A/B Testing for WordPress WP Registry grade D. High-severity findings · 5 findingsWP RegistryHigh-severity findings · 5 findingsOpen the reportD #9 in Analytics & Tracking

High-severity findings.

Audited release

1.18.2

Findings

5

Worst severity

high

Content hash

64f6bffe5ab783c213fa6f45… Copy

Findings

• high Contributor+ stored XSS via unescaped ab-test-block id attribute (CVE-2025-4587)

  xss_stored

  register_block_type('ab-testing-for-wp/ab-test-block') declares no PHP attribute schema or sanitize_callback. renderTest() takes $attributes['id'] from the block comment and wrapData() concatenates it raw into a data-test HTML attribute. Contributors can insert the inserter block (or convert an existing block) and set id in the code editor to a breakout such as x"><img src=x onerror=alert(document.domain)><!-- ; wp_kses_post does not rewrite JSON inside HTML comments, so the payload survives save and executes for every visitor of the published/previewed page. Variant HTML from GET /ab-testing-for-wp/v1/ab-test is also assigned with test.innerHTML in handleTestRender.ts (script tags would not run there, but the wrapData sink is a real HTML parser context). Unpatched; Wordfence/CVE-2025-4587, WordPress.org closed the plugin on 2025-06-26 for this issue.

  src/php/helpers/block-renderer.php:122-127

  Recommendation

  Escape the id with esc_attr() (and restrict it to a safe charset such as [A-Za-z0-9_-]). Register the block attributes in PHP with a sanitize_callback. Do not treat Gutenberg block-comment JSON as trusted for HTML attribute context.

• high Inserter block and REST preview render arbitrary posts without a read_post check

  information_disclosure

  Three sinks load get_post($id) and run the_content with no current_user_can('read_post'), post_status, or post_type gate. (1) renderInsertedTest() is the render_callback for ab-test-block-inserter; a Contributor/Author sets attributes.id to any post ID (private page, someone else's draft, password-protected post) and the full body is echoed on the front end once the post is published (Authors publish themselves). (2) GET /ab-testing-for-wp/v1/get-test-content-by-post?id=N (permission_callback edit_posts only) returns apply_filters('the_content') wrapped in a full HTML document that also runs do_action('wp_head'), plus get_edit_post_link. (3) GET /get-posts-by-type?type=post returns $query->posts as JSON, including post_content and post_password for every published post of that type (password-protected posts are status=publish). Shortcode [ab-test id] similarly renders any abt4wp-test regardless of status. Observable: dump or publicly embed unpublished marketing copy, private pages, and password-protected post passwords.

  src/php/helpers/block-renderer.php:240-245

  Recommendation

  Require current_user_can('read_post', $id) and post_type === 'abt4wp-test' (and a public/publish status for front-end renders). For REST, also require edit_post on that ID. Do not JSON-encode full WP_Post rows; return id/title only and exclude post_password.

• medium Test mutation and plugin options REST routes require only edit_posts

  missing_capability

  The overview admin pages are registered with manage_options, but POST /ab-testing-for-wp/v1/update-test and POST /ab-testing-for-wp/v1/options only check current_user_can('edit_posts'). updateTestData() json_decodes the body and ABTestManager::updateTest() array_merges it into the existing row then REPLACE INTO ab_testing_for_wp_ab_test, so a Contributor who knows a test id (they are printed as data-test on every front-end wrapper, and GET /get-tests-info also requires only edit_posts) can set isEnabled, postGoal, control, title, or postId for any site test — turning experiments off or pointing conversions at a different goal. handleOptions() writes any key/value into autoloaded option ab-testing-for-wp-options with no allow-list (including lastMigration, which forces installer ALTER/CREATE on the next init). Core REST cookie nonce applies; this is missing capability, not CSRF.

  src/php/registrations/register-rest.php:55-125

  Recommendation

  Gate update-test, options, get-tests-info, and stats on manage_options (or edit_post for the specific host post). Allow-list option keys. Do not let Contributors REPLACE test rows they do not own.

• medium Admin database repair runs on an un-nonced GET and DROPs plugin tables

  csrf

  pages/advanced.php is included from RegisterAdminPage::advanced(), which is the manage_options submenu ab-testing-for-wp_advanced. The first lines run Installer::repair() when $_GET['repair-db']==='true' with no wp_verify_nonce, no check_admin_referer, and no POST requirement. repair() snapshots tracking, DROP TABLE the four ab_testing_for_wp_* tables, recreates them, clears lastMigration, re-runs migrations, and repopulates from a search for the block comment. A CSRF GET (img/script against /wp-admin/admin.php?page=ab-testing-for-wp_advanced&repair-db=true) while an administrator is logged in executes that path. If the request dies after DROP, all experiment metadata and logs are gone; even on success, repopulate depends on WP_Query search finding every block.

  src/php/pages/advanced.php:9-15

  Recommendation

  Use a POST form with check_admin_referer(), current_user_can('manage_options') immediately before repair(), and never trigger schema DROP from a GET parameter.

• medium Plugin closed on WordPress.org for an unpatched 2025 XSS; no release since 1.18.2

  abandoned_plugin

  Header and README still ship Version 1.18.2, Requires at least 5.0, Tested up to 5.4. WordPress.org closed ab-testing-for-wp on 26 June 2025 with reason Security Issue the same day CVE-2025-4587 was published; Wordfence lists no patch. This GitHub-distributed zip is that same 1.18.2 tree (content hash 64f6bffe…). Combined with the additional unpatched IDOR/BAC/CSRF issues in this audit, sites cannot get a vendor fix via the update API.

  ab-testing-for-wp.php:6-12

  Recommendation

  Uninstall. WordPress.org already closed the listing; there is no patched release to update to. Replace with a maintained A/B testing plugin.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.