{"id":9809,"date":"2026-07-18T17:18:41","date_gmt":"2026-07-18T15:18:41","guid":{"rendered":"https:\/\/www.lrob.fr\/?p=9809"},"modified":"2026-07-18T17:18:42","modified_gmt":"2026-07-18T15:18:42","slug":"critical-flaws-in-the-wordpress-core-what-you-need-to-know-and-how-to-react","status":"publish","type":"post","link":"https:\/\/www.lrob.fr\/en\/blog\/securite-wordpress\/failles-critiques-dans-le-core-wordpress-ce-quil-faut-savoir-et-comment-reagir\/","title":{"rendered":"Critical Vulnerabilities in WordPress Core: What You Need to Know and How to Respond"},"content":{"rendered":"<p class=\"wp-block-paragraph\">On July 17, 2026, the WordPress security team released three patch versions\u20146.8.6, 6.9.5, and 7.0.2\u2014along with two security advisories posted to the repository <code>wordpress-develop<\/code>. One of the two vulnerabilities is classified <strong>Critique<\/strong> and allows, in certain configurations, remote code execution.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This article details the technical nature of these vulnerabilities, the affected versions, and the steps to secure your installations.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Why a core vulnerability deserves your attention<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The overwhelming majority of WordPress vulnerabilities disclosed each year concern <strong>third-party extensions and themes<\/strong>. The core code, on the other hand, benefits from a rigorous review process, a large contributor base, and a dedicated security team. Vulnerabilities are rare.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This is precisely what makes the event notable. A vulnerability in the core potentially affects all sites running the affected versions, without any specific extension being necessary for exploitation. The attack surface is no longer dependent on the administrator's choices: it is universal.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">The two vulnerabilities<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">GHSA-fpp7-x2x2-2mjf \u2014 SQL Injection Facilitated in <code>WP_Query<\/code><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Severity: moderate<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Affected versions:<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Branch<\/th><th>Vulnerable versions<\/th><\/tr><\/thead><tbody><tr><td>6.8<\/td><td>6.8.0 to 6.8.5<\/td><\/tr><tr><td>6.9<\/td><td>6.9.0 \u2192 6.9.4<\/td><\/tr><tr><td>7.0<\/td><td>7.0.0 \u2192 7.0.1<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The flaw lies in the processing of the parameter <code>author__not_in<\/code> from the class <code>WP_Query<\/code>, the central component used by WordPress to build content retrieval queries.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>WP_Query<\/code> accepts a large number of parameters that allow filtering of returned publications. The parameter <code>author__not_in<\/code> serves to exclude authors from a set of results, normally expecting a table of numerical identifiers. A validation defect on this parameter allows unsanitized data to end up in the final SQL query.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The qualifier \u00abfacilitated\u00bb vulnerability (<em>facilitated<\/em>) used in the advisory is important: the core does not directly expose the parameter to unauthenticated user input. Exploitation assumes that an entry point\u2014an extension, theme, custom code, or API route\u2014passes an attacker-controlled value to this parameter. The core makes exploitation possible; the application context makes it reachable.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This explains the moderate severity rating when considering the vulnerability in isolation. This rating changes dramatically when combined.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Disclosed by:<\/strong> TF1T, dtro and haongo.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">GHSA-ff9f-jf42-662q \u2014 Route Confusion in REST API Leading to RCE<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Severity: critical<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Affected versions:<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Branch<\/th><th>Vulnerable versions<\/th><\/tr><\/thead><tbody><tr><td>6.9<\/td><td>6.9.0 \u2192 6.9.4<\/td><\/tr><tr><td>7.0<\/td><td>7.0.0 \u2192 7.0.1<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Since WordPress 6.9, the REST API offers a mechanism for <strong>grouped queries<\/strong> (<em>batch requests<\/em>), which allows submitting multiple operations in a single HTTP call via the endpoint <code>\/wp-json\/batch\/v1<\/code>. This mechanism exists for performance reasons, especially on the block editor side.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The vulnerability lies in a confusion in route resolution within this mechanism. Individual requests encapsulated in a batch are not resolved and validated with the same rigor as an equivalent direct request. An attacker can exploit this discrepancy to reach, via the batch, routes or parameters that would have been filtered in direct access.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Taken in isolation, this confusion of routes is an access control problem. <strong>Combined with the SQL injection described above<\/strong>, it provides the missing entry point: the attacker gets a channel to inject controlled data into <code>WP_Query<\/code>, transforming a conditional vulnerability into a full exploit chain leading to the\u2019<strong>remote code execution<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This is the classic pattern of a composite vulnerability: two individually manageable flaws, the combination of which produces an impact of a completely different order.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Disclosed by:<\/strong> Adam Kues (Assetnote \/ Searchlight Cyber).<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Version summary<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Corrected versions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>6.8.6<\/strong><\/li>\n\n\n\n<li><strong>6.9.5<\/strong><\/li>\n\n\n\n<li><strong>7.0.2<\/strong><\/li>\n\n\n\n<li><strong>7.1 beta2<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Summary Table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Installed version<\/th><th>SQL Injection<\/th><th>RCE via REST API<\/th><th>Action<\/th><\/tr><\/thead><tbody><tr><td>Less than or equal to 6.7.x<\/td><td>Not applicable<\/td><td>Not applicable<\/td><td>Branch update recommended<\/td><\/tr><tr><td>6.8.0 \u2013 6.8.5<\/td><td><strong>Vulnerable<\/strong><\/td><td>Not applicable<\/td><td>Switch to 6.8.6<\/td><\/tr><tr><td>6.8.6<\/td><td>Corrected<\/td><td>Not applicable<\/td><td>Updated<\/td><\/tr><tr><td>6.9.0 \u2013 6.9.4<\/td><td><strong>Vulnerable<\/strong><\/td><td><strong>Vulnerable<\/strong><\/td><td>Upgrade to 6.9.5 \u2014 urgent<\/td><\/tr><tr><td>6.9.5<\/td><td>Corrected<\/td><td>Corrected<\/td><td>Updated<\/td><\/tr><tr><td>7.0.0 \u2013 7.0.1<\/td><td><strong>Vulnerable<\/strong><\/td><td><strong>Vulnerable<\/strong><\/td><td>Upgrade to 7.0.2 \u2014 urgent<\/td><\/tr><tr><td>7.0.2<\/td><td>Corrected<\/td><td>Corrected<\/td><td>Updated<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">The specific case of versions 6.7 and earlier<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">These versions are not affected by the two opinions. This is good news for now, but it hides a structural problem.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A site running 6.7 or earlier is several cycles behind. It is exposed to vulnerabilities patched between its version and the current version\u2014public, documented flaws for which exploits have been circulating for months. Not appearing on the affected versions list this month does not constitute a secure posture.<\/p>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/www.lrob.fr\/en\/services\/wordpress-webmastering\/\">Discover WordPress Maintenance by LRob<\/a><\/div>\n<\/div>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">What to do concretely<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1. Identify your versions<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">From WP-CLI, on each installation:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>wp core version<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">On a shared or multisite server, a file system scan remains the most reliable method:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>find \/var\/www -name version.php -path &#x27;*\/wp-includes\/*&#x27; 2&gt;\/dev\/null | \\\nwhile read f; do\n  v=$(grep -oP &quot;\\\\\\$wp_version = &#x27;\\K[^&#x27;]+&quot; &quot;$f&quot;)\n  echo -e &quot;$v\\t${f%\/wp-includes\/version.php}&quot;\ndone | sort -V<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">2. Update<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Via WP-CLI, while staying in the minor branch:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>wp core update --minor<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Or by explicitly targeting the version:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>wp core update --version=7.0.2<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">From the administration interface: <strong>Dashboard \u2192 Updates<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3. Check afterward<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The core update doesn't guarantee anything if it failed silently \u2014 a common case when file system permissions are restrictive or a plugin managing updates interferes. Always check the effective version after the operation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4. Search for any signs of compromise<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">For a site remaining vulnerable in 6.9.x or 7.0.x for an extended period, an update is not enough: it closes the door but doesn't expel who may have already entered. Priority checkpoints:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>unknown administrator accounts in <strong>Users<\/strong><\/li>\n\n\n\n<li>recently modified PHP files in <code>wp-content\/uploads\/<\/code> (directory that should never contain)<\/li>\n\n\n\n<li>unexpected scheduled tasks<code>WP Cron event list<\/code>)<\/li>\n\n\n\n<li>suspicious entries in the access logs on <code>\/wp-json\/batch\/v1<\/code><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">If your site has been hacked, LRob offers a service to <a href=\"https:\/\/www.lrob.fr\/en\/services\/repairing-and-securing-pirated-wordpress-sites\/\">WordPress repair and security<\/a>.<\/p>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/www.lrob.fr\/en\/services\/repairing-and-securing-pirated-wordpress-sites\/\">Discover our WordPress repair service<\/a><\/div>\n<\/div>\n\n\n\n<h3 class=\"wp-block-heading\">5. Prevent this from happening again<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Automatic background updates for minor core versions have been enabled by default since WordPress 3.7. If your sites were not updated, it means this mechanism has been disabled\u2014either intentionally or by a plugin. Check the constant in <code>wp-config.php<\/code> :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>define( 'WP_AUTO_UPDATE_CORE', 'minor' );<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Security patches fall precisely into this category.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For faster updates, LRob hosting allows automatic updates directly from the server.<\/p>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/www.lrob.fr\/en\/web-hosting\/\">Web hosting offers<\/a><\/div>\n\n\n\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/www.lrob.fr\/en\/web-hosting\/web-agency\/\">Multi-site Hosting Offers (Web Agency)<\/a><\/div>\n<\/div>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">What this episode really reveals<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The time between a patch's release and the appearance of automated exploits is now measured in hours, not weeks. Mass scanners integrate new vectors almost immediately, and a lagging site isn't targeted because someone is interested in it; it's targeted because it's discoverable.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The relevant question, therefore, is not \u00abam I up-to-date today?\u00bb, but \u00abhow much time structurally passes in my organization between the release of a patch and its application?\u00bb. This is a question of process, not individual vigilance.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">The LRob Approach<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">At LRob, the coverage of these two vulnerabilities concerned <strong>1.3 % of the hosted fleet<\/strong> at the time of the publication of notices \u2014 a direct consequence of an automated update policy applied by default.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Our WordPress hosting offer includes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>additional WordPress-specific protections<\/strong>, upstream of the application code, with active banning of attackers by the servers, which drastically reduces the attack surface regardless of the installed version; ;<\/li>\n\n\n\n<li><strong>the ability to enable automatic updates for the core, extensions, and themes<\/strong> ;<\/li>\n\n\n\n<li><strong>from <a href=\"https:\/\/www.lrob.fr\/en\/services\/wordpress-webmastering\/\">Comprehensive WordPress maintenance plans<\/a><\/strong>, including monitoring, tested backups, and incident response.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The objective is simple: for the publication of a security notice to no longer be an event requiring urgent action for you. You entrust the monitoring and application of patches, and you can sleep soundly.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong><a href=\"https:\/\/www.lrob.fr\/en\/services\/wordpress-webmastering\/\">Discover our WordPress maintenance plans \u2192<\/a><\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">References<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/github.com\/WordPress\/wordpress-develop\/security\/advisories\/GHSA-fpp7-x2x2-2mjf\" target=\"_blank\" rel=\"noopener\">GHSA-fpp7-x2x2-2mjf \u2014 SQL injection vulnerability in the <code>author__not_in<\/code> parameter of <code>WP_Query<\/code><\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/github.com\/WordPress\/wordpress-develop\/security\/advisories\/GHSA-ff9f-jf42-662q\" target=\"_blank\" rel=\"noopener\">GHSA-ff9f-jf42-662q \u2014 REST API batch-route confusion and SQL injection vulnerability leading to Remote Code Execution<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/wordpress.org\/news\/2026\/07\/wordpress-7-0-2-release\/\" target=\"_blank\" rel=\"noopener\">Official WordPress 7.0.2 Announcement<\/a><\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"<p>WordPress has just released three patch versions following the discovery of two vulnerabilities in the core, one of which is critical and allows for remote code execution. Technical analysis of the flaws, affected versions, and steps to secure your installations.<\/p>","protected":false},"author":1,"featured_media":9810,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[41],"tags":[],"class_list":["post-9809","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-securite-wordpress"],"_links":{"self":[{"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/9809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/comments?post=9809"}],"version-history":[{"count":1,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/9809\/revisions"}],"predecessor-version":[{"id":9811,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/9809\/revisions\/9811"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/media\/9810"}],"wp:attachment":[{"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/media?parent=9809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/categories?post=9809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/tags?post=9809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}