Description

The Viable URL Media Uploader plugin for WordPress is vulnerable to Stored Cross-Site Scripting via SVG File uploads in all versions up to, and including, 1.0.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses the SVG file.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-09-30T09:17:11.883Z",
  "pubdate": "2026-09-30T09:17:11.883Z",
  "executiveSummary": "The Viable URL Media Uploader plugin for WordPress, in versions up to and including 1.0.0, contains a critical Stored Cross-Site Scripting (XSS) vulnerability.\nThis vulnerability stems from the plugin's failure to adequately sanitize or validate SVG file uploads. Because SVG files are XML-based documents, they can embed malicious JavaScript payloads that execute within the context of the user's browser when the file is accessed.\nThe vulnerability is exploitable by authenticated users holding Author-level privileges or higher. Successful exploitation allows an attacker to execute arbitrary scripts in the victim's browser session.\nThe implications of this vulnerability include potential session hijacking, unauthorized actions performed on behalf of an administrator, or the redirection of users to malicious third-party domains.\nGiven that the application does not implement strict content-type filtering or file content inspection for SVG uploads, the attack vector is highly reliable for authenticated attackers.\nMitigation is essential to prevent the persistence of malicious scripts within the media library and to ensure the integrity of the administrative interface.",
  "technicalDetails": "The vulnerability resides in the file upload processing logic of the Viable URL Media Uploader plugin. Specifically, the component responsible for handling media uploads fails to perform sufficient input sanitization or output escaping on user-provided SVG files.\nThe root cause is the handling of SVG files as simple image uploads without stripping embedded XML elements that support script execution. Since SVG is an XML-based format, it allows for the inclusion of <script> tags or event handlers (e.g., onload, onerror) within the file structure. When the WordPress media library serves this file, or when a user navigates directly to the file URL, the browser interprets the XML/SVG content and executes the embedded JavaScript.\nThe attack flow proceeds as follows: First, an authenticated attacker with Author-level access or higher accesses the plugin's media upload functionality. The attacker crafts a malicious SVG file containing a JavaScript payload. This file is uploaded to the WordPress server, where the plugin stores it without performing server-side sanitization to remove executable code.\nOnce the file is stored, the attacker can force a victim (such as an Administrator) to access the file via its direct URL. When the victim's browser loads the SVG, the embedded script executes within the context of the WordPress origin. This grants the attacker the ability to interact with the DOM of the target site, potentially capturing sensitive session cookies or performing actions via the WordPress REST API or Admin AJAX endpoints.\nBecause the vulnerability is stored in nature, the malicious payload persists on the server indefinitely until the file is manually deleted. This allows for long-term weaponization of the media library. The lack of output escaping ensures that the browser does not interpret the content as a neutral data object, but rather as executable code. This is particularly dangerous as it bypasses traditional WordPress security headers that might be configured to trust standard image formats, yet are often bypassed by SVG due to its XML nature.\nAuthentication is required to trigger the upload process; however, the Author role is common in multi-user WordPress environments, significantly expanding the potential attack surface. There is no requirement for network-level access beyond the ability to reach the WordPress administrative interface, making this a high-risk vector for internal or external attackers with valid credentials."
}