[GHSA-54mj-vcvj-q3v5] Umbraco CMS has an arbitrary file upload vulnerability

[legacy-git]

Updates

• Affected products
• CVSS v3
• CVSS v4
• Severity

Comments
Hi there!

I represent the security team at Umbraco HQ, and I have reviewed CVE-2025-67288 internally. I can conclude that this advisory describes a vulnerability that is already documented under CVE-2023-49279 and does not represent a new issue. The underlying root cause, exploitation conditions, and impact are identical to the earlier CVE. The only difference is the example file type referenced (PDF instead of SVG), but the issue is not file-type specific and has already been addressed as a class of behavior.

Additionally, the PDF-based example is technically inaccurate in modern browser environments. JavaScript execution in PDFs is sandboxed and does not allow access to cookies or meaningful browser context, meaning it does not meet the criteria for XSS in practice. This has been confirmed both through Chromium's security documentation and internal testing.

Because:

• The issue is a duplicate of CVE-2023-49279 (GHSA-6xmx-85x3-4cv2),
• No new attack surface or product behavior is introduced,
• The PDF example does not constitute a valid XSS vector
• CVE.org has already updated the CVE with the dispute (https://www.cve.org/CVERecord?id=CVE-2025-67288)
• It's stated in the official Umbraco CMS documentation that server-side file validation is the implementors own responsibility, since the CMS doesn't ship with a built-in mechanism.

I believe this advisory should be removed, or atleast merged with the existing CVE/advisory to avoid confusion and unnecessary concern for our users. Thank you!

Kind regards,
Anders
Umbraco Security Team

[Copilot]

Pull request overview

This pull request updates the security advisory GHSA-54mj-vcvj-q3v5 for Umbraco CMS by downgrading the severity assessment. According to the PR description, the Umbraco security team has determined this CVE is a duplicate of an existing CVE-2023-49279 and the PDF-based attack vector is not valid in modern browsers.

Key changes:

• Removes CVSS v3 scoring entirely
• Downgrades CVSS v4 score to reflect no actual impact (all metrics set to None)
• Changes severity rating from "MODERATE" to "LOW"

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[JonathanLEvans]

Hi @legacy-git,

I want to make sure I have this correct. Umbraco fixed CVE-2023-49279 by implementing the serverside-file-validation feature and documenting that administrators can block various file types. Umbraco leave the filter configuration to the administrator and does not block anything by default. This is why the researcher who found CVE-2025-67288 was able to upload a malicious PDF in a later, fixed version of Umbraco. Am I understanding correctly?

[legacy-git]

Hi @legacy-git,

I want to make sure I have this correct. Umbraco fixed CVE-2023-49279 by implementing the serverside-file-validation feature and documenting that administrators can block various file types. Umbraco leave the filter configuration to the administrator and does not block anything by default. This is why the researcher who found CVE-2025-67288 was able to upload a malicious PDF in a later, fixed version of Umbraco. Am I understanding correctly?

Hi Jonathan,

The documentation about serverside file validation is meant as a start to implement your own file validation mechanism. The patch for the previous CVE provided a hook to allow implementors to provide their own validation of the contents of uploaded files. Umbraco doesn't do anything with this out of the box, we just call the validators that are registered on upload, which by default will be an empty collection. We do that as we don't believe there's a sensible default to provide here, it all comes down to the depth of security the implementor wants and the types and sizes they expect to use and analyze.

Regarding CVE-2025-67288, it's by definition not an actual vulnerability, hence why we're requesting a removal/merge of this advisory. The PDF file the researcher used to test with, only triggered an alert box to pop-up on screen, but as PDF's are sandboxed in modern web browsers, they have no access to actual context and sensitive information from the Umbraco environment, such as cookies, access tokens or other important content. Because of this, you cannot use this exploit to do anything harmful. So in conclusion, the researcher did not upload a malicious PDF file. 😄

I hope this answered your question!

Best regards,
Anders
Umbraco Security Team

[advisory-database]

Hi @legacy-git! Thank you so much for contributing to the GitHub Advisory Database. This database is free, open, and accessible to all, and it's people like you who make it great. Thanks for choosing to help others. We hope you send in more contributions in the future!

[JonathanLEvans]

Hi @legacy-git,

Thank you for the clarification. We are going to keep the advisory as we consider insecure defaults for file uploads a security risk our users should be notified about. I have update the advisory to include your dispute.

[legacy-git]

Hi @legacy-git,

Thank you for the clarification. We are going to keep the advisory as we consider insecure defaults for file uploads a security risk our users should be notified about. I have update the advisory to include your dispute.

Hi Jonathan,

Thank you for your actions. While I completely understand the desire to inform users, I must maintain that this advisory is technically inaccurate.

For this to be a valid vulnerability, there must be demonstrable security impact, as there was in the duplicate advisory GHSA-6xmx-85x3-4cv2 (SVG file upload XSS). But the two are fundamentally different. SVG files execute JavaScript in the browser's full DOM context, meaning they can access cookies, make authenticated requests, and steal session tokens. That's why GHSA-6xmx-85x3-4cv2 was a legitimate vulnerability.

PDFs, on the other hand, run in a completely isolated sandbox with no capability of stealing cookies, making authenticated requests, or accessing session tokens. This is documented browser behaviour, not a vulnerability. If it were, Chrome itself would have a major security issue.

As this "vulnerability" has no actual impact, it doesn't meet the criteria for a CVE. I request that the description is at least corrected to remove the "arbitrary code execution" language, as it's demonstrably false and misleading, and that the severity is reconsidered.

I hope you understand.

Best regards,
Anders :)
Umbraco Security Team