Which versions of Concrete CMS are affected by EUVD-2026-31340?

Concrete CMS 9.5.0 and earlier contain a cross-site request forgery vulnerability in the core update mechanism that allows remote attackers to force unauthorized CMS upgrades or downgrades without…. A patch is available.

How to fix or mitigate EUVD-2026-31340?

24 hours: Create inventory of all Concrete CMS instances and document version numbers; restrict administrative dashboard access via IP whitelist or VPN-only requirement. 7 days: Review upgrade logs for unauthorized version changes; deploy Web Application Firewall rules to block suspicious CMS upgrade requests. 30 days: Monitor Concrete CMS security advisories for patched versions; establish upgrade timeline and test patch in non-production environment.

Concrete CMS EUVD-2026-31340

Q: What is the CVSS score of EUVD-2026-31340?

EUVD-2026-31340 has a CVSS 4.0 base score of 7.5 (High). CVSS vector: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

| CVE-2026-8428 HIGH

Cross-Site Request Forgery (CSRF) (CWE-352)

2026-05-21 ff5b8ace-8b95-4078-9743-eac1ca5451de

GHSA-prxr-vjgc-2cq9

PHP CSRF

7.5

CVSS 4.0 · NVD

Severity by source

NVD PRIMARY

7.5 HIGH

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

Analysis Generated

May 21, 2026 - 21:34 vuln.today

DescriptionCVE.org

Concrete CMS 9.5.0 and below emits a CSRF token in the local_available_update.php view ($token->output('do_update')) but the corresponding do_update() method in concrete/controllers/single_page/dashboard/system/update/update.php never calls $this->token->validate('do_update'). The form is rendered as a POST form, meaning the token reaches the browser, but because the controller discards it without verification, an attacker can craft a cross-site POST that triggers a core CMS update to an attacker-specified version string. In order to be vulnerable, theictim must be passing canUpgrade()anda valid update version must be present under DIR_CORE_UPDATES. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks https://github.com/maru1009 for reporting.

AnalysisAI

Cross-site request forgery in Concrete CMS 9.5.0 and earlier allows remote attackers to coerce an authenticated administrator's browser into triggering a core CMS upgrade to an attacker-chosen version. The dashboard's do_update() controller emits a CSRF token in the rendered POST form but never calls $this->token->validate('do_update'), leaving the update workflow effectively unauthenticated against forged cross-origin requests. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.

Technical ContextAI

Concrete CMS is an open-source PHP content management system. The flaw lives in concrete/controllers/single_page/dashboard/system/update/update.php, where the do_update() action processes a POST submission from the local_available_update.php view. The view properly calls $token->output('do_update') to emit an anti-forgery token, but the receiving controller method omits the matching $this->token->validate('do_update') check - a textbook CWE-352 (Cross-Site Request Forgery) implementation gap where a defense was scaffolded but never actually enforced server-side. Because the action drives the core upgrade pipeline (using version strings resolved under DIR_CORE_UPDATES), forging this single request causes Concrete to pivot its own runtime to a chosen on-disk update package.

RemediationAI

Upgrade Concrete CMS to version 9.5.1 or later, which according to the vendor's 9.5.1 release notes at https://documentation.concretecms.org/9-x/developers/introduction/version-history/951-release-notes addresses this CSRF gap; treat the upstream-cited 9.5.1 as the patched release while independently validating the controller now invokes $this->token->validate('do_update'). Where immediate upgrade is not feasible, compensating controls include removing or not staging any update packages under DIR_CORE_UPDATES so the vulnerable code path has nothing to install (trade-off: blocks legitimate in-dashboard upgrades and forces manual updates), restricting access to /dashboard/system/update at the web-server or WAF layer to known admin source IPs (trade-off: breaks remote admin workflows), and enforcing SameSite=Lax or Strict on the Concrete session cookie plus a strict Referer/Origin check in front of the dashboard to neutralize cross-site POSTs (trade-off: may interfere with embedded admin flows or SSO redirects).