CVE-2025-10573 is a stored cross-site scripting flaw in Ivanti Endpoint Manager 2024 SU4 and earlier, patched on 9 December 2025 in EPM 2024 SU4 SR1.
It is on this page not because of what happened — there is no confirmed exploitation in the wild, and this is a vulnerability disclosure rather than a breach — but because of what could have. It is the version of the Canvas architecture that a commercial buyer recognises immediately.
An unauthenticated POST, and then someone opens a dashboard
The vector was a crafted POST to /incomingdata/postcgi.exe, requiring no authentication at all. The injection points were device-related fields: Device ID, Display Name, OS Name.
The payload was stored directly in the EPM device database and sat there. It fired when an administrator opened the web dashboard and those fields were rendered.
At that point the attacker has the administrator's session in a product whose entire job is managing endpoints — which means authority over the machines it manages, the software deployed to them, and the security policies applied to them. One unauthenticated request to one CGI endpoint, and the blast radius is the estate.
This is the one that kills “we don't have user-generated content”
Ivanti had no forum. No comments. No support ticket queue anywhere in the payload path. What it had was device names.
Any field an untrusted system can write, and a privileged human later reads, is user-generated content.
- The definition worth adopting
Once you accept that definition, the list gets uncomfortable quickly: log viewers, asset inventories, error dashboards, webhook payloads, filenames, user agent strings, hostnames reported by agents. Most estates have far more of these than anyone has counted, and almost all of them are rendered in exactly the kind of internal tool whose session has reach.
The same three conditions as Canvas
Untrusted input, from a source requiring no authentication. Rendered in privileged tooling. In a session with authority far beyond the page it was displayed on.
Two products in two unrelated industries, arriving at the same architecture independently. That is what makes it worth writing down as a pattern rather than as two incidents.
A nonce-based policy is what breaks this chain. With script-src 'self' 'nonce-{random}' and no 'unsafe-inline', an injected script carries no nonce, so the browser refuses to run it — and the session it was reaching for is never taken. It does not matter which field the payload arrived in or which bug let it through.
The honest framing throughout this page is could have. Ivanti shipped a fix and there is no public evidence anyone was compromised through it. That does not make the shape of it any less instructive, and the window between a stored payload landing in a database and an administrator opening the page it renders on is precisely where reporting earns its place.
How we can help
The policy is the mitigation and the reporting is the detection, and it is the second half almost nobody switches on. Run CSP in report-only across the internal tools where untrusted content gets rendered, and an injected inline script announces itself the first time it fires — from the real session it fired in, with the page it fired on.
One line of code or config to deploy, and nothing is blocked while you learn what the policy would have caught. Reach out to sales@report-uri.com for a demo or a trial with no commitment.
