• The following is an AI generated report about a Client_DOM_Stored_XSS vulnerability in the scripts/post.js:editPostSlug() method, this is impacting my WordPress instance since our IT team has a strict CVE resolution policy:

    The method function embeds untrusted data in generated output with html, at line 1037 of \wordpress\wp-content\plugins\classic-editor\scripts\post.js. This untrusted data is embedded into the output without proper sanitization or encoding, enabling an attacker to inject malicious code into the generated web-page.

    AI Reasoning

    The AJAX callback receives the server response in the data parameter and directly injects it into the page with box.html(data). No sanitization, encoding, or validation of data is performed before this DOM‑inserting operation, allowing attacker‑controlled content to be rendered as HTML. This constitutes a stored DOM‑based XSS vulnerability.

    AI Evidence

    [“Line 1035: function(data) { \u2013 defines the callback parameter receiving server data.”, “Line 1037: box.html(data); \u2013 inserts the received data into the DOM as HTML.”, “No calls to functions or methods that perform sanitization, validation, or encoding on data before the html call.”]

    AI Remediation

    Sanitize or encode the server‑generated content before inserting it into the DOM. Options include:
    1. Return plain text or JSON from the AJAX handler and use text() or a templating engine that escapes HTML.
    2. Apply a client‑side sanitization library (e.g., DOMPurify) to data before calling html().
    3. Ensure the server side validates and escapes any user‑controlled fields used to build the response.

    Personally I think this is a bit blown out of proportion since the post request in question is affected and returned by wp-admin/ajax-admin.php anyway… so this feels a bit unnecessary, however it couldn’t hurt to leverage something like DOMPurify to do some basic sanitization on the response data.

    https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Safely_inserting_external_content_into_a_page#html_sanitization

    • This topic was modified 3 months, 2 weeks ago by branacleboy.
Viewing 1 replies (of 1 total)
  • Nidhi Makadia

    (@nidhimakadia)

    Hi @branacleboy,

    Thanks for reporting this. It looks like a false positive from the scanner:

    • The data passed to box.html(data) comes from WordPress core’s sample-permalink AJAX handler. That handler checks a nonce and requires permission to edit the post.
    • The server builds the response with get_sample_permalink_html(), which escapes all dynamic values (esc_html() / esc_url()) before sending them. The response is safe,
      pre-escaped HTML from WordPress itself.
    • This file is a copy of core’s wp-admin/js/post.js, and core uses the same code.

      Static scanners like Checkmarx flag any .html() call, but they can’t see that the server already escapes the output.
      If you do find a way to exploit it, please report it privately through the WordPress HackerOne program rather than in a public forum.

      Hope this helps!
Viewing 1 replies (of 1 total)

You must be logged in to reply to this topic.