GHSA-FFQ7-898W-9JC4: Stored Cross-Site Scripting via SVG Upload in DotNetNuke

DotNetNuke (DNN) exposes a stored Cross-Site Scripting (XSS) vulnerability within its file management and upload mechanisms, tracked as GHSA-FFQ7-898W-9JC4 and CVE-2025-48378. The vulnerability specifically affects the DotNetNuke.Core NuGet package across the 9.x and 10.x release branches. The flaw exists because the application allows authenticated users to upload Scalable Vector Graphics (SVG) files without sufficient content validation.

SVG files are constructed using XML and natively support the inclusion of executable scripting blocks via <script> tags, as well as embedded event handlers such as onload or onclick. When a web application serves an SVG file directly and allows the browser to render it inline, any embedded JavaScript executes within the origin of the hosting domain. The DNN platform historically implemented security checks to filter malicious content, but these mechanisms proved obsolete and failed to adequately parse and sanitize modern SVG structures.

Exploiting this vulnerability requires the attacker to possess an account with sufficient privileges to upload files to the platform. This is a common configuration in CMS environments where content editors, contributors, or forum members frequently share media. Once the malicious SVG is stored on the server, the payload remains dormant until accessed by a victim.

The core threat emerges when a user with administrative or SuperUser privileges views the uploaded file through the DNN file manager or via a direct URL. The browser processes the SVG instruction set, encounters the embedded script, and executes it. This execution context provides the attacker's script with access to sensitive session tokens, DOM data, and the ability to issue administrative requests on behalf of the compromised user.

The root cause of this vulnerability lies in the implementation of the file sanitization logic within the PortalSecurity component of the DNN framework. Prior to the patch, the application processed file uploads primarily by checking file extensions and applying a set of basic pattern-matching filters to the file contents. These filters were designed to identify standard HTML-based script injection vectors but failed to account for the unique structural properties of XML-based image formats like SVG.

Because SVGs are valid image formats, the platform's upload handlers accept them for storage in media directories. However, the system did not perform a rigorous XML Document Object Model (DOM) traversal to identify and strip nested script nodes or malicious attribute structures. Attackers bypass the rudimentary checks by leveraging XML namespaces or CDATA sections to obfuscate the <script> blocks from simple string-matching filters.

Furthermore, the application serves uploaded media files with headers that permit inline rendering in modern web browsers. If an SVG file is served with the Content-Type: image/svg+xml header and lacks restrictive Content-Disposition headers (such as attachment), the browser interprets the file as an active document rather than a static image. This rendering process natively executes any embedded ECMAScript.

The intersection of these three factors—permissive file upload policies, inadequate XML structural validation, and inline file rendering—creates the requisite conditions for stored XSS. The application relies on the assumption that an image file cannot contain executable code, an assumption that the SVG specification explicitly contradicts.

Analysis of the patch implemented in commit cfed83c291d5e5072b2fa70924a8b7c35b1cdf9e reveals a transition from basic pattern matching to a more robust, content-aware verification step. The vulnerability existed because the previous validation routines in PortalSecurity were marked as obsolete or simply bypassed during the file ingestion pipeline. The patch introduces specific parsing logic that evaluates the content of SVG files before they are written to the filesystem.

// Vulnerable pattern (Conceptual)
public bool IsValidFile(string filePath) {
    string extension = Path.GetExtension(filePath);
    if (extension == ".svg") {
        return true; // No structural validation performed
    }
    return BaseValidation(filePath);
}

The remediated code implements an explicit scanning phase that loads the SVG content and inspects it for known malicious vectors. This includes traversing the XML structure to detect <script> nodes, regardless of their namespace configuration, and identifying dangerous event-driven attributes (e.g., onload, onmouseover) attached to graphic elements. If these elements are detected, the system rejects the file upload entirely.

// Patched pattern (Conceptual)
public bool IsValidSvg(Stream fileStream) {
    XmlDocument doc = new XmlDocument();
    doc.Load(fileStream);
    XmlNodeList scriptNodes = doc.GetElementsByTagName("script");
    if (scriptNodes.Count > 0) {
        return false; // Reject payload
    }
    // Additional logic to scan for on* attributes
    return true;
}

