Formie: Missing authorization on sent notification resend modal exposes submission PIIGHSA-9rg8-2wvr-fgjh
HIGHFix: verbb/formie@9f4e23cGHSA-9rg8-2wvr-fgjh is a high-severity (CVSS 7.7) Information Exposure vulnerability in verbb/formie. A fix is available for verbb/formie — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-9rg8-2wvr-fgjh.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-9rg8-2wvr-fgjh by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,415 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
verbb/formie🐘verbb/formieReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Impact
The control panel action formie/sent-notifications/get-resend-modal-content (SentNotificationsController::actionGetResendModalContent) performed only requireAcceptsJson() and loaded a SentNotification by request id without permission or object-level authorization checks.
Any authenticated user who could invoke the action could enumerate notification IDs and read full email content — including recipient headers and the complete HTML body containing submitted form data (PII) — without formie-accessSentNotifications or equivalent permission. Sibling actions in the same controller enforced authorization.
Patches
Fixed in 3.1.31 (Craft 5) and 2.2.23 (Craft 4).
Craft 5: canView() is enforced after loading, consistent with actionEdit.
Craft 4: formie-viewSentNotifications permission is required.
Workarounds
Restrict CP access to trusted users only until upgraded. No configuration workaround.
- Reported by Jorge González ([email protected])
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | verbb/formie | ≥ 3.0.0&&< 3.1.31 | 3.1.31composer require verbb/formie:^3.1.31 |
| 🐘Packagist | verbb/formie | all versions | 2.2.23composer require verbb/formie:^2.2.23 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for verbb/formie, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update verbb/formie to 3.1.31 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9rg8-2wvr-fgjh is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-9rg8-2wvr-fgjh in your dependencies?
Find it across Packagist, including transitive dependencies.