Formie EUVD-2026-85547

The affected Craft CMS site must use Formie multi-page forms or the save-for-later feature, since only incomplete submissions (isIncomplete=true) can be targeted; completed submissions are unaffected. Exploitation requires an in-progress submission to exist for enumeration/hijack, and the attacker needs no authentication, no session, and no user interaction against the anonymous formie/submissions/submit endpoint. Disabling multi-page forms or save-for-later reduces exposure but does not fully remediate; the only reliable fix is upgrading to Formie 3.1.31 (Craft 5) or 2.2.23 (Craft 4).

This is a genuine, high-impact authorization flaw (CWE-639 IDOR) that deserves prompt patching, though not emergency-tier response. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N, 8.2) is internally consistent with the description: a fully unauthenticated network attacker can enumerate sequential submission IDs against the anonymous formie/submissions/submit action with no session binding or ownership check, yielding high integrity impact (overwriting/hijacking another user's in-progress submission) and low confidentiality (exposure of the loaded submission's field data). I largely AGREE with the 8.2 score; the primary counterweight is that exploitation is gated on the target site actually using multi-page or save-for-later forms and on an in-progress incomplete submission existing to hijack - realistic but not universal. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no signal of active exploitation; the risk here is potential/technical rather than observed. Notably this is explicitly an INCOMPLETE remediation of prior advisory GHSA-pgxq-p76c-x9cg (which fixed save-submission but not submit), which raises the plausibility of a knowledgeable attacker revisiting the same class - a factor worth weighting above the raw absence of a POC.

An unauthenticated attacker scripts requests to formie/submissions/submit, supplying guessed sequential submissionId values to load and overwrite other visitors' in-progress multi-page or save-for-later submissions. The tampered data is persisted and later forwarded through the form's notifications and integrations when the victim completes the submission. No public exploit code is identified at time of analysis, but the attack is mechanically simple (enumeration of an integer ID).