Summary
Formie contains an object-level authorization flaw in the control panel action that retrieves resend-modal content for sent notifications. An authenticated user who can invoke the action may enumerate notification identifiers and read recipient headers and complete HTML email bodies containing submitted form data, even without the intended sent-notification viewing permission.
Affected context
The issue occurs in Formie for Craft CMS when the sent-notification resend-modal action processes a request-supplied notification identifier without verifying that the requesting user is authorized to view the referenced notification. Deployments are at risk when authenticated users can reach this control panel action and notification records contain sensitive recipient information or submitted form data.
Exploit preconditions
- Attack surface: Craft CMS control panel action for sent-notification resend-modal content
- Required access: An authenticated Formie or Craft CMS user able to invoke the action
- Trigger point: Submission of a request containing a sent-notification identifier
- Authorization condition: The action does not consistently enforce the sent-notification viewing permission or object-level ownership and access checks
- Why exploitation is possible: User-controlled identifiers are used to retrieve notification records and their rendered content without confirming authorization for each referenced object
Why this happens
The underlying bug is a missing object-level authorization check, commonly associated with CWE-639: Authorization Bypass Through User-Controlled Key. The application accepts a notification identifier from the request and retrieves the corresponding record, but fails to establish that the authenticated requester is permitted to access that specific object. This also relates to CWE-862: Missing Authorization and can produce CWE-200: Exposure of Sensitive Information when notification content includes submitted form data.
Potential impact
- An authenticated user may enumerate valid sent-notification identifiers
- Unauthorized users could read recipient headers and complete HTML email bodies
- Submitted form data may be disclosed across organizational or user boundaries
- Sensitive personal, business, or operational information could be exposed
- The issue could support targeted privacy violations or further social engineering
General mitigation guidance
Mitigation typically focuses on enforcing authorization at the point where each notification object is retrieved and rendered.
Common defensive patterns include:
- Require the intended sent-notification viewing permission for the action
- Apply server-side object-level authorization checks for every request-supplied identifier
- Derive accessible notification records from the authenticated user's authorized scope rather than trusting client-selected keys
- Return uniform responses for missing and unauthorized objects to reduce identifier enumeration
- Minimize the data rendered in resend dialogs and redact sensitive form fields where practical
- Apply least privilege to control panel roles and separate notification-management capabilities
How teams detect issues like this
Organizations commonly detect this class of issue through:
- Static analysis and review rules for database lookups driven directly by request parameters
- Code review checks confirming authorization before object retrieval or rendering
- Tests that access another user's or role's notification identifier and expect denial
- Authorization policy enforcement for every control panel action and record type
- Monitoring for repeated requests containing sequential or invalid notification identifiers
- Automated security testing that compares responses across roles with different permissions
