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. 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 an authorized user attaches a file, or otherwise links to it, unauthorized users won't be able to view the file. The Concrete CMS security team thanks Tristan Mandani for reporting this issue.
Update concrete5/concrete5 to 9.5.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanConcrete CMS is vulnerable to IDOR in AddMessage/UpdateMessage affects concrete5/concrete5 (composer). Severity is low. 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. 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 an authorized user attaches a file, or otherwise links to it, unauthorized users won't be able to view the file. The Concrete CMS security team thanks Tristan Mandani for reporting this issue.
AI coding agents often install or upgrade packages automatically in composer. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
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. 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 an authorized user attaches a file, or otherwise links to it, unauthorized users won't be able to view the file. The Concrete CMS security team thanks Tristan Mandani for reporting this issue.
Update concrete5/concrete5 to 9.5.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanConcrete CMS is vulnerable to IDOR in AddMessage/UpdateMessage affects concrete5/concrete5 (composer). Severity is low. 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. 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 an authorized user attaches a file, or otherwise links to it, unauthorized users won't be able to view the file. The Concrete CMS security team thanks Tristan Mandani for reporting this issue.
AI coding agents often install or upgrade packages automatically in composer. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|
| concrete5/concrete5composer | <9.5.1 | 9.5.1 |
|---|
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard| Package | Affected range | Fixed version |
|---|
| concrete5/concrete5composer | <9.5.1 | 9.5.1 |
|---|
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard