Summary
Formie contains a server-side request forgery vulnerability in the form integration settings action. An authenticated attacker with access to the affected control panel or permitted front-end authentication path may redirect requests to attacker-controlled or internal hosts, potentially exposing stored integration credentials and remote responses.
Affected context
The issue occurs in Formie deployments where the vulnerable integration settings action is reachable without the intended form integration permission. It becomes risky when a configured integration uses stored API keys or OAuth tokens and request-supplied settings can override outbound host properties such as the API URL. Sites allowing low-privileged or front-end user authentication may have a broader exposure surface.
Exploit preconditions
- Attack surface: Formie's
formie/integrations/form-settingscontrol panel action - Required access: An authenticated account able to reach the action, including potentially low-privileged or front-end users depending on site configuration
- Trigger point: Processing integration settings that control the destination of a server-side request
- Why exploitation is possible: The action lacks the required permission check and accepts attacker-influenced host properties while using credentials stored for the configured integration
Why this happens
The vulnerability results from a missing authorization check combined with insufficient control over outbound request destinations. The action passes request-supplied integration settings to a configured integration, allowing an attacker to replace an API endpoint while the server retains its trusted API keys or OAuth tokens. This maps primarily to CWE-918: Server-Side Request Forgery, with related weaknesses involving missing authorization (CWE-862) and improper control of externally influenced object or configuration state (CWE-915).
Potential impact
- The server may send authenticated requests to an attacker-controlled host
- Integration API keys or OAuth tokens could be disclosed
- Internal services and network responses could be exposed
- Requests could reach cloud metadata or other privileged internal endpoints
- The application or connected services could be affected through credentialed requests
General mitigation guidance
Mitigation typically focuses on enforcing authorization before processing integration settings and reducing trust in client-controlled destination values.
Common defensive patterns include:
- Apply the required permission check consistently to every integration-related action
- Use server-side allowlists for approved integration hosts and schemes
- Avoid accepting arbitrary endpoint overrides from request parameters
- Separate stored credentials from user-controlled configuration values
- Restrict outbound network access with egress controls and private-address filtering
- Use narrowly scoped integration credentials and least-privilege service accounts
- Return only the minimum response data needed by the caller
How teams detect issues like this
Organizations commonly detect this class of issue through:
- Static analysis for controller actions that process requests without authorization checks
- Code review of parameters that influence URLs, hosts, schemes, proxies, or integration configuration
- Tests verifying that low-privileged users cannot invoke protected integration actions
- Runtime monitoring for outbound requests to unexpected domains, private IP ranges, loopback addresses, or metadata services
- Egress policies that alert on or block unauthorized destinations
- Automated security review tools that identify SSRF sinks and missing access-control enforcement
