What is CVE-2026-69197?
CVE-2026-69197 is an authorization flaw in the Content Delivery API of Umbraco CMS, an open source ASP.NET content management system. The Delivery API enforces member and Public Access checks on the node a caller directly requests, but it does not apply those same checks to nodes referenced through Content Picker or Multi-Node Tree Picker properties. The gap extends to pickers nested inside Block List, Block Grid, and Rich Text Editor blocks.
The vulnerability carries a CVSS v4.0 base score of 8.7 (High). It is classified as both exposure of sensitive information to an unauthorized actor and missing authorization. No CVSS v3.1 score has been published for this issue at the time of writing.
Exploitation is pre-authentication in the configuration that matters most. When DeliveryApi:PublicAccess is enabled, an anonymous caller can reach an unprotected node that references a protected one and read the protected node’s name, route, and id. Appending ?expand to the request returns its full property values. Where the Delivery API is instead gated behind the organization-wide API key rather than opened anonymously, a valid key holder can still bypass per-node Public Access through the same expansion path. The same expansion strategies also bypass allowed and disallowed content-type alias restrictions on referenced content.
The impact is confidentiality only. A direct request for the protected node still returns 401, and the vendor advisory establishes no integrity or availability impact. The practical consequence is that content an organization deliberately placed behind Public Access, such as member-only pages, internal notices, unpublished campaign material, or gated documents, can be read by a caller who was never granted access to it.
What assets are affected by CVE-2026-69197?
The flaw affects Umbraco CMS versions from 12.0.0 up to but not including 13.15.1, from 14.0.0-rc1 up to but not including 17.5.3, and from 18.0.0 up to but not including 18.0.2. This spans the long-term-support 13 line alongside the current 17 and 18 releases, so an organization on a recent version is not automatically outside the affected range.
In practice an affected asset is a public-facing Umbraco site with the Content Delivery API enabled. The Delivery API is the headless and decoupled front end for Umbraco content, so the deployments most likely to have it switched on are those serving content into a separate frontend framework, a mobile application, a partner portal, or a set of microsites built on a shared content backend. Public sector portals, healthcare information sites, membership organizations, and corporate marketing estates are all common Umbraco use cases and all routinely combine public pages with Public Access sections.
Two conditions narrow real exploitability, and both are worth checking before triaging an asset as at risk. The Delivery API must be enabled, and it must either be open to anonymous callers with DeliveryApi:PublicAccess set or be reachable by someone holding the organization-wide API key. An Umbraco instance with the Delivery API turned off is not exposed to this flaw, even on an affected version. Externally, neither condition is visible from a login page or a service banner, which is precisely why version and configuration verification has to happen on the asset owner’s side.
What does our data show about exposure patterns?
Exposure in this set is led by Industrials at 63.1% of observed assets, with Health Care contributing 7.1% and Consumer Staples 5.2%.
This distribution should be read as a statement about where the largest Umbraco estates sit rather than about which sectors are structurally more vulnerable. Exposure here is heavily concentrated: individual large estates account for a substantial share of the observed assets, and a single organization running Umbraco across a wide portfolio of public-facing microsites will register far more assets than an entire sector of organizations running one site each.
The sectors at the top of this table are ones where that pattern is common. Public service, health, and consumer brand organizations tend to operate many separately branded sites, campaign properties, and regional portals on one shared content platform, which is exactly the architecture Umbraco and its Delivery API are built to serve.
That concentration is itself the more useful finding. A content platform shared across many sites means a single misconfigured Delivery API setting propagates across every property built on it, and it means the team that owns the CMS upgrade is often not the team that owns any individual site.
The assets in this set were identified by service fingerprint rather than by confirmed version detection or confirmed Delivery API configuration, so the population of assets running Umbraco is necessarily broader than the population where this specific flaw is reachable. That gap is the point defenders should act on. Knowing which of an organization’s Umbraco properties have the Delivery API enabled, and with what access setting, is not information most external inventories carry, and it is rarely tracked centrally on the inside either.
Are fixes available?
Yes. Umbraco fixed the issue in versions 13.15.1, 17.5.3, and 18.0.2, published alongside the vendor security advisory on September 17, 2026. Each release corresponds to one of the three affected version ranges, so the correct target depends on which line an instance is running rather than on upgrading to the newest release.
The fix is delivered through standard Umbraco releases rather than a separate patch, so organizations already on a supported upgrade path can apply it through their normal NuGet package update process. Sites on a version below 12.0.0 fall outside the stated affected ranges for this specific issue, but those versions are also outside Umbraco’s supported lifecycle and carry their own separate exposure.
Because the advisory is recent, vulnerability database coverage and any downstream hosting-provider guidance may lag behind the vendor releases. Defenders should verify the installed Umbraco version and Delivery API configuration directly rather than relying on a scanner’s inferred patch status, which cannot see either.
Are there any other recommended actions to take?
Until patching is confirmed, defenders should:
- Inventory all internet-facing Umbraco properties, including microsites and campaign sites
- Check whether the Content Delivery API is enabled on each instance
- Disable
DeliveryApi:PublicAccesswhere anonymous Delivery API access is not required - Rotate the organization-wide Delivery API key and restrict who holds it
- Audit which content relies on Public Access rather than on genuine access control
- Monitor Delivery API request logs for anomalous use of the
?expandparameter
How can CyCognito help your organization?
CyCognito published an Emerging Threat Advisory for CVE-2026-69197 in the CyCognito platform and is actively researching enhanced detection capabilities for this vulnerability.
To learn how CyCognito can help your organization reduce external exposure and manage emerging threats more effectively, contact us to request a demo.
