Concrete CMS CVE-2026-8340

Exploitation requires two cumulative conditions: first, the victim must be an authenticated Concrete CMS backend user holding the edit_file_contents permission - users without this permission cannot trigger the approveVersion action even via CSRF. Second, the attacker must have prior knowledge of or access to a valid file version identifier on the target CMS instance, either by having previously uploaded content themselves or through reconnaissance of the target's file management workflow; this is reflected in the CVSS AT:P metric. User interaction (UI:P) is mandatory - the victim must navigate to or load content from an attacker-controlled page while their CMS session cookie is active. Exploitation is further limited by the fact that it cannot be automated at scale (SSVC Automatable:no), requires targeted social engineering, and only affects file version integrity with no confidentiality or availability impact. Default CMS configurations are not sufficient alone - the victim's permission level and active authenticated session are both required.

All available signals converge on low real-world risk. The vendor-assigned CVSS v4.0 base score of 2.3 reflects that while the attack originates over the network (AV:N) with no attacker privileges (PR:N), two hard constraints apply: AT:P (a specific file version ID on the target must be known or previously uploaded by the attacker) and UI:P (the victim must interact with an attacker-controlled page while authenticated). Impact is integrity-only at low severity (VI:L), limited to changing which file version is active - no confidentiality or availability impact. EPSS at 0.02% (5th percentile) indicates near-zero observed exploitation probability in the broader threat landscape. SSVC confirms Exploitation:none, Automatable:no, and Technical Impact:partial, reinforcing that this vulnerability cannot be mass-exploited and requires targeted social engineering. No KEV listing and no POC further reduce urgency. This is not a prioritization candidate for most organizations unless the affected CMS hosts sensitive content where unauthorized file version changes could have downstream compliance or content-integrity consequences.

An attacker who has previously uploaded a file or otherwise knows a valid file version ID on the target Concrete CMS instance crafts a malicious HTML page embedding a forged POST request to the Backend\File::approveVersion endpoint. The attacker then lures a Concrete CMS editor who holds the edit_file_contents permission - via phishing email or a compromised page - to visit the malicious page while authenticated to the CMS backend. The victim's browser silently submits the forged request, causing the CMS to approve and publish the attacker-specified file version without any visible indication to the editor. No public exploit code is known to exist at time of analysis.