Craft CMS EUVD-2026-81291

Requires ALL of: (1) the target runs an affected Craft CMS 5.0.0-5.10.12 installation; (2) an independently-occurring database (MySQL) outage while PHP remains available - the vulnerability provides no way to induce this; (3) the attacker obtained a valid guest session cookie and matching CSRF token BEFORE the outage, and that session remains valid during it; (4) the attacker knows or guesses a predictable environment variable/constant name (e.g. Craft's conventional CRAFT_SECURITY_KEY). These stacked timing prerequisites - an outage the attacker cannot trigger plus a pre-positioned valid session - are the primary factors limiting real-world exploitation despite the network/unauthenticated vector.

This is a genuine but conditionally-gated confidentiality flaw, not a widespread-exploitation priority. The CVSS 4.0 vector (8.2, AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N) reflects the key tension: it is network-reachable and unauthenticated (PR:N), but carries AT:P (attack requirements) because exploitation depends on two conditions the attacker cannot create - an independently-occurring MySQL outage AND a still-valid guest session cookie plus matching CSRF token obtained BEFORE the outage. That AT:P is doing heavy lifting; in CVSS 3.1 terms this is better modeled as AC:H, giving a lower ~5.9 score. Impact is confidentiality-only (VC:H, VI:N/VA:N) - leaked secrets (security key, DB creds, API keys) could enable follow-on compromise, but this CVE itself grants only disclosure. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no signal of active or imminent exploitation. CWE-636 (fail-open / failure to fail securely) correctly captures the root cause: treating a DB connection error as 'not installed.' Net: a real bug worth patching, but the compound timing prerequisites make opportunistic mass exploitation unlikely - it favors a prepared, targeted attacker positioned before an outage.

An attacker first visits the target Craft CMS site under normal operation to obtain a valid guest session cookie and CSRF token. When the site's MySQL backend later suffers an independent outage (while PHP stays up), Craft mistakenly believes it is uninstalled and re-exposes the anonymous install/validate-site action; the attacker replays their still-valid session to submit a predictable variable name such as CRAFT_SECURITY_KEY, which is expanded via App::env() and returned to them. No public exploit code has been identified at time of analysis.