CVE-2026-81904 in Concrete CMS
Summary
by MITRE • 09/09/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in Concrete CMS versions prior to 9.5.3 represents a critical failure in access control mechanisms within the platform's asset management subsystem, specifically affecting how registered view assets are handled across complex page structures such as Stacks, Containers, and layout areas. In these environments, content is often organized into hierarchical blocks where individual sub-blocks may have distinct permission settings restricting visibility to specific user roles or authenticated users only. The core technical flaw lies in the fact that when a parent container renders its contents, it iterates through all registered sub-blocks and registers their associated view assets without verifying whether the current requesting user possesses the necessary permissions to actually view those specific sub-blocks. This architectural oversight means that asset registration logic is decoupled from permission validation logic during the rendering phase for these composite structures.
This design flaw allows an unauthenticated visitor or any user with insufficient privileges to trigger the execution of code within restricted sub-blocks solely through the side effect of asset registration. Many block types utilize header hooks or asset registration methods not just for visual presentation but also to inject configuration values, API keys, and other sensitive metadata into the page's head section or JavaScript environment. Because the system registers these assets regardless of user permissions, any configuration data output by a restricted sub-block becomes accessible in the source code of public pages that embed affected Stacks, Containers, or layout areas. This effectively bypasses the intended block-level permission restrictions, turning what should be private administrative configurations into publicly available information.
The operational impact of this vulnerability is significant due to its potential for data exfiltration without authentication. Attackers can target any public-facing page on a Concrete CMS installation that utilizes Stacks, Containers, or layout areas containing sub-blocks with sensitive configuration outputs. A primary example cited involves the recovery of configured Google Maps API keys from restricted blocks embedded within these structures. The exposure of such credentials allows attackers to potentially abuse third-party services linked to those configurations, leading to unauthorized usage costs, service disruption, or further reconnaissance against the organization's infrastructure. Since this affects any sub-block type whose asset or header hooks output configuration values, the scope of potential data leakage is broad and depends heavily on how administrators have configured their site components.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as it involves an actor bypassing intended restrictions to access resources they should not be able to reach. It also relates closely to CWE-913 Improper Control of Dynamically-Managed Code Resources, where the dynamic loading and registration of assets are manipulated without proper authorization checks. In terms of adversary tactics, this behavior is consistent with ATT&CK technique T1505 Server Software Component which involves implanting or using server-side components for persistence or data access, although in this case it is more accurately described as information discovery through improper component configuration rather than active exploitation of a plugin. The attack vector is classified as Network (AV:N) with Low Complexity (AC:L) and requires no Authentication (PR:N), resulting in a CVSS v4.0 score of 6.3, indicating a medium severity risk that demands prompt attention due to the ease of exploitation by unauthenticated actors.
Mitigation strategies must focus on immediate patching and architectural review. The primary remediation is to upgrade Concrete CMS to version 9.5.3 or later, where this permission check has been implemented within the asset registration process for Stacks, Containers, and layout areas. Administrators should also audit their existing site configurations to identify any public pages that embed restricted sub-blocks outputting sensitive data such as API keys or internal configuration values. For sites unable to upgrade immediately due to compatibility constraints, temporary workarounds might include removing the affected block types from public-facing stacks or containers until a patch can be applied. Additionally, organizations should implement strict monitoring for unusual outbound traffic related to exposed APIs and rotate any potentially compromised credentials such as Google Maps API keys that were previously embedded in restricted blocks now visible publicly.