CVE-2026-7886
IDOR in Concrete CMS via Attachments Parameter
Publication date: 2026-05-21
Last updated on: 2026-05-21
Assigner: ConcreteCMS
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| concrete5 | concrete_cms | to 9.5.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-639 | 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. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability affects Concrete CMS version 9.5.0 and below and is an Insecure Direct Object Reference (IDOR) issue in the AddMessage and UpdateMessage conversation controllers.
The problem arises because these controllers accept user-supplied file attachment IDs via the attachments[] parameter and load files directly without verifying if the user has permission to view those files.
Specifically, the system uses a function to find files by their ID but does not check per-file permissions with canViewFile(), allowing a user who can post in any conversation to reference any file in the CMS file manager by its sequential ID.
This effectively bypasses the file permission system, potentially exposing files that should be restricted.
How can this vulnerability impact me? :
This vulnerability can allow a user with posting permissions in any conversation to access files they should not be authorized to view by referencing file IDs directly.
As a result, sensitive or private files stored in the CMS file manager could be exposed to unauthorized users, leading to potential data leakage.
However, the impact is somewhat mitigated if the site owner configures private storage locations outside of the webroot, which enforces permission checks on file views.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, site owners should set up a private storage location outside of the webroot. This ensures that permissions can be properly checked on file views, preventing unauthorized users from accessing private files even if they are linked or attached by authorized users.
Specifically, configuring private storage locations as described in the Concrete CMS documentation helps protect files from unauthorized access despite the IDOR vulnerability in the AddMessage/UpdateMessage controllers.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in Concrete CMS allows unauthorized users to bypass file permission checks and access files they should not be able to view. This could potentially lead to unauthorized disclosure of sensitive or private information.
Such unauthorized access to files may impact compliance with data protection regulations like GDPR and HIPAA, which require strict controls over access to personal and sensitive data to protect privacy and confidentiality.
However, the Concrete CMS security team recommends configuring private storage locations outside the webroot to enforce proper permission checks, which can mitigate the risk of unauthorized file access.