CVE-2026-7886
MediumCVSS 4.3Exploitation Probability (EPSS)
Low risk21th percentile - higher than 21% of all known CVEs
Summary
Concrete CMS version 9.5.0 and below is vulnerable to IDOR in the AddMessage and UpdateMessage controllers via the attachments[] parameter. They lack per-file permission checks (canViewFile()), allowing a user who can post in any conversation to reference any file in the CMS file manager by its ID, bypassing the permission system.
Risk Assessment
The organization risks unauthorized access to private files stored in the CMS, potentially leading to exposure of confidential data.
Recommendation
Update Concrete CMS to a version above 9.5.0, and for private files configure a private storage location outside the webroot.
Other vulnerabilities in Concrete CMS
See all- CVE-2026-10721High
Vulnerability in Concrete CMS below version 9.5.2 allows an unauthenticated attacker to perform PHP object injection via unserialize() calls in Permission, Cache, and Search components. The attack requires a malicious payload to be placed in the database.
- CVE-2026-7888High
Concrete CMS below version 9.5.2 is vulnerable to PHP Object Injection via unserialize() calls in the Workflow, Form block, and File/Set components that lack the allowed_classes restriction. An unauthenticated attacker may trigger arbitrary PHP object instantiation if a malicious serialized payload has been placed in the database.
- CVE-2026-8353Medium
Concrete CMS versions 9.0 to 9.5.0 are vulnerable to Stored XSS via page name in the Atomik theme. A rogue editor can inject arbitrary JavaScript that executes in the context of any authenticated user visiting the affected account pages.
- CVE-2026-8347Medium
Concrete CMS 9.5.0 and below is vulnerable to IDOR + wrong-authorization-level in the Express association Reorder dialog. This can cause Cross-entity state tampering with view-only permission on one entry. To be affected, a website has to be using express and relying on express entity ordering.
- CVE-2026-8340Medium
Concrete CMS version 9.5.0 and below is vulnerable to CSRF via Backend\File::approveVersion. A victim with edit_file_contents permission can be tricked into publishing an attacker-chosen previously-uploaded file version (downgrade or activation of an unpublished version).
- CVE-2026-8435Medium
Concrete CMS 9 before version 9.5.0 is vulnerable to Cross-Site Request Forgery (CSRF) in the approveVersion() controller. An attacker can exploit this vulnerability to perform unauthorized actions on behalf of an administrator.
- CVE-2026-8434High
Concrete CMS 9 before 9.5.0 is vulnerable to Cross-Site Request Forgery (CSRF) at concrete/controllers/backend/file rescanMultiple(). An attacker can trick an administrator into performing unwanted file operations.
- CVE-2026-8433High
Concrete CMS 9 before 9.5.0 is vulnerable to Cross-Site Request Forgery (CSRF) at concrete/controllers/backend/file rescan(). An attacker can trick an administrator into rescanning a file.
- CVE-2026-8432High
Concrete CMS 9 before 9.5.0 is vulnerable to Cross-Site Request Forgery (CSRF) at concrete/controllers/backend/file star(). An attacker can trick an administrator into starring a file.
- CVE-2026-8427High
Concrete CMS 9 before 9.5.0 is vulnerable to CSRF in the removeFavoriteFolder($id) endpoint. An attacker can exploit this to perform unauthorized actions on behalf of the victim.
Original NVD description (English source)
Concrete CMS 9.5.0 and below is vulnerable to IDOR in AddMessage/UpdateMessage via attachments[] parameter which can lead to file permission bypass. The `AddMessage` and `UpdateMessage` conversation controllers accept user-supplied file attachment IDs and load files directly via `$em->find(File::class, $attachmentID)` without checking per-file permissions (`canViewFile()`). A user who can post in any conversation can reference any file in the CMS file manager by its sequential ID, effectively bypassing the file permission system. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 2.3 with a vector CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Tristan Mandani for reporting. if a site truly has private files, the owner should set up a private storage location https://documentation.concretecms.org/user-guide/editors-reference/dashboard/system-and-maintenance/files/file-storage-locations outside of the webroot so that permissions can be checked on view as well. That way, even if a authorized user attaches a file, or otherwise links to it, unauthorized users won't be able to view the file.