Hello,
We’ve received a dependabot warning on CVE-2025-67288. The CVE mentions “<= v16.3.3”
I’m trying to understand to what degree this CVE affects v13 installations. If it does, can we expect an update to v13 as this is still in security phase?
Thank you for any advice.
That CVE is still work in progress. Because v14+ features a completely new backoffice, it isn’t certain that v13 would be affected.
I can confirm that Umbraco v13 is affected.
I uploaded the PDF file (success_xss.pdf) from CVE/CVE-2025-67288 at main · vuquyen03/CVE · GitHub
and the issue was successfully reproduced.
Umbraco 13 is still in security phase as you say, but we’re in the process of disputing this CVE, or at least getting it marked as a duplicate. As it’s not a new one to us.
For background Umbraco has historically not shipped with anything that interrogates the contents of files uploaded to the media section. We take the view that we can’t really know the level of security a customer wants, and what would be appropriate for the types of file they work with to provide a “sensible default”. E.g. if uploading large video files, something that has to load the contents of the file to validate them could be a very heavy operation.
Rather we provide a hook such that customers can add this validation if they want to, and it’s appropriate for them.
The documentation for this feature can be found here: Server-side file validation | CMS | Umbraco Documentation
There was also a recent forum discussion on the topic, with other suggestions for protection if a customer requires it, that you can find here: Umbraco Forms, Upload File.. any core protections against common exploits? - #7 by JasonElkin
Thank you for the clarification.
Just to walk this CVE back a bit…
It’s an attention grabbing PoC
But what does Umbraco have to do with that? You could upload the file anywhere - in fact, you can download the PoC file from GitHub… does that mean GitHub is vulnerable to a CWE-434…? No, and neither is Umbraco.
The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.
Emphasis mine, this doesn’t pass the test.
Now, let’s have a gander at the XSS (Cross Site Scripting) claim. Where does the JavaScript actually run? In the browser, sure, but it’s not run in the context of the Umbraco site. It’s sandboxed by the browser and not treated like it’s running on your domain..
It’s not JavaScript as we know it either. It doesn’t have access to any important browser APIs - i.e. no fetch() or document.cookies etc. in fact if you look at the alert itself you’ll see it’s calling app.alert()… that’s not a web browser API but a PDF one 
I’ve not got time to craft a PDF (especially one that I know won’t work) but you’ll quickly find that if you try and call any APIs that could present a real risk to the user that the browser will block it.
Even if you could, that CVE would really be the browser’s problem, not Umbraco’s.
Obviously there’s still a potential social engineering/phishing angle with these crafted PDFs… but that’s a whole different issue.
Edit: If anyone is feeling extra nerdy, here’s a fun design doc for the PDF Viewer in Chromium that talks about the sandboxing, what kinds of JavaScript execution are allowed, and why.
If anyone coming here would like an example implementation of an IFileStreamSecurityAnalyzer for scanning PDFs I’ve popped one in an article here: