CVE-2026-94077 in Safe SVG Plugin
Summary
by MITRE • 09/30/2026
Contributor Cross Site Scripting (XSS) in Safe SVG <= 2.5.0 versions.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability identified as Contributor Cross-Site Scripting within the Safe SVG plugin for WordPress, affecting versions up to and including 2.5.0, represents a significant security flaw rooted in insufficient input validation and output encoding mechanisms. This specific weakness allows attackers with contributor-level or lower privileges on a WordPress installation to inject malicious JavaScript code into web pages viewed by other users. The core of the issue lies in how the plugin handles SVG files uploaded through its interface. While Safe SVG is designed to sanitize SVG inputs to prevent server-side attacks such as XML External Entity (XXE) injections, it failed to adequately sanitize or encode specific attributes and event handlers within the SVG markup when rendered on the frontend. This oversight creates a pathway for stored cross-site scripting, where malicious scripts are permanently embedded in the site's content rather than being executed transiently through URL parameters.
From a technical perspective, this vulnerability aligns with CWE-79, which classifies Improper Neutralization of Input During Web Page Generation commonly known as Cross-Site Scripting. The flaw exploits the trust that WordPress administrators and other users place in user-generated content. When an attacker uploads a crafted SVG file containing embedded JavaScript event handlers or script tags within specific attributes like onerror or onload, the plugin's sanitization logic fails to strip these dangerous elements before they are outputted to the browser. Consequently, when another user views a post or page featuring this maliciously uploaded image, their browser executes the injected code in the context of the victim site. This allows the attacker to perform actions such as stealing session cookies, hijacking administrative sessions, defacing the website, or redirecting users to phishing sites.
The operational impact of this vulnerability is severe due to its low privilege requirement and stored nature. Unlike reflected XSS which requires tricking a user into clicking a malicious link, stored XSS persists on the server side. This means that every time an administrator or another contributor views content containing the infected SVG file, they are potentially compromised. In many WordPress environments, contributors have access to media libraries and can upload files without immediate editorial review if permissions are not strictly configured. The ability for lower-privileged users to execute arbitrary JavaScript undermines the principle of least privilege and compromises the integrity and confidentiality of the entire web application environment. Attackers can leverage this to escalate privileges by stealing cookies with administrative roles, effectively taking over the website control panel.
This vulnerability is also relevant to MITRE ATT&CK framework techniques related to Client-Side Injection and Web Session Manipulation. Specifically, it falls under T1059 which covers command and script interpretation via client-side execution, and can facilitate T1534 for internal spearphishing if used in conjunction with social engineering tactics within the organization's intranet or customer-facing portal. The persistence of the payload makes it particularly dangerous for long-term reconnaissance and lateral movement within a compromised network environment that relies on this WordPress instance as an entry point.
Mitigation strategies must focus on immediate remediation through software updates and enhanced configuration practices. Users running Safe SVG versions 2.5.0 or earlier should update to the latest patched version immediately, where developers have implemented stricter sanitization rules for SVG attributes and event handlers. Beyond updating, administrators should enforce strict media upload policies by disabling file uploads for contributor-level users if possible, restricting them to pre-approved assets only. Implementing a Content Security Policy (CSP) header can also mitigate the impact of successful XSS attacks by restricting the sources from which scripts can be loaded or executed, thereby preventing the malicious JavaScript from running even if it is injected into the DOM. Regular security audits and penetration testing should include checks for stored XSS vulnerabilities in media handling plugins to ensure that sanitization logic remains robust against evolving attack vectors.