Craft CMS EUVD-2026-97608

Exploitation requires an authenticated low-privileged (PR:L) user account - such as a front-end/registered user - and the specific precondition that the installed edition does NOT match the licensed edition (reflected as AT:P in the CVSS 4.0 vector); the vulnerable AppController::actionSwitchToLicensedEdition() action route is only abusable in that mismatched state. Limiting factors: authentication is mandatory (no anonymous exploitation), the license/edition mismatch condition must exist, and the impact is confined to persistently downgrading the site edition in project config rather than code execution or data exposure. Sites that do not provision any low-privileged or self-registering user accounts are not practically exposed.

This is a genuine but moderate-priority issue, not a top-tier emergency. The CVSS 4.0 base score of 6.0 (Medium) reflects an authenticated (PR:L) network-reachable (AV:N) flaw with low attack complexity (AC:L) but a present attack requirement (AT:P) - exploitation only works when the licensed edition mismatches the installed edition, which bounds real-world exploitability. Impact is skewed toward availability (VA:H, a persistent edition downgrade admins cannot reverse from the control panel) with limited integrity impact (VI:L) and no confidentiality impact (VC:N). No EPSS score, SSVC decision, KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is therefore self-inflicted operational disruption by any low-privileged front-end user rather than data compromise or remote code execution - meaningful for multi-tenant or public-registration Craft sites, but lower stakes for single-admin deployments. Missing signals to verify: there is no EPSS probability and no independent exploitation evidence, so prioritization should lean on exposure (does the site allow low-privileged/front-end user accounts?) rather than threat-intel urgency.

On a Craft CMS site that permits low-privileged front-end user registration or logins, an authenticated user whose licensed edition differs from the installed edition navigates to the unprotected AppController::actionSwitchToLicensedEdition() route and triggers an edition downgrade. The change is written persistently to project config, degrading site functionality in a way administrators cannot undo through the control panel. No public exploit code was identified at time of analysis, but the attack requires only a standard authenticated request.