CVE-2026-81916 in Concrete CMS
Summary
by MITRE • 09/11/2026
Concrete CMS before 9.5.3 evaluated the authorization check for an Express entry submission against the entity of the posted form rather than the entity identified by the dashboard route. As a result, a user permitted to add entries to one Express object could create entries in a different Express object outside their authorization scope, potentially polluting protected datasets, triggering workflows, or injecting content into administrative processes. The dashboard submit route resolved the mutated entity from the attacker-controlled route ID while the permission check validated the independently posted form's entity, and the submission proceeded because the two entities were never compared. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.1 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
Concrete CMS versions prior to 9.5.3 contain a critical authorization bypass vulnerability within the Express entry submission mechanism, classified under CWE-862 as Missing Authorization. This flaw arises from an inconsistency in how the application validates user permissions against requested resources during data creation operations. Specifically, when a user submits a form to create a new entry for an Express object, the system performs its access control check by validating the entity identifier embedded within the submitted form payload rather than verifying it against the target resource defined by the dashboard route or controller context. This architectural misalignment allows an attacker who possesses valid credentials and permission to add entries to one specific Express object to manipulate the request parameters to target a different, unauthorized Express object.
The technical root cause lies in the decoupling of the authorization check from the actual entity being modified. The dashboard submit route resolves the intended mutated entity based on the route ID or controller configuration, which represents the legitimate administrative intent. However, the permission validation logic independently inspects the entity identifier posted within the form data submitted by the client side. Because these two values are never compared for consistency, an authenticated user with limited privileges can simply alter the entity reference in their POST request to point toward a protected or restricted Express object. Since the authorization check passes based on the attacker-controlled payload rather than the route-defined target, the system erroneously grants access and proceeds with the submission operation.
This vulnerability enables unauthorized data injection into administrative processes and protected datasets, leading to significant integrity violations. An attacker can pollute databases by inserting malicious or malformed entries into objects they do not have permission to modify. Furthermore, depending on the configuration of specific Express objects, this action may trigger automated workflows, notifications, or business logic that were intended only for authorized administrators. This capability effectively bypasses role-based access controls, allowing lower-privileged users to perform actions reserved for higher-level roles such as editors or system administrators. The impact is primarily focused on integrity and potentially availability if the injected content disrupts downstream processes, though confidentiality remains largely unaffected in this specific vector unless sensitive data exposure occurs through subsequent interactions with the polluted dataset.
From a threat modeling perspective, this vulnerability aligns with MITRE ATT&CK technique T1078 Valid Accounts, as it requires authentication but exploits misconfigured permissions to escalate privileges or access restricted resources. It also reflects patterns associated with CWE-269 Improper Privilege Management and CWE-352 Cross-Site Request Forgery if the vulnerability can be triggered via a crafted request from another origin without proper anti-CSRF protections, although the primary issue is authorization logic rather than session management. The severity of this flaw was assessed by the Concrete CMS security team with a CVSS v4.0 score of 5.1, indicating medium risk due to its network exploitable nature and low complexity but limited impact on confidentiality and availability compared to integrity.
To mitigate this vulnerability, organizations running affected versions of Concrete CMS must upgrade immediately to version 9.5.3 or later where the authorization logic has been corrected to validate permissions against the route-defined entity rather than the form payload. Until an upgrade is feasible, administrators should implement strict input validation and ensure that all Express object submissions are routed through controllers that enforce consistent identity verification between the request context and the target resource. Additionally, reviewing user roles and minimizing the number of users with permission to create entries in sensitive Express objects can reduce the attack surface. Regular security audits focusing on authorization checks across all administrative endpoints are recommended to identify similar inconsistencies where client-supplied identifiers might override server-side access control decisions.