CVE-2026-63030: Verified Repro With Script Download

WordPress 7.0.1 contains a composable pre-authentication chain in its stock REST and post-processing paths. A malformed REST batch entry desynchronizes parsed requests from matched handlers; a shifted posts handler then accepts an attacker-controlled scalar author_exclude value that reaches WP_Query::author__not_in without integer normalization. The resulting full-row SQL projection lets an unauthenticated attacker poison post-cache objects. Core oEmbed partial-update and hierarchy-repair behavior turns those transient objects into persistent forged posts, including a due Customizer changeset. While core applies that changeset under its recorded owner context, a forged request post with status parse invokes the stock parse_request hook and re-enters REST dispatch. A nested malformed batch consequently reaches the normal user-creation controller as the owner and creates a fresh attacker-chosen administrator. That new account can authenticate normally, use the core plugin uploader, and execute a command as the web server. WordPress 7.0.2 aligns batch arrays, integer-normalizes the ID list, and blocks nested top-level REST dispatch.

• Affected component: WordPress Core REST batch dispatch, WP_Query, post/oEmbed cache update behavior, Customizer changeset publication, and nested REST dispatch.
• Affected version exercised: stock WordPress 7.0.1, official wordpress:7.0.1-php8.2-apache image pinned to sha256:bfc320ed4f02dd3939186b8020de64203a48a939d6dedcf44cb92cf2368923f5.
• Fixed control exercised: WordPress 7.0.2 source at commit 855551c4477bd5a0407221c57dae123c4163b434, over the same pinned base image.
• Database: MySQL 8.0 pinned to sha256:7dcddc01f13bab2f15cde676d44d01f61fc9f99fe7785e86196dfc07d358ae2b, with @@local_infile=0, application-scoped grants, and no global FILE privilege.
• Risk: Critical. An unauthenticated network attacker can create a new administrator without knowing, recovering, or reusing the sole owner's random password, then obtain arbitrary command execution as Apache's www-data identity.

Impact Parity

• Disclosed/claimed maximum impact: Unauthenticated remote code execution through creation of a fresh attacker-chosen administrator.
• Reproduced impact from this run: Full unauthenticated fresh-administrator creation followed by normal login, core plugin upload, and target-originated command execution as uid=33(www-data) gid=33(www-data) groups=33(www-data). The final generated script passed twice consecutively; each execution itself recreated and passed two clean vulnerable/fixed matrices.
• Parity: full.
• Not demonstrated: None of the claimed chain remains unproved.

Root Cause

Three missing invariants in WordPress 7.0.1 compose into the privilege transition:

1. REST batch request/handler array desynchronization. WP_REST_Server::serve_batch_request_v1() appends a parse error to its request array but, in the vulnerable source, does not append a corresponding entry to the matched-handler array before continuing. Subsequent requests are paired with the next route's handler and permission callback.
2. Scalar author__not_in SQL injection. A shifted posts-list handler retains attacker-controlled query parameters. In 7.0.1, author__not_in is normalized only when already represented as an array; a scalar can reach the interpolated NOT IN (...) SQL clause. A high page size and orderby=none disable the ID-only split-query boundary, allowing a complete 23-column forged wp_posts.* row.
3. Nested top-level REST dispatch. Core's dynamic {$new_status}_{$post_type} transition permits the forged parse_request pair to call rest_api_loaded() while an outer REST dispatch is active. The vulnerable implementation re-enters serve_request() during the Customizer's temporary owner context. The nested malformed batch then invokes WP_REST_Users_Controller::create_item() with permission checks evaluated as user 1.

The middle state transition uses stock behavior rather than a plugin gadget: an ID-zero embed triggers WP_Embed::shortcode(), which performs a partial wp_update_post() on a real cache row. wp_update_post() first loads and merges all fields from the poisoned cached object; hierarchy repair performs another partial update and persists the forged fields. A due customize_changeset then applies stock custom CSS under the recorded owner context, and the forged status/type transition selects the existing parse_request action.

