You don’t need to worry about CVE-2025-45388
Here's why CVE-2025-45388 is bogus
On Friday morning (9th May 2025), the Wagtail Security Team were informed (through Google Alerts, rather than any official channel) that someone had issued a CVE, a security vulnerability identification number, for Wagtail for a vulnerability. CVEs are a surprisingly complex topic, but in short most security vulnerabilities in software are allocated a CVE to allow for easy referencing. Registering CVEs is a common process, and something we do whenever there’s a security release. But, this wasn’t requested by us. So what happened?
CVE-2025-45388 states that “Wagtail CMS 6.4.1 is vulnerable to a Stored Cross-Site Scripting (XSS) in the document upload functionality. Attackers can inject malicious code inside a PDF file. When a user clicks the document in the CMS interface, the payload executes”. Vulnerabilities like this do happen, and if true, it would be a big deal. But fortunately, after some digging, we traced the CVE back to a report the security team received back in March.
The short explanation is this: CVE-2025-45388 is not a new vulnerability in Wagtail, nor is it an exploitable vulnerability at all. Wagtail, in addition to your browser, is doing everything they can to protect you against this vulnerability, and no further action is needed.
You don't need to worry about it. But if you want to know more, here's the longer explanation.
The long explanation
Wagtail lets users (specifically, admin users) upload files. In the case of the Image Library, these are generally images. However, for Documents, they can be any kind of file. When serving these files back to users, care must be taken that a malicious actor can’t upload a file which lets them run arbitrary code on another user’s computer. For example, a malicious user could upload a HTML file which, when opened, executes an embedded script to steal their authentication details, impersonate the login form for their bank, or otherwise trick them into giving information they otherwise wouldn’t want to.
Wagtail is already doing everything it can to protect users from this class of vulnerability. The default project template excludes the common culprits such as HTML files. If the developer chooses to allow these, and Wagtail is serving the file itself, a Content-Security-Policy header is added to ensure files can’t execute any embedded scripts in the browser. However, the same protections can’t be added by Wagtail if it isn’t the one serving the file, such as when being served directly from AWS S3.
Instead, we document the risks and exactly how to mitigate them.
Last year, the Wagtail Security team discovered a case which the current protections don’t quite cover: PDFs. When Wagtail serves a HTML file with embedded javascript, the Content-Security-Policy prevents the javascript from executing. However, we learned not only that Javascript can be embedded in PDFs, but that a Content-Security-Policy doesn’t prevent these scripts from executing. Therefore, a PDF with embedded javascript in it will still execute.
And herein lies the crux of CVE-2025-45388. If a malicious user uploads a PDF with embedded javascript, and another user opens it, it executes the embedded script in their browser. And, worst still, conventional mechanisms to protect embedded scripts don’t work. That sounds terrible, right?
Well yes, but actually no.
Browsers to the rescue
On the surface, this would be a pretty severe vulnerability. But, as usual, your browser has your back!
This vulnerability hinges on the fact that, when viewing a PDF, the browser will open it itself and display the contents. The web browser is the gateway to the Internet - which is full of so many nasty things - so when it comes to security, browser makers generally know what they’re doing! All the major browsers are already aware of this class of vulnerability, and protect you against it. If the user downloads the file, rather than opening it in their browser, we’re falling back to the common practice of not opening arbitrary files you download off the internet.
“But!” I hear you cry, the reporter of CVE-2025-45388 showed a demo where the javascript is clearly executing and creating a popup in the browser. And you’re right. But, just because the script is executing, doesn’t mean it’s dangerous.
Both Chromium (the basis for Chrome, Edge and many other browsers) and Firefox run the JavaScript embedded in a PDF in a sandbox, which heavily restricts what it has access to - even more so than is allowed conventionally. In both cases, there’s no access to cookies, local storage, or even the network — just the PDF it’s running in. That means, even though there is technically a cross-site scripting vulnerability, executing JavaScript in this context won’t get you anything. And, if you were able to do something malicious with the JavaScript inside that sandbox, it would be a vulnerability in the browser itself, not Wagtail.
All that means is that while it’s possible to upload a PDF with embedded javascript in, it can’t do very much besides play Doom — it definitely can’t compromise your device.
And, if failing all that, a user does download the file and open it using a different PDF reader, then that probably has a sandbox as well, and wouldn’t have access to your browser and its precious cookies anyway. For example, GitHub uses a modified version of Firefox’s PDF viewer and completely disables JavaScript execution.
This is why we don’t consider this an exploitable vulnerability. While Wagtail doesn’t protect you from this specific issue, your PDF viewer does. It’s for this reason that we dismissed previous reports of this vulnerability, and in fact took the discussion public to collect more insight from the community.
Mitigations
If however you don’t trust me, or your browser, and want to be certain this class of vulnerability won’t affect your Wagtail admins or your users, there’s a simple solution.
By default, Wagtail lets your browser show a PDF inline, rather than forcing you to download it. That behavior can be changed with the WAGTAILDOCS_INLINE_CONTENT_TYPES setting. By explicitly setting it to an empty list (or removing application/pdf if you’re already defining it), Wagtail will send a Content-Disposition header which ensures PDFs are downloaded rather than immediately displayed. If you’re serving media directly from your storage, you’ll need to additionally configure that too.
Or, of course, you can prevent PDFs being uploaded in the first place using WAGTAILDOCS_EXTENSIONS.
Details on how to do this, and all the considerations when using remote storage can be found in our docs.
But what about the CVE?
As I’ve just explained, the Wagtail security team believes this CVE to be invalid. The report itself was hastily put together and lacks research into the affected versions, any mitigations or workarounds, or coordination with the upstream project. These are all things the Wagtail Security Team does when triaging, reporting, and publishing vulnerabilities.
We have already reached out to MITRE (the company who issued the CVE) to request it be revoked as invalid.
CVEs can be issued by any of a large number of organizations (known as CVE Numbering Authorities). The Wagtail project uses GitHub’s Security Advisories to record vulnerabilities, request CVE IDs and track both upcoming and historical vulnerabilities. Therefore, we let GitHub be the ones to issue our CVE IDs. CVEs issued by another authority do not come from us and should also be considered bogus. This CVE was allocated by MITRE, the largest Numbering Authority and operators of most of the CVE project.
The fact that anyone can approach any one of these Numbering Authorities, attempt to convince them they’ve found a vulnerability in a piece of software, and potentially be allocated one which is then made public, all without even talking to the upstream project may seem strange, but it’s how the CVE project operates. These “bogus” CVEs have bitten projects far larger than Wagtail — both curl and PostgreSQL have received them in the past.
Moving forwards
Unfortunately, now this CVE is published, it’s likely to appear in numerous vulnerability scans against Wagtail and related projects. Worst still, even if MITRE sides with us and revokes the CVE, there’s no guarantee that it will stop being flagged by automated scans. A stain on Wagtail’s otherwise excellent security track record.
If you receive an alert about CVE-2025-45388, it’s safe to ignore it. If you don’t want to ignore it, you can try the above mitigations to fix it. There’s also a discussion on GitHub.
If you’re reading this as a security vendor, consider excluding CVE-2025-45388 from your reports.
If you’re a CVE Numbering Authority, or are closely involved with the CVE project, it’s time for some change. If there’s a way to prevent unauthorized CNAs from issuing CVEs for our project, much like CAA records do for TLS certificates, we’d love to hear about it!
Until then, we’ll keep doing what we can to keep the Wagtail project secure.
This post was updated on 9-5-25. The following text is the initial version of the post:
The Wagtail security team has become aware of CVE-2025-45388, a bogus CVE filed by a security researcher against our advice. We have been researching this kind of cross-site scripting (XSS) issue in user-uploaded documents for a while, and don’t believe there is any exploitable vulnerability in Wagtail.
We recommend ignoring this bogus CVE, and will update this post with more information in due time.
The image for this post was generated with ChatGTP and DeepAI.
