Urgent Security Advisory: Authenticated (Author) Stored XSS via SVG Upload in Easy SVG Support (≤ 4.0)

Author: Hong Kong Security Expert

Date: 18 Feb 2026

Affected plugin: Easy SVG Support (WordPress)

Vulnerable versions: ≤ 4.0

Fixed in: 4.1

CVE: CVE-2025-12451

Severity (site impact): Low (CVSS ~5.9) — context matters

Executive summary

Easy SVG Support up to version 4.0 fails to adequately validate and sanitize uploaded SVG files. An authenticated user with Author (or higher) privileges can upload crafted SVGs containing embedded script, event handlers, or javascript: URIs. When such SVGs are stored and later rendered in contexts that allow script execution, a stored Cross‑Site Scripting (XSS) condition can occur. Update to Easy SVG Support 4.1 or later as the definitive fix. If immediate update is not possible, apply the mitigations in this advisory.

What happened?

The plugin accepted and stored SVG files without sufficient server-side sanitization. An authenticated user with the ability to upload media can embed executable constructs in an SVG. When an administrator or other privileged user views the page or media item where the SVG is rendered inline, the embedded script can execute in that user’s browser, potentially performing actions in the context of their session.

• Attack vector: Authenticated upload of a crafted SVG file.
• Required privilege: Author (authors can upload media by default on many WordPress sites).
• Exploit type: Stored XSS in site content delivered to other users (including admins).
• Fixed in: Easy SVG Support 4.1.
• Detection indicators: SVG attachments containing <script> elements, attributes beginning with “on” (onload, onclick), or javascript: URIs.

Why SVG is dangerous if not sanitized

SVG is XML-based and supports scripting, event attributes, external references, and embedded HTML via foreignObject. If an application stores and serves SVGs without removing unsafe constructs, browsers may execute scripts inside the SVG depending on how it is embedded. Common implementation mistakes include relying on extension or client-side checks only, failing to strip script elements or event attributes, and serving SVGs inline without mitigation (CSP, sanitization, or rasterization).

Immediate actions for site administrators (step‑by‑step)

Follow these steps in order of priority:

1. Update the plugin. Upgrade Easy SVG Support to 4.1 or later as soon as possible. This is the definitive remedy.
2. If you cannot update immediately — apply mitigations:
   • Disable SVG uploads temporarily.
   • Restrict upload capability to administrators only.
   • Apply server-side rules to block SVG uploads that contain <script>, event attributes, or javascript: URIs (virtual patching via WAF or server filters).
3. Scan for existing malicious SVGs:
   • Search the Media Library for .svg files and inspect contents.
   • Use WP‑CLI or direct SQL queries to locate attachments and posts containing SVG content or script tags.
   • Remove, quarantine, or sanitize suspicious SVGs.
4. Rotate high‑privilege credentials if compromise is suspected:
   • Change administrator passwords and revoke stale sessions.

Quick playbook — disable SVG uploads

If you need to block SVG uploads immediately, add a site-specific plugin or an mu-plugin with one of these examples. Editing theme functions.php on a live site can be risky; prefer an isolated plugin.

<?php
// Disable .svg uploads (blocks MIME type)
add_filter( 'upload_mimes', function( $mimes ) {
    if ( isset( $mimes['svg'] ) ) {
        unset( $mimes['svg'] );
    }
    if ( isset( $mimes['svgz'] ) ) {
        unset( $mimes['svgz'] );
    }
    return $mimes;
}, 10, 1 );
?>

To remove upload capability from the Author role (evaluate impact on workflows):

<?php
// Remove upload capability from author role (site owner decision required)
function remove_author_uploads() {
    $role = get_role( 'author' );
    if ( $role && $role->has_cap( 'upload_files' ) ) {
        $role->remove_cap( 'upload_files' );
    }
}
add_action( 'init', 'remove_author_uploads' );
?>

Caveat: removing upload capability affects legitimate content workflows. Communicate and plan changes with content teams.