The fixed release adds batch-array alignment (c8bdf1fa12355f79db94054d307d0e3898b501c9), parses author exclusion values through an integer-only ID list, and guards against nested REST dispatch. The fixed source identity used by the control is commit 855551c4477bd5a0407221c57dae123c4163b434 (WordPress 7.0.2).

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh from any working directory (or set PRUVA_ROOT to the bundle directory).
2. The script verifies the ticket-pinned image digests and exact 7.0.2 source archive, starts isolated MySQL and WordPress targets, and installs each with exactly one owner whose random password is generated inside the installer and is neither printed nor supplied to the exploit driver.
3. It confirms no exploit plugin or mu-plugin is present, application DB grants are scoped to wordpress.*, and @@local_infile=0.
4. A distinct Python driver container sends unauthenticated HTTP requests through /wp-json/batch/v1, seeds and rediscovers disposable oEmbed rows through the vulnerable application path, composes the forged changeset/request state, and creates a randomized administrator.
5. The driver authenticates through wp-login.php, uploads a randomized proof plugin through the core uploader, and requests it over HTTP to execute printf 'PRUVA-CMD-MARKER\n'; id.
6. The exact same trigger is run against WordPress 7.0.2 and must fail before its first disposable oEmbed cache row can be discovered. The script verifies one user and zero oembed_cache rows afterward.
7. The script destroys both target stacks, recreates clean databases and targets, and repeats the complete vulnerable/fixed matrix.

Expected success output ends with:

[+] CONFIRMED: WordPress 7.0.1 pre-auth fresh-administrator chain to command execution
[+] Two clean vulnerable/fixed matrices passed

Evidence

The current script records fresh evidence under bundle/logs/:

• reproduction_steps.log: complete build, setup, trigger, oracle, and cleanup transcript.
• source_identity.log: fixed commit, ticket source identities, bundled 7.0.2 archive checksum, and stable prepared repository path.
• image_identity.log: requested image digests and resolved Docker image IDs.
• network_boundary.log: distinct driver/provider and target identities plus isolated network state.
• vulnerable_setup.log: target version, image identity, mounts, stock plugin inventory, absent mu-plugins, initial user/oEmbed counts, grants, and local_infile state.
• vulnerable_database_before.log and vulnerable_database_after.log: one-to-two user transition, fresh username/ID, administrator metadata, and oEmbed state.
• vulnerable_http_chain.log: full remote-chain JSON including generated administrator identity, normal-login result, plugin-upload result, and command response.
• vulnerable_command_response.log: target-originated command markers and exact www-data identity.
• fixed_setup.log, fixed_http_chain.log, and fixed_database_after.log: unchanged-trigger failure before cache discovery and fixed postconditions.
• second_* logs and second_clean_run.log: independent clean-target repeat.
• bundle/repro/runtime_manifest.json: strict runtime evidence manifest written on every attempt.

Fresh current-run excerpts from the final two consecutive script executions include:

administrator.id=2
administrator.roles=["administrator"]
normal_login_confirmed=true
plugin_upload_confirmed=true
PRUVA-RCE-BEGIN
PRUVA-CMD-MARKER
uid=33(www-data) gid=33(www-data) groups=33(www-data)
PRUVA-RCE-EXIT:0

The matching database evidence records user_count=2, admin=2:<generated username>, while each fixed control records user_count=1 and oembed_count=0. The unchanged fixed trigger raises oEmbed seed did not create a discoverable cache row, proving first divergence before cache discovery. logs/pass1/ preserves the preceding successful top-level execution; the root logs/ files are the second successful execution. Historical proof-carry data is not treated as evidence for this verdict.

Recommendations / Next Steps

• Upgrade affected installations to WordPress 7.0.2 or later.
• Preserve the batch parser invariant by appending exactly one matched-handler and validation entry for every parsed sub-request, including parse errors.
• Normalize every author include/exclude input with wp_parse_id_list() before SQL construction, regardless of the original scalar/array shape.
• Refuse top-level serve_request() re-entry while the REST server is already dispatching; guard both rest_api_loaded() and the server entry point.
• Add regression coverage for malformed entries at every batch position, scalar/list query-parameter forms, nested batch bodies, and dynamic status/type hooks reached during privileged context windows.
• Add end-to-end tests asserting that the unchanged 7.0.1 trigger cannot create oEmbed cache state, users, or plugin files on fixed releases.

Additional Notes

• The final proof uses the real stock HTTP/REST, login, and plugin-upload boundaries; no sanitizer, direct parser harness, or source-only oracle is used.
• The exploit driver performs no direct database write and receives no owner password or database credential.
• The oEmbed service is an isolated provider that returns valid bounded iframe HTML; it does not fabricate the command marker or privileged state.
• The vulnerable target uses no modified WordPress tree. The fixed control intentionally overlays the complete exact 7.0.2 source onto the same pinned official 7.0.1 PHP/Apache base.
• Container names are randomized and cleanup is trapped, making the script safe to repeat. It also recreates both vulnerable and fixed targets internally for a second clean matrix.
• Idempotency is confirmed: the final script was executed twice consecutively from clean targets, both exits were zero, generated administrator usernames differed, and every vulnerable/fixed oracle passed. Each script execution also performs an internal clean teardown/recreation, yielding four fresh vulnerable successes and four fixed controls across the two required top-level runs.

No distinct vulnerability variant or WordPress 7.0.2 bypass was found. The bounded search exercised the original unauthenticated /wp-json/batch/v1 trust boundary against clean stock WordPress 7.0.1 and exact 7.0.2 targets, tested a materially different data path that moved the shifted scalar author_exclude value from the URL query string into the subrequest JSON body, retained the original query-scalar path as a live primitive control, and separately examined malformed-entry placement in batch dispatch. The query-scalar control reflected a forged full-row marker on 7.0.1 and not on 7.0.2; the body-scalar candidate reflected no forged marker on either target. Exact trunk revision ace9192af868524bdc49cf4fcb91f4c12c73ee5f retained all three independent guards. The result is therefore negative rather than a fabricated alternate label for the parent chain.

Fix Coverage / Assumptions

The 7.0.2 fix establishes three independent invariants:

1. WP_REST_Server::serve_batch_request_v1() appends a WP_Error to $matches whenever it appends the same error to $validation, preserving one-to-one request/match/validation indexing for every malformed subrequest (src/wp-includes/rest-api/class-wp-rest-server.php).
2. WP_Query::get_posts() parses every non-empty author__not_in value with wp_parse_id_list() before interpolating the resulting integer list into SQL (src/wp-includes/class-wp-query.php). This is shape-independent at the sink: scalar strings and arrays are normalized.
3. rest_api_loaded() and WP_REST_Server::serve_request() refuse to start a fresh top-level REST cycle while a dispatch is active (src/wp-includes/rest-api.php and src/wp-includes/rest-api/class-wp-rest-server.php). Internal subrequests must use dispatch().

These changes assume that every batch parse failure is represented by a WP_Error, all author-exclusion flows reaching WP_Query use author__not_in, and privileged re-entry requires a fresh serve_request() cycle. Source scanning supports those assumptions for the parent chain. At the exact tested trunk revision, the sole production call to serve_request() remained in rest_api_loaded(), which is itself guarded, while the server method also retains a defense-in-depth guard.

The patch does not redesign the oEmbed-cache merge behavior, Customizer per-setting user switching, dynamic post-status/type hooks, or normal REST dispatch(). Those paths remain legitimate core behaviors. They are no longer attacker-reachable through the parent chain because the patch cuts the chain at three earlier, independent gates. The only asymmetry noticed in nearby code is that author__in retains a separate normalization implementation, but it applies absint to every value and does not preserve the parent SQL-injection sink; relabeling it as a bypass would be unsupported.

Variant / Alternate Trigger

All runtime candidates used unauthenticated HTTP POST /wp-json/batch/v1 from a separate driver container:

