Umbraco is a wildly popular, open-source content management system (CMS) built on Microsoft’s .NET tech stack. Its easy-to-use “backoffice” panel helps content creators and site editors manage web pages, media, and more. But recently, a critical security vulnerability—CVE-2025-27602—was found in Umbraco’s backoffice API, putting sensitive content and media at risk of unauthorized access and deletion.

In this post, I’ll explain what the bug is, show how it works using code snippets, provide the latest references, and lay out the impact. My write-up is based on details from the official Umbraco security advisory and CVE records.

What Is CVE-2025-27602?

In every CMS, access control is key: only users with the right role or group should modify or even view certain pages and files. In Umbraco, admins assign permissions to users based on their jobs—like editors, writers, or admins.

Due to a flaw in the backoffice API access checks, *authenticated* users could craft API requests that let them:

Bypass folder-level restrictions.

> 🚨 The vulnerable versions are Umbraco prior to 10.8.9 and 13.7.1. If you’re running anything older, you are at risk.

No simple settings fix or workaround exists—patching is the only option.

Technical Deep Dive: How the Attack Works

The bug lies in the way Umbraco's backoffice API endpoints handle permission checks for folders containing content or media.

Intended Behavior:
When a user (e.g., an editor) with limited access visits the backoffice, Umbraco's UI only shows folders/items they’re authorized to see or manage.

Buggy Reality:
If the user directly calls certain API URLs (by manipulating a GET or DELETE request), the backend fails to properly check folder access.

So, even with limited UI access, the editor can

- Fetch (download) content/media from blocked folders.

Sample Exploit

Below is a code snippet using plain curl to get or delete protected content. In practice, you’d need a valid backoffice auth token (your own session cookie), but that’s all—no high privileges required!

Step 2: Fetch restricted media using a crafted ID

curl -X GET \
  'https://example.com/umbraco/backoffice/UmbracoApi/Media/GetById?Id=1234'; \
  -H 'Cookie: .AspNetCore.Cookies=YOUR_SESSION_TOKEN'

Step 3: Delete restricted page/content

curl -X DELETE \
  'https://example.com/umbraco/backoffice/UmbracoApi/Content/DeleteById?Id=5678'; \
  -H 'Cookie: .AspNetCore.Cookies=YOUR_SESSION_TOKEN'

Normally, both requests should fail for users without rights to IDs 1234 or 5678—*but on vulnerable versions, they succeed.*

Note: You need to know or guess the internal IDs of the target media/content, which can often be enumerated or leaked.

Any site running Umbraco versions prior to 10.8.9 (v10) or 13.7.1 (v13)

- Environments where editors, designers, or other low-privilege authenticated users have backoffice access

Accidentally (or purposely) delete irreplaceable files or media

Since the exploit requires no admin powers—just basic backoffice login—the risk is serious in shared editorial teams.

Umbraco 13.7.1 or newer

> See advisory:
> https://umbraco.com/blog/security-advisory-vulnerabilities-in-umbraco-cms/

No workarounds: There are no reliable configuration fixes or permission tweaks until you upgrade.

References

- Umbraco Security Advisory June 25, 2024
- CVE-2025-27602 (NVD)
- Mitre CVE Record

Final Notes

If you run Umbraco and have trusted even “low-level” editors with backoffice rights, patch urgently. This kind of lateral privilege abuse is exactly what data breach attackers look for.

Check your Umbraco version—update if needed, and monitor your audit logs for suspicious API calls on protected content or folders.

If you have further questions, see the official Umbraco Security Portal or subscribe to their security mailing list.

Timeline

Published on: 03/11/2025 16:15:18 UTC