How to search for suspicious SVGs and stored XSS

Use these detection steps; always work on a backup or staging copy when running DB queries.

WP‑CLI

wp db query "SELECT ID, post_title, guid FROM wp_posts WHERE post_type = 'attachment' AND guid LIKE '%.svg%';"

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<svg%' AND post_content LIKE '%script%';"

SQL

SELECT ID, post_title FROM wp_posts
WHERE (post_content LIKE '%<svg%' OR post_content LIKE '%src="%.svg%')
  AND (post_content LIKE '%<script%' OR post_content LIKE '%onload=%' OR post_content LIKE '%javascript:%');

Manual inspection

For each SVG found, open it in a text editor and look for:

• <script> tags
• on* event attributes (onload, onclick)
• javascript: URIs
• foreignObject blocks that include HTML

Server-side upload validation and sanitization (for developers)

Server-side validation is mandatory. Do not rely on file extension or client-side checks alone.

Validate MIME type using finfo:

$finfo = new finfo(FILEINFO_MIME_TYPE);
$mime = $finfo->file( $uploaded_file_path );
if ( $mime !== 'image/svg+xml' ) {
    // reject or handle accordingly
}

Sanitize the SVG by parsing XML and removing unsafe constructs: remove <script>, strip attributes that start with “on”, remove javascript: URIs, and strip external script references. Prefer well-maintained sanitizer libraries rather than ad-hoc code.

function sanitize_svg_string( $svg_string ) {
    // Use DOMDocument or an XML parser to parse and remove dangerous elements/attributes
    $dom = new DOMDocument();
    libxml_use_internal_errors(true);
    $dom->loadXML( $svg_string, LIBXML_NOENT | LIBXML_DTDLOAD | LIBXML_NOERROR | LIBXML_NOWARNING );

    // Remove all <script> elements
    while ( $script = $dom->getElementsByTagName('script')->item(0) ) {
        $script->parentNode->removeChild( $script );
    }

    // Remove any attributes that start with "on" (onload, onclick, etc.)
    $xpath = new DOMXPath($dom);
    foreach ( $xpath->query('//@*') as $attr ) {
        if ( preg_match('/^on/i', $attr->nodeName) ) {
            $attr->ownerElement->removeAttributeNode( $attr );
        }
        // Remove javascript: URIs
        if ( stripos( $attr->nodeValue, 'javascript:' ) !== false ) {
            $attr->ownerElement->removeAttributeNode( $attr );
        }
    }

    return $dom->saveXML();
}

Warning: building your own sanitizer carries risks (XML entity expansion, XXE). Use a vetted library where possible.

Server filtering / WAF rules (conceptual)

Server-side rules can provide virtual patching while you update and clean sites. Example detection concepts:

• Block uploads with Content-Type image/svg+xml if file contains <script or on[a-z]+= attributes.
• Detect <svg … <script … > patterns: /<svg[\s\S]*?<script[\s\S]*?>/i
• Detect event handler attributes: /(?i)\bon[a-z]+\s*=/
• Detect javascript: URIs: /(?i)javascript\s*:/

Apply a layered approach: block high-confidence matches and log lower-confidence hits for manual review. Avoid overly broad blocking that disrupts legitimate vector usage.

Hardening recommendations (short, medium, long term)

Short term (days)

• Update plugin to 4.1 immediately if possible.
• Temporarily disable SVG uploads or restrict them to administrators.
• Apply server filtering rules to block SVGs containing scripts/events.
• Scan the Media Library and quarantine suspicious files.

Medium term (weeks)

• Enforce server-side sanitization for accepted SVGs.
• Remove execute permissions in upload directories and disallow execution of uploaded files.
• Deploy Content-Security-Policy headers to reduce inline script execution risk (test thoroughly).

Long term (months)

• Implement an approval workflow for vector graphics from untrusted contributors.
• Consider rasterizing SVGs to PNG/JPEG where vector is unnecessary.
• Limit upload privileges by role and enforce least privilege.

