GHSA-584p-f93j-wpgc: High severity composer/verbb/formie vulnerability
Impact
The anonymous front-end action formie/submissions/submit (SubmissionsController::actionSubmit) trusted a client-supplied submissionId when loading an incomplete submission, with no session binding, ownership check, or edit token validation.
An unauthenticated attacker could enumerate sequential submission IDs and overwrite or hijack another user's in-progress (multi-page / save-for-later) submission. Tampered data could be persisted and forwarded via notifications and integrations when the submission was completed.
Completed submissions were not affected (isIncomplete=true filter). This is an incomplete remediation of GHSA-pgxq-p76c-x9cg, which added edit-token validation to save-submission but not to submit.
Patches
Fixed in 3.1.31 (Craft 5) and 2.2.23 (Craft 4).
When resuming an existing submission on a site request, the submission ID must match the session-bound submission (Form::getCurrentSubmission()) or a valid submissionEditToken when editingSubmission is set. Cross-form submission ID reuse is also rejected.
Workarounds
No reliable workaround without upgrading. Disabling multi-page forms or save-for-later reduces exposure but does not remove the vulnerability.
- Reported by Jorge González (jorge@jmilla.es)
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/verbb/formieto a version that resolves this vulnerability.Fixed in 2.2.23 - Upgrade
Upgrade
composer/verbb/formieto a version that resolves this vulnerability.Fixed in 3.1.31 - Upgrade
Upgrade
Formie for Craft 5to a version that resolves this vulnerability.Fixed in 3.1.31 - Upgrade
Upgrade
Formie for Craft 4to a version that resolves this vulnerability.Fixed in 2.2.23 - Configuration
Disable multi-page forms or save-for-later to reduce exposure; this does not remove the vulnerability.
Formie multi-page forms or save-for-later = disabled
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using the affected Formie submission endpoint are exposed when they allow incomplete submissions, such as multi-page forms or save-for-later workflows. Completed submissions are not affected because the vulnerable lookup is limited to submissions marked incomplete.
What does an attacker need to exploit it?
An attacker does not need authentication or user interaction. They need to submit requests to the public form endpoint and enumerate sequential submission IDs for incomplete submissions.
What could an attacker do with a guessed submission ID?
They could overwrite or hijack another user's in-progress submission. The altered data can be persisted and may be sent through notifications or integrations when the submission is later completed.
Which versions contain the fix?
The issue is fixed in Formie 3.1.31 for Craft 5 and 2.2.23 for Craft 4. The fix requires a resumed submission to match the session-bound submission or provide a valid submission edit token, and rejects cross-form submission ID reuse.
Is there a mitigation if an upgrade cannot be performed immediately?
No reliable workaround is available without upgrading. Disabling multi-page or save-for-later behavior may reduce exposure, but the provided advisory does not identify it as a reliable mitigation.