1. Body-scalar alternate data path. The shifted request placed author_exclude in its JSON body instead of the URL query string, while keeping the malformed nested batch and full-row marker query. This was materially different input placement but did not reach the SQL marker on either 7.0.1 or 7.0.2. On 7.0.1 the shifted GET posts handler executed but did not consume this body value as the needed query parameter.
2. Query-scalar sink control. The scalar remained in the shifted subrequest URL query. A synthetic wp_posts.* row containing PRUVA-VARIANT-ROW-MARKER was reflected on 7.0.1, proving the vulnerable batch-to-WP_Query path was live in this stage's fresh environment. The marker was absent on 7.0.2, where aligned handlers stop the shifted route and integer normalization independently removes SQL syntax.
3. Alternate malformed-entry/alignment check. A malformed subrequest was followed by post and user routes to compare handler selection. On 7.0.1 the response showed the shifted user-controller permission code (rest_cannot_create_user) for the posts request; 7.0.2 showed the correctly aligned posts-controller code (rest_cannot_create). This confirms the alignment patch rather than a transport failure. Moving the malformed error later cannot shift an earlier request and leaves no subsequent attacker request to exploit when last; multiple errors are covered by appending one match entry per error.

The relevant path is WP_REST_Server::serve_batch_request_v1() -> shifted WP_REST_Posts_Controller::get_items() -> WP_Query::get_posts() for the primitive, followed in the parent chain by oEmbed/cache persistence, Customizer publication, rest_api_loaded()/serve_request() re-entry, and WP_REST_Users_Controller::create_item(). No alternate stock endpoint was found that both crosses the same unauthenticated network boundary and bypasses all three fixed invariants.

• Component: WordPress Core REST batch dispatch and WP_Query author exclusion handling.
• Vulnerable control tested: stock WordPress 7.0.1 source identity 18f793b1f16c1b15b0fc37027f4aeaefab0bfe02.
• Fixed target tested: WordPress 7.0.2 tag/commit 855551c4477bd5a0407221c57dae123c4163b434 over the ticket-pinned PHP/Apache image.
• Latest checked: origin/trunk at exact revision ace9192af868524bdc49cf4fcb91f4c12c73ee5f on 2026-07-18; all three guards were present. Latest was source-inspected rather than started as a third runtime because it is an unreleased 7.1 development tree and the exact released 7.0.2 fixed target supplied the runtime oracle.
• Risk of the parent issue: Critical unauthenticated administrator creation leading to code execution.
• Risk established by this variant run: None on the fixed target. No persistent write, user creation, privilege transition, or code execution occurred.

Impact Parity

• Disclosed/claimed maximum parent impact: Unauthenticated creation of a fresh administrator followed by normal login, core plugin upload, and command execution as www-data.
• Reproduced impact in this variant run: A side-effect-free full-row SQL reflection marker only on the vulnerable 7.0.1 control. No marker reached 7.0.2; both clean targets retained one user and their original post counts.
• Parity: none for a fixed-version bypass. The vulnerable-control primitive is partial evidence only and is not claimed as a new variant.
• Not demonstrated: Fixed-version SQL injection, cache poisoning, persistent post creation, administrator creation, authentication, plugin upload, or code execution.

Root Cause

There is no surviving same-root-cause path on the tested fixed target. The parent root cause requires composition of (a) batch-array desynchronization, (b) unnormalized scalar author__not_in SQL construction, and (c) nested top-level REST dispatch during a temporary privileged context. WordPress 7.0.2 fixes each condition independently in commits merged into tag 855551c4477bd5a0407221c57dae123c4163b434:

• 85015b84fbc52bf6151a691299896b8971772594 — nested top-level REST dispatch guards.
• c8bdf1fa12355f79db94054d307d0e3898b501c9 — batch match-array alignment.
• 74d37a344cbf28e9187a1a5ca71b33d186bcd333 — integer normalization of author__not_in.

The body-scalar experiment did not reproduce even on 7.0.1 because request-body placement did not become the posts collection's query parameter in this shifted GET-handler path. The exact query-scalar parent primitive did reproduce on 7.0.1, then failed on 7.0.2 as expected. Consequently there is no technical basis to claim that the underlying bug remains reachable.

