CVE-2026-81916: BOLA lets users forge Express

CISO Take

Concrete CMS versions before 9.5.3 have a broken object-level authorization flaw in the Express module: the dashboard submit route resolves the target entity from the attacker-controlled route ID, while the permission check instead validates the independently posted form's entity — the two are never compared. A user permitted to add entries to one Express object can therefore create entries in a completely different Express object outside their authorization scope, polluting protected datasets, triggering unintended workflows, or injecting content into administrative processes. This is a low-urgency, insider-facing issue rather than an internet-wide threat: CVSS v4.0 is 5.1 with PR:H (an authenticated account with some Express add-permission is required), there is no EPSS score, no CISA KEV listing, and no public exploit or scanner template. Organizations running Concrete CMS with Express objects — especially where those objects feed structured data into downstream reporting or automation — should upgrade to 9.5.3 or later and review recent Express entries for cross-object submissions that shouldn't exist under normal permission boundaries. Given the low CVSS, high privilege prerequisite, and absence of any exploitation signal, this does not warrant a breaking alert to security teams.

Sources: NVD documentation.concretecms.org

What is the risk?

Low-to-moderate risk. The CVSS v4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N) shows network-reachable but privilege-gated exploitation with only limited integrity impact and no confidentiality or availability loss. There is no EPSS score, no CISA KEV entry, no SSVC decision, and no public exploit code or Nuclei template, indicating this is not being actively targeted. The main risk driver is that any authenticated user with even minimal Express entry-creation rights can escalate their write scope to arbitrary Express objects, which matters most in multi-tenant or role-segmented Concrete CMS deployments where Express objects are used to enforce data separation.

How does the attack unfold?

Initial Access

Attacker holds a legitimate but narrowly-scoped account with entry-add permission on one Express object.

Exploitation

Attacker submits a forged POST to the dashboard route for a different, unauthorized Express object while including form data for the object they are permitted to write to.

Impact

Because the authorization check validates the posted form's entity instead of the route-resolved entity, the entry is created in the unauthorized object, polluting its dataset or triggering its workflows.

AML.T0059

Initial Access

Attacker holds a legitimate but narrowly-scoped account with entry-add permission on one Express object.

Exploitation

Attacker submits a forged POST to the dashboard route for a different, unauthorized Express object while including form data for the object they are permitted to write to.

Impact

Because the authorization check validates the posted form's entity instead of the route-resolved entity, the entry is created in the unauthorized object, polluting its dataset or triggering its workflows.

AML.T0059

How severe is it?

CVSS 3.1

4.3 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 25% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C None

I Low

A None

What should I do?

1 step

Upgrade Concrete CMS to 9.5.3 or later, where the dashboard submit route is expected to validate the permission check against the same entity resolved from the route rather than the independently posted form. Until patched, audit which user roles hold Express entry-add permissions and restrict them to the minimum necessary scope. Detection: review Express entry creation logs for entries whose submitting user's permission grant does not match the target Express object ID, which would indicate exploitation of this route/form entity mismatch. No public exploit exists, so proactive log review rather than signature-based detection is the practical control.

How is it classified?

Auth Bypass Training Data AML.T0059 - Erode Dataset Integrity

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 10 - Data and data governance

ISO 42001

Annex A.7 - Data for AI systems

Frequently Asked Questions

What is CVE-2026-81916?

Concrete CMS versions before 9.5.3 have a broken object-level authorization flaw in the Express module: the dashboard submit route resolves the target entity from the attacker-controlled route ID, while the permission check instead validates the independently posted form's entity — the two are never compared. A user permitted to add entries to one Express object can therefore create entries in a completely different Express object outside their authorization scope, polluting protected datasets, triggering unintended workflows, or injecting content into administrative processes. This is a low-urgency, insider-facing issue rather than an internet-wide threat: CVSS v4.0 is 5.1 with PR:H (an authenticated account with some Express add-permission is required), there is no EPSS score, no CISA KEV listing, and no public exploit or scanner template. Organizations running Concrete CMS with Express objects — especially where those objects feed structured data into downstream reporting or automation — should upgrade to 9.5.3 or later and review recent Express entries for cross-object submissions that shouldn't exist under normal permission boundaries. Given the low CVSS, high privilege prerequisite, and absence of any exploitation signal, this does not warrant a breaking alert to security teams.

Is CVE-2026-81916 actively exploited?

No confirmed active exploitation of CVE-2026-81916 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-81916?

Upgrade Concrete CMS to 9.5.3 or later, where the dashboard submit route is expected to validate the permission check against the same entity resolved from the route rather than the independently posted form. Until patched, audit which user roles hold Express entry-add permissions and restrict them to the minimum necessary scope. Detection: review Express entry creation logs for entries whose submitting user's permission grant does not match the target Express object ID, which would indicate exploitation of this route/form entity mismatch. No public exploit exists, so proactive log review rather than signature-based detection is the practical control.

What systems are affected by CVE-2026-81916?

This vulnerability affects the following AI/ML architecture patterns: data pipelines.

What is the CVSS score for CVE-2026-81916?

CVE-2026-81916 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.32%.

What is the AI security impact?

Affected AI Architectures

data pipelines

MITRE ATLAS Techniques

AML.T0059 Erode Dataset Integrity

Compliance Controls Affected

EU AI Act: Article 10

ISO 42001: Annex A.7

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An authenticated Concrete CMS user has legitimate permission to add entries to Express Object A (e.g., a low-sensitivity intake form) but no permission on Express Object B (e.g., a protected compliance or workflow-triggering dataset). The attacker navigates to the dashboard submit route for Object B, which resolves the target entity from the route's object ID, but crafts the POST body to reference Object A's form structure. Because the authorization check validates permissions against the entity described in the posted form (Object A, which the user is allowed to write to) rather than the entity identified by the route (Object B), the submission is approved and an entry is created directly in Object B — bypassing the intended access boundary and potentially triggering any workflow or automation tied to new entries in Object B.

Weaknesses (CWE)

CWE-639 Authorization Bypass Through User-Controlled Key CWE-639 Authorization Bypass Through User-Controlled Key CWE-862 Missing Authorization CWE-862 Missing Authorization

CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

[Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
[Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Source: MITRE CWE corpus.