Incident response — if you find malicious uploads or suspect compromise

1. Immediate containment:
   • Remove or replace malicious files from the Media Library.
   • Update or disable the vulnerable plugin.
   • Revoke admin sessions and rotate credentials if session hijack is suspected.
   • Consider taking the site into maintenance mode for triage if needed.
2. Forensics:
   • Export server logs covering the upload time window (POSTs to /wp-admin/async-upload.php).
   • Identify uploader username, IP, and timestamps.
   • Look for unexpected admin actions around the time of upload.
   • Search for additional webshells or modified files.
3. Remediation:
   • Remove malicious SVGs and sanitize affected content.
   • Update plugin to the fixed version.
   • Change passwords for affected accounts and rotate API keys.
   • Clean up backdoors and remove unknown admin accounts.
4. Post-incident hardening:
   • Implement scanning and monitoring for uploads.
   • Enforce server-side sanitization and improved workflows for uploads.

Detection rules and monitoring ideas

Suggested automated checks:

• Scheduled job scanning new uploads for <script> tags, attributes starting with “on”, and javascript: URIs.
• Alert when a non-admin role performs an SVG upload.
• Monitor admin dashboard for unusual XHRs or unexpected POSTs.
• Log and review uploads with suspicious filenames or content.

// Periodic scan example (pseudo-code)
$attachments = get_posts([
    'post_type' => 'attachment',
    'post_mime_type' => 'image/svg+xml',
    'numberposts' => -1
]);

foreach ( $attachments as $att ) {
    $file = get_attached_file( $att->ID );
    $content = file_get_contents( $file );
    if ( preg_match('/<script\b/i', $content) || preg_match('/\bon[a-z]+\s*=/i', $content) || stripos($content, 'javascript:') !== false ) {
        // Alert: suspicious SVG found
    }
}

Guidance for plugin authors and maintainers

1. Avoid enabling SVG uploads unless you can sanitize them properly. If vector features are unnecessary, convert to raster images on upload.
2. Perform strict MIME detection and content scanning server-side (finfo or similar).
3. Use a maintained SVG sanitizer library. Test with malicious payloads and edge cases.
4. Restrict upload privileges to trusted roles and document your security approach.
5. Use CSP headers to reduce inline script risk where feasible.

Risk assessment — how bad is this on your site?

The practical impact of stored XSS depends on user roles and viewing patterns. If only unprivileged visitors view compromised SVGs, the effect may be defacement or client-side attacks. If administrators view the content, an attacker could perform actions in the admin session, elevating the severity. Treat this issue urgently if upload rights are broadly granted or admins routinely review user-submitted media.

Real-world prevention examples

• Replace uploaded SVGs with sanitized versions and quarantine originals until approved.
• Rasterize SVGs at upload time and serve raster images publicly; keep SVGs only when trusted.
• Enforce an upload workflow: upload → automatic scan/sanitize → admin approval for embedding.

Final checklist — what to do now

1. Update Easy SVG Support to 4.1 immediately.
2. If you cannot update right away:
   • Disable SVG uploads or restrict them to administrators.
   • Apply server filtering/WAF rules to detect and block SVGs with scripts or event attributes.
3. Scan your Media Library and posts for <script> fragments in SVGs, on… attributes, and javascript: URIs.
4. If you find suspicious content: remove/quarantine malicious files, rotate credentials, revoke sessions, and scan for other indicators of compromise.
5. Implement longer-term protections: server-side sanitization, CSP, role hardening, and upload approval workflows.

Closing notes

Stored XSS via file upload recurs because formats like SVG mix data and executable constructs. Treat any plugin that enables SVG uploads with caution: sanitize on the server, restrict who can upload, and monitor uploaded content. Patches are released, but attackers act quickly when disclosures appear — virtual patching and scanning buy time while you update and clean affected sites.

If you need specialist assistance, engage a qualified security consultant or incident response team to help with triage and remediation.

Stay vigilant,

Hong Kong Security Expert