Reproduction Steps

1. Run bundle/vuln_variant/reproduction_steps.sh from any directory, optionally setting PRUVA_ROOT to the bundle directory.
2. The script resolves and records exact 7.0.1, 7.0.2, and trunk source identities; reads the target security policy; verifies the three guards in 7.0.2 and trunk; launches clean isolated MySQL and WordPress 7.0.1/7.0.2 targets; installs each with one owner whose random password is never exposed; and runs all three candidates over unauthenticated HTTP.
3. It requires the vulnerable query-scalar marker to be present, the fixed marker to be absent, and user/post counts to remain unchanged. It exits 1 for this valid negative outcome. Exit 0 is reserved for a marker reaching the fixed target, and exit 2 indicates an infrastructure/oracle failure.
4. Expected final evidence is verdict=no_distinct_variant_or_bypass and NO DISTINCT VARIANT/BYPASS.

Evidence

Primary logs are under bundle/logs/vuln_variant/:

• verification_run1.log and verification_run2.log: two independent complete script executions.
• two_run_verification.log: both expected exits were 1.
• vulnerable_query_scalar.json: marker_reflected=true, proving the vulnerable primitive was live.
• fixed_query_scalar.json: marker_reflected=false.
• vulnerable_body_scalar.json and fixed_body_scalar.json: alternate body path was negative on both.
• vulnerable_batch_alignment.json and fixed_batch_alignment.json: shifted versus aligned controller response codes.
• vulnerable_before.log, vulnerable_after.log, fixed_before.log, and fixed_after.log: both targets stayed at user_count=1, post_count=4, oembed_count=0, and local_infile=0.
• source_identity.log, fixed_version.txt, and latest_version.txt: exact commit identities.
• static_coverage.log: 7.0.2 and trunk each contain the batch, nested-dispatch, and author-ID guards; trunk has one production serve_request() call site.
• fix_diff.txt and security_policy.md: patch and target policy evidence.
• candidate_matrix.log: canonical bounded-search outcome.

Key evidence excerpts:

candidate_1=body_scalar_alternate_data_path vulnerable_marker=false fixed_marker=false
candidate_2=query_scalar_original_sink_control vulnerable_marker=true fixed_marker=false
candidate_3=batch_alignment_alternate_error_position inspected_runtime_and_source=true
latest_revision=ace9192af868524bdc49cf4fcb91f4c12c73ee5f guards_retained=true
verdict=no_distinct_variant_or_bypass
run1_exit=1
run2_exit=1

Recommendations / Next Steps

• Keep all three fixes; none should be treated as redundant. Add regression tests that compose malformed batch entries at first, middle, last, and multiple positions and assert exact request/match/validation alignment.
• Add WP_Query tests covering scalar strings, arrays, comma-separated strings, nested arrays, and values supplied through query and body parameter bags, requiring integer-only author__not_in SQL.
• Retain both nested-dispatch guards. Add a regression assertion that all internal REST subrequests use dispatch() and that serve_request() cannot re-enter while is_dispatching() is true.
• Consider normalizing author__in through wp_parse_id_list() too for consistency and stable cache-key behavior, although current absint mapping did not expose the parent sink.
• Add an end-to-end test that the parent unauthenticated request leaves users, posts, oEmbed rows, and plugin state unchanged on supported releases.

Additional Notes

• WordPress's repository SECURITY.md explicitly covers Core and directs reports to HackerOne. It does not exclude unauthenticated REST privilege transitions; the tested boundary is therefore in scope. The probes do not reframe a user-selected local file or documented behavior as a security issue.
• Runtime probes were intentionally side-effect-free: the SQL candidate only reflected a synthetic row in the REST response and did not persist it. Database counts verify this.
• Idempotency was confirmed by two consecutive complete script runs, each ending with the expected exit code 1 and the same negative matrix.
• The latest default branch was exact-revision source checked, not runtime built, because it was an unreleased 7.1 development revision. The fixed 7.0.2 release was tested live side by side as required.