While the patch effectively mitigates the primary attack vector, structural XML validation must be implemented carefully to avoid bypasses via XML Entity (XXE) injection or malformed encoding. The DNN maintainers addressed this by ensuring the XML parser is instantiated with secure defaults, disabling external entity resolution, and strictly validating the allowed elements within the SVG namespace.

Exploitation begins with the attacker crafting a malicious SVG payload. The file contains standard vector graphic elements to bypass visual inspection or basic file-type verification, combined with a nested script block. The attacker ensures the XML structure is valid so that the target browser parses it correctly upon rendering.

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
  <rect width="300" height="100" style="fill:rgb(0,0,255);stroke-width:3;stroke:rgb(0,0,0)" />
  <script type="text/javascript">
    alert('XSS execution: ' + document.cookie);
    // Attackers append logic here to issue authenticated requests to /API/ or /DesktopModules/
  </script>
</svg>

Once the payload is constructed, the attacker authenticates to the DNN instance using a standard user account. They navigate to a module that permits file uploads, such as user profile management, forum attachments, or a shared media folder. The attacker uploads the crafted SVG file, which the vulnerable server accepts and stores in the application's file repository.

To trigger the execution, the attacker must entice a privileged user to interact with the file. This is typically achieved by submitting a support ticket referencing the image, embedding the image in a public forum post, or simply waiting for an administrator to audit the file manager. When the victim's browser requests the file directly, it executes the JavaScript within the context of the dnnsoftware deployment.

> [!NOTE] > The execution occurs within the origin of the DNN platform. The script interacts directly with the DOM, allowing it to extract anti-CSRF tokens, read HttpOnly-flagged cookies (if misconfigured), and perform background XMLHttpRequests to administrative APIs.

The execution of arbitrary JavaScript within the security context of an administrator yields severe consequences for the integrity and confidentiality of the DNN instance. The attacker achieves full account takeover by instructing the script to extract session identifiers or perform actions on behalf of the victim. This effectively elevates the attacker's privileges from a standard user to a SuperUser, assuming an administrator views the payload.

With administrative access, the attacker can leverage standard DNN management interfaces to establish persistence or pivot further into the infrastructure. A common post-exploitation technique involves uploading a malicious DNN extension or module. Since administrators possess the authority to install extensions containing compiled .NET assemblies, the attacker escalates the XSS vulnerability into remote code execution (RCE) on the underlying Windows server.

The CVSS v4.0 score of 6.1 (Medium) reflects the necessity of user interaction and the requirement for an initial authenticated foothold. The vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N highlights the network-based attack surface and the significant impact on the secondary context (the user's browser session). Despite the medium numerical score, the practical risk is high for deployments allowing public registrations.

Organizations utilizing DNN for enterprise content management or public-facing portals face substantial exposure if file uploads are heavily utilized. The vulnerability demonstrates how a localized failure in input sanitization directly compromises the entire application hierarchy when administrative users participate in standard workflows.

The primary and most effective remediation strategy is upgrading the DNN installation to a patched version. Administrators managing deployments on the 10.x branch must update to DotNetNuke.Core version 10.2.2. Deployments operating on the older 9.x branch must be updated to version 9.13.9. These updates replace the obsolete validation routines with comprehensive SVG parsing logic.

For environments where immediate patching is not feasible, administrators must apply restrictive configuration changes to the file upload modules. Access controls should be modified to ensure that only highly trusted users (such as administrators themselves) possess the ability to upload files, particularly media formats. Furthermore, administrators can explicitly remove .svg from the list of allowed file extensions within the platform's global security settings.

Network-level mitigation involves deploying Web Application Firewall (WAF) rules designed to inspect multipart form data. Security engineers should construct rules that block any file upload containing the strings <script, javascript:, or onload= within the file contents. While WAF rules can be bypassed by advanced obfuscation, they provide a necessary layer of defense-in-depth.

Security teams should conduct proactive threat hunting by utilizing vulnerability scanners. Nessus plugin ID 237464 specifically detects outdated and vulnerable versions of the DNN platform. Additionally, system administrators should audit existing directories for previously uploaded SVG files and review their contents for embedded script tags to identify potential historical compromises.