Please note that these vulnerabilities are unrelated to the recently reported PHP security vulnerability. Umbraco depends on a different framework ( .NET).
What’s affected?
Umbraco CMS
Affected Product Version Range:
17.x up to 17.7.1
18.x up to 18.2.1
Affected Product Version Range:
17.x up to 17.7.1
18.x up to 18.2.1
Affected Product Version Range:
13.x up to 13.16.3
17.x up to 17.7.1
18.x up to 18.2.1
Affected Product Version Range:
17.x up to 17.7.1
18.x up to 18.2.1
Umbraco Forms
Affected Product Version Range:
13.0.0 - 13.9.11
17.0.0 - 17.6.1
18.0.0 - 18.2.1
Affected Product Version Range:
13.0.0 - 13.9.11
17.0.0 - 17.6.1
18.0.0 - 18.2.1
Umbraco AI
Affected Product Version Range:
Umbraco. AI.Core: 1.0.0 - 17.6.0 and 18.0.0 - 18.6.0
Umbraco. AI.Agent: 1.1.0 - 17.4.0 and 18.0.0 - 18.4.0
Umbraco. AI.Agent.Deploy: 1.0.0-beta2 - 17.1.0 and 18.0.0 - 18.1.0
Umbraco. AI. Deploy: 1.0.0-beta1 - 17.3.0 and 18.0.0 - 18.3.0
Umbraco. AI. Search: 1.0.0-beta1 - 17.0.4 and 18.0.0 - 18.0.4
How to fix the vulnerability
If you’re using Umbraco CMS 13, 17 or 18, Umbraco Forms 13, 17 or 18, or Umbraco AI 17 or 18, you can upgrade to a new patch version of these releases the way you would normally upgrade.
Umbraco CMS patched versions: 13.16.3 (Umbraco CMS 13 is affected by one Moderate severity issue only), 17.7.2 and 18.2.2.
Umbraco Forms patched versions: 13.9.12, 17.6.2, and 18.2.2.
Umbraco AI patched versions:
Umbraco. AI.Core: 17.6.1 and 18.6.1
Umbraco. AI.Agent: 17.4.1 and 18.4.1
Umbraco. AI.Agent.Deploy: 17.1.1 and 18.1.1
Umbraco. AI.Deploy: 17.3.1 and 18.3.1
Umbraco. AI. Search: 17.0.5 and 18.0.5
How do you check which version you are on? Reach out to your technical contact for your Umbraco site with this blog post, and they will be able to take care of the necessary precautions.
If your project is on Umbraco Cloud
If your Umbraco project is hosted on Umbraco Cloud, an automatic upgrade will be rolled out today to fix the vulnerabilities for Umbraco CMS and Umbraco Forms - no action needed. If you’re running Umbraco AI on your Cloud project(s), this fix needs to be implemented manually, as it’s an add-on to your Umbraco Cloud setup.
If you cannot upgrade immediately
Upgrading is the only complete fix. The following interim measures reduce exposure until you can upgrade:
Umbraco CMS, backoffice sign-in (GHSA-rpv9-qp4c-g469): Restrict the host names that reach the application. For example, set AllowedHosts in appsettings.json to the site’s own host names, separated by semicolons, or bind the web server or reverse proxy to explicit host names so requests for any other host are rejected before they reach Umbraco. Avoid opening back-office links from untrusted sources while signed in to the backoffice.
Umbraco CMS, media (GHSA-88p9-4pxf-pq3c): Limit permission to create and update media to trusted users, and avoid opening links to files on media items that have been updated by users who are not fully trusted.
Umbraco CMS, website preview and Delivery API (GHSA-24m3-86rh-6888): Avoid relying on start nodes alone to keep unpublished content confidential from other back-office users. If the Delivery API is not required, consider disabling it or not exposing it publicly.
Umbraco CMS, preview tokens (GHSA-4vcm-wj6q-3pmg): You can invalidate a user’s existing preview tokens by disabling or locking out the account. Changing the user’s password does not invalidate them.
Umbraco CMS, start-node lookups (GHSA-xqwv-jvcm-5vjq): Avoid relying on start nodes alone to keep sensitive files in the media library, or the names of content, confidential from other back-office users.
Umbraco Forms, entries and exports (GHSA-56r2-v3fp-wj6h): Grant the Forms section only to users who are allowed to see the entries of every form. Turning off View Entries, or denying access to individual forms, does not prevent the access described in this advisory on unpatched versions.
No workaround is documented for the remaining issues (GHSA-4qmm-fhgv-vq9g, GHSA-r4qv-c8pg-qq59, GHSA-6mm6-h9v6-mjmp, GHSA-xc89-5cg7-36xf); upgrading is the recommended action.
What if I’m on an unsupported version?
Umbraco 14, 15, and 16 have reached End-of-Life (EOL) and will not receive a patch for the Umbraco CMS and Umbraco Forms issues. Unsupported versions can be subject to the vulnerability, but will not receive a patch. If you are running a version that is past End-of-Life, the recommended path is to upgrade to a supported major version - Umbraco 17 (LTS) or Umbraco 18. You can check the support status of your version on our Long-term Support and End-of-Life page. Feel free to book a discovery call with us to talk about your options.
What we know about the vulnerabilities
Umbraco CMS: Back-office account takeover via sign-in redirect manipulation (GHSA-rpv9-qp4c-g469)
Several weaknesses in the back-office sign-in flow could be combined so that a back-office user’s session was handed to an attacker. If the attack succeeded, the attacker got an authenticated back-office session with the privileges of the user who opened the attacker’s link. If that user was an administrator, the attacker got full control of the backoffice, including reading and changing all content, users and configuration, and potentially running code on the server through features available to administrators.
No account is needed to prepare the attack, but a signed-in back-office user has to open a link supplied by the attacker. Sites are exposed to the full chain where the web server or hosting setup passes requests for unrecognised host names through to Umbraco. This is common when Umbraco runs on Kestrel directly, in IIS without host name bindings, or behind a reverse proxy that forwards the Host header unchanged. Sites where only the expected host names reach the application are not exposed to the full chain. The patch also protects sites whose stored sign-in configuration was tampered with before the upgrade; the GitHub advisory describes how to check for this.
The severity of this vulnerability is: High (CVSS 8.8). It can be prepared over the network without an account and with low complexity, and a successful attack can compromise confidentiality, integrity and availability. It does require a signed-in back-office user to open a link supplied by the attacker.
Umbraco CMS: Stored XSS chained with path traversal in media management (GHSA-88p9-4pxf-pq3c)
A weakness in how Umbraco CMS validated and displayed media file information allowed stored cross-site scripting in the backoffice. Script injected this way ran with the privileges of the back-office user who interacted with the media item. If that user was an administrator, this could lead to privilege escalation and to content or configuration being read or changed.
Exploitation requires a valid back-office account with permission to update media, which includes the default user groups, and another back-office user has to interact with the affected media item. It cannot be exploited anonymously. A Content-Security-Policy reduces, but does not remove, the exposure and should be treated as defence in depth, not as a substitute for upgrading. The patch also protects media items that were saved with malicious file information before the upgrade; the GitHub advisory describes how to check whether any exist.
The severity of this vulnerability is: Moderate (CVSS 5.4). It needs an authenticated account and another user to interact with the media item, but the injected script runs in the context of that other user.
Umbraco CMS: Backoffice logout does not invalidate the auth cookie (GHSA-4qmm-fhgv-vq9g)
Signing out of the backoffice did not end the user’s session on the server. A back-office authentication cookie obtained before sign-out kept granting back-office access until it expired.
An attacker who had already obtained a user’s back-office cookies, for example from a shared or unattended device or through another vulnerability, could keep using them after the user signed out, without knowing the user’s password. The attacker gets the same access as the signed-out user, including administrator rights if the user is an administrator. Default configurations are affected.
The severity of this vulnerability is: Moderate (CVSS 4.8). The attacker must already have the cookie, which makes the attack complex to carry out, but users who sign out expect their session to end and may consider themselves protected when they are not.
Umbraco CMS: Unpublished content exposed through website preview and the Delivery API (GHSA-24m3-86rh-6888)
A back-office user restricted to a content start node could view the unpublished content of documents outside their start nodes using website preview, including documents they did not have browse permission for. In Umbraco 18, the same applied to library elements outside the user’s element start nodes. Separately, on sites with the Delivery API enabled, the names of documents with unpublished changes could be included in Delivery API responses where those documents were linked from published content, and for a period afterwards could be returned to other callers, including anonymous ones. Preview is read-only, so none of this allowed content to be changed.
The user has to be authenticated to the backoffice and must have opened preview at least once. Sites that do not use start nodes or permissions to separate users are not affected by the preview issue, and sites that do not enable the Delivery API are not affected by the Delivery API issue. Published content is not affected.
The severity of this vulnerability is: Moderate (CVSS 4.3). It needs a back-office account and only exposes unpublished content or names in a read-only way.
Umbraco CMS: Website preview session did not expire (GHSA-4vcm-wj6q-3pmg)
The token that enables website preview for a back-office user did not expire, and it remained valid when the user’s password was changed. Anyone who obtained a copy of a user’s preview token could keep viewing unpublished content as that user until the account was disabled, locked out or deleted. On sites protected by basic authentication (Umbraco 17.7.0 and later, and 18.2.0 and later), a copied preview token also let requests through basic authentication.
To exploit the issue, an attacker first needs a copy of a user’s preview token, for example from the user’s browser or from intercepted traffic. It cannot be exploited anonymously without one. Preview is read-only and gives no access to the backoffice or the Management API.
Behaviour change: the preview token now expires after the back-office login timeout (20 minutes by default) and stops working when the user’s password, login or email changes. Preview tokens issued before the upgrade are no longer accepted, so users who are previewing when the site is upgraded need to start preview again.
The severity of this vulnerability is: Low (CVSS 3.7). The attacker must already hold a copy of the token, and the exposure is limited to read-only access to unpublished content.
Umbraco CMS: Backoffice users can grant user groups start nodes outside their own access (GHSA-r4qv-c8pg-qq59)
An authenticated back-office user with access to the Users section could create or update a user group so that it had content or media start nodes the user could not access themselves. The server-side check meant to prevent this was not enforced when “Allow access to all documents/media” was selected, and in Umbraco 18 the equivalent check was missing for Elements. This allowed privilege escalation beyond the user’s assigned start nodes, including self-escalation by editing their own user group, and then reading, editing, publishing or deleting content they were never meant to reach.
This affects installations where back-office users are deliberately limited to parts of the content or media tree, for example per-site, per-department or per-tenant editors, and in Umbraco 18 installations that restrict access to Elements. It requires an authenticated back-office user with access to the Users section and permission to create or edit users or user groups.
The severity of this vulnerability is: Moderate (CVSS 6.5). It requires a high-privilege account, but it breaks content isolation between restricted editors and administrators, with high impact on confidentiality and integrity of the affected content.
Umbraco CMS: Start-node restrictions not enforced on URL, imaging and reference lookups (GHSA-xqwv-jvcm-5vjq)
A back-office user restricted to a media start node could retrieve the file URL of media items outside their start nodes through two Management API endpoints that resolve media URLs. Media files are served as static files, so a user who obtained such a URL could download the file. A user restricted by a content, media or element start node could also list the items that reference a document, media item or element outside their start nodes, including the referencing items’ names, publish state and types. A related endpoint listed the relations of a relation type to any user with access to the Content section, rather than only to users with access to Settings. Nothing could be changed, and no property values could be read through the reference lookups.
The user has to be authenticated to the backoffice and must already know the identifier of the item they target. Sites that do not use start nodes to separate users are not affected.
The severity of this vulnerability is: Moderate (CVSS 4.3). It needs a back-office account and knowledge of the item’s identifier, and the exposure is limited to reading file URLs and reference metadata.
Umbraco Forms: Form workflow settings can write and render a server-side Razor view, enabling remote code execution (GHSA-6mm6-h9v6-mjmp)
Some built-in workflow steps in Umbraco Forms did not place enough restriction on the files they write and the server-side templates they render. A back-office user who can configure a form’s workflows could arrange for content submitted through the form to be written to the server and then run as server-side code with the privileges of the application. That allows reading and changing files the application can reach, running processes and making network connections from the server.
By default, any back-office user with access to the Forms section is permitted to manage forms, so this does not require administrator rights, nor the separate Settings access that normally allows editing templates or other server-side code. The code runs where the application compiles views at runtime, which is the case in the product’s default runtime mode. The two non-default runtime modes do not run it, although the insecure file is still written in every mode, and a site that has enabled runtime view compilation by other means is affected in any mode. Sites where more than one person can manage forms and those people are not already trusted with server-side code are impacted; sites where every form manager is an administrator or otherwise fully trusted are not meaningfully affected. We are deliberately not publishing configuration or reproduction details while sites remain unpatched.
The severity of this vulnerability is: High (CVSS 8.8). It can be exploited over the network by a low-privilege account with low complexity and no user interaction, and it allows code execution with full impact on confidentiality, integrity and availability.
Umbraco Forms: Form entries, entry exports and form definitions readable without the matching permissions (GHSA-56r2-v3fp-wj6h)
Several Management API endpoints authorised requests on Forms section access alone, without applying the user’s Forms permissions to the form being requested. As a result, a back-office user with access to the Forms section could:
generate and download an export of a form’s entries without the View Entries permission;
list and export the entries of forms they had been denied through Forms security, or whose start folders did not include them;
download an export generated earlier by another user, which could include sensitive field values the downloading user is not allowed to see; and
with the Manage Forms permission, download the definition of a form they had been denied, including its workflow settings, which can hold credentials such as webhook URLs or API keys.
Umbraco Forms 13 is affected by the first three items; the form definition item does not apply to 13.x. Related checks are also enforced in the patched versions: copying, moving, creating, saving, importing and restoring forms, and creating and moving folders, now respect the user’s per-form access and start folders.
Exploiting the issue requires an authenticated back-office user with access to the Forms section. Installations where only fully trusted users have the Forms section are not exposed beyond those users’ existing access. Form entries can contain personal data, so affected installations should treat the stored entries of all forms as potentially readable by every user with access to the Forms section.
Behaviour changes after upgrading:
Generating or downloading an entries export requires the View Entries permission and access to the form.
Exports are stored per user, and a user can only download exports they generated themselves. Exports generated before the upgrade can no longer be downloaded and are removed by the normal temporary-file cleanup.
All entry endpoints, and form definition export, return 403 for forms the user cannot access through Forms security or their start folders.
A user with exactly one start folder who copies, moves or creates an item at the root has it placed in their start folder. A user with several start folders can no longer place items at the root.
The severity of this vulnerability is: Moderate (CVSS 6.5). It requires an authenticated back-office account, but form entries can contain personal data, so the impact on confidentiality is high.
Umbraco AI: Authorization and credential-handling issues in AI agent tools and Deploy integrations (GHSA-xc89-5cg7-36xf)
Several Umbraco AI components did not enforce the permissions configured for back-office users when AI agents read or changed content:
Agent tools that read content and media ignored the user’s start nodes and item permissions, including for unpublished drafts and for pages protected for website members.
Agent tools that create and change content and media did not check whether the user has access to the Content or Media section.
Per-user-group tool restrictions were not applied to the assistant’s in-editor editing, saving and publishing tools when these were granted as a tool group.
Per-user-group tool restrictions for custom user groups stopped applying after an agent was deployed to another environment with Umbraco Deploy.
Separately, the Umbraco Deploy integration wrote AI provider credentials, such as API keys, unencrypted to deployment files, which are usually committed to source control. If your deployment files containing AI provider credentials were committed to source control, we recommend rotating those keys after upgrading.
A back-office user who can use an agent with these tools enabled could read or change content and media beyond their permissions. Anyone with access to a site’s source repository could read its AI provider credentials. None of the issues can be exploited anonymously, and the content and media agent tools are not enabled by default.
The severity of this vulnerability is: Moderate (CVSS 6.5). It requires an authenticated back-office account or access to the source repository, and the affected tools are not enabled by default, but it can expose content and credentials with high confidentiality impact.
Credit
We’d like to thank Joe, Damien and the team at umbra.cooties.io for reporting the Umbraco CMS vulnerability “Back-office account takeover via sign-in redirect manipulation”.
We’d like to thank am7maaz for reporting the Umbraco CMS vulnerability “Stored XSS chained with path traversal in media management”.
We’d like to thank rafal-woznicki for reporting the Umbraco CMS vulnerability “Backoffice logout does not invalidate the auth cookie”.
We’d like to thank shirabe0x05 and ffasterss (Omoikane Labs) for reporting the Umbraco CMS vulnerability “Unpublished content exposed through website preview and the Delivery API”.
We’d like to thank ma4ter for reporting the Umbraco CMS vulnerability “Backoffice users can grant user groups start nodes outside their own access”.
We’d like to thank shirabe0x05 and ffasterss (Omoikane Labs) and Matt Perry (Original Objective) for reporting the Umbraco CMS vulnerability “Start-node restrictions not enforced on URL, imaging and reference lookups”.
We’d like to thank Lucas Teste (Soluss SA) for reporting the Umbraco Forms vulnerability “Form workflow settings can write and render a server-side Razor view, enabling remote code execution”.
We’d like to thank Petr Tomek (COMGUARD a.s.) for reporting the Umbraco Forms vulnerability “Form entries, entry exports and form definitions readable without the matching permissions”.
Any questions?
If you have any questions or comments about this advisory, make sure to get in touch with us directly on the Security Advisories. Alternatively, you can reach out to the dedicated security email address listed at https://umbraco.com/security. Here you can also find information on how we handle security-related issues.
For direct communication related to security in Umbraco products, please sign up for the dedicated security mailing list.
