CVE-2026-81904: Missing Authorization in Stack/Container Sub-Block Asset Registration
Concrete CMS below 9.5.3 registered view assets for every sub-block of a Stack, Container, or layout area without checking whether the requesting user could view that sub-block. An unauthenticated visitor could recover configuration values emitted by a restricted sub-block's asset registration — such as a site's configured Google Maps API key — from any public page embedding an affected Stack, Container, or layout area, despite the block-level permission restriction. Any sub-block type whose asset or header hooks output configuration values is affected. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 6.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori (Tenzai) for reporting.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Concrete CMSto a version that resolves this vulnerability.Fixed in 9.5.3 - Configuration
Ensure Concrete CMS only registers/outputs assets (including any asset/header hooks that emit configuration values such as Google Maps API keys) for Stack, Container, or layout sub-blocks when the requesting user is authorized to view that specific sub-block.
Concrete CMS authorization check for Stack/Container sub-block asset registration = enabled
Event History
Frequently Asked Questions
Does exploiting this issue require an account or interaction from a privileged user?
No. An unauthenticated visitor can recover affected configuration values from a public page that embeds the affected Stack, Container, or layout area.
Which sites are realistically exposed?
Sites running Concrete CMS below 9.5.3 are exposed when a public page includes a Stack, Container, or layout area containing a sub-block that is restricted from the visitor but emits configuration through asset or header hooks.
What information could be disclosed?
The issue can disclose configuration values emitted during the restricted sub-block's asset registration. The advisory specifically identifies a configured Google Maps API key as an example.
How can I determine whether a restricted block may have leaked data?
Review public pages that embed Stacks, Containers, or layout areas for restricted sub-blocks. Pay particular attention to sub-block types whose asset or header hooks output configuration values, because those values may be recoverable by unauthenticated visitors.