Summary
Gophish through version 0.12.1 contains an insecure direct object reference vulnerability in APIs that manage groups, templates, landing pages, and sending profiles. An authenticated user may submit another user's sequential object identifier to overwrite or reassign resources, potentially locking out their owners and exposing recipient lists.
Gophish through version 0.12.1 contains an insecure direct object reference vulnerability in APIs that manage groups, templates, landing pages, and sending profiles. An authenticated user may submit another user's sequential object identifier to overwrite or reassign resources, potentially locking out their owners and exposing recipient lists.
Affected context
The vulnerability occurs in Gophish deployments where authenticated users can access resource-management endpoints without sufficiently enforcing ownership or authorization for the referenced object. Affected API areas include groups, templates, landing pages, and SMTP sending profiles, particularly when object identifiers are sequential and accepted directly from client requests.
The vulnerability occurs in Gophish deployments where authenticated users can access resource-management endpoints without sufficiently enforcing ownership or authorization for the referenced object. Affected API areas include groups, templates, landing pages, and SMTP sending profiles, particularly when object identifiers are sequential and accepted directly from client requests.
Exploit preconditions
- Attack surface: Authenticated HTTP API endpoints
- Required access: A valid Gophish user account with access to the relevant API functionality
- Trigger point: POST requests to resource-management endpoints such as
/api/groups/,/api/templates/,/api/pages/, or/api/smtp/ - Why exploitation is possible: The application may rely on a user-supplied sequential identifier without verifying that the authenticated user owns or is authorized to modify the referenced object
- Attack surface: Authenticated HTTP API endpoints
- Required access: A valid Gophish user account with access to the relevant API functionality
- Trigger point: POST requests to resource-management endpoints such as
/api/groups/,/api/templates/,/api/pages/, or/api/smtp/ - Why exploitation is possible: The application may rely on a user-supplied sequential identifier without verifying that the authenticated user owns or is authorized to modify the referenced object
Why this happens
The underlying bug is an authorization failure in object-level access control. The application accepts a direct object reference from an authenticated client and performs an update or reassignment without consistently checking whether that object belongs to the requesting user or is otherwise within the user's permitted scope. This behavior maps to CWE-639: Authorization Bypass Through User-Controlled Key, commonly associated with insecure direct object references.
The underlying bug is an authorization failure in object-level access control. The application accepts a direct object reference from an authenticated client and performs an update or reassignment without consistently checking whether that object belongs to the requesting user or is otherwise within the user's permitted scope. This behavior maps to CWE-639: Authorization Bypass Through User-Controlled Key, commonly associated with insecure direct object references.
Potential impact
- An attacker may overwrite or reassign another user's groups, templates, landing pages, or sending profiles.
- Resource owners could be locked out of objects they previously controlled.
- Recipient lists or other campaign-related information could be exposed.
- Campaign configuration may be altered, causing operational disruption or unauthorized phishing activity.
- The integrity of stored Gophish resources could be compromised.
- An attacker may overwrite or reassign another user's groups, templates, landing pages, or sending profiles.
- Resource owners could be locked out of objects they previously controlled.
- Recipient lists or other campaign-related information could be exposed.
- Campaign configuration may be altered, causing operational disruption or unauthorized phishing activity.
- The integrity of stored Gophish resources could be compromised.
General mitigation guidance
Mitigation generally centers on enforcing server-side object-level authorization for every resource operation.
Common defensive patterns include:
- Deriving the permitted owner or tenant scope from the authenticated session rather than trusting client-provided ownership data.
- Checking authorization immediately before every read, update, reassignment, or deletion operation.
- Using opaque, non-sequential identifiers as a defense-in-depth measure, without treating them as a replacement for authorization.
- Applying least-privilege roles and limiting access to campaign-management APIs.
- Returning generic authorization failures without revealing whether another user's object exists.
- Separating administrative resource operations from ordinary user workflows and requiring explicit elevated privileges where appropriate.
Mitigation generally centers on enforcing server-side object-level authorization for every resource operation.
Common defensive patterns include:
- Deriving the permitted owner or tenant scope from the authenticated session rather than trusting client-provided ownership data.
- Checking authorization immediately before every read, update, reassignment, or deletion operation.
- Using opaque, non-sequential identifiers as a defense-in-depth measure, without treating them as a replacement for authorization.
- Applying least-privilege roles and limiting access to campaign-management APIs.
- Returning generic authorization failures without revealing whether another user's object exists.
- Separating administrative resource operations from ordinary user workflows and requiring explicit elevated privileges where appropriate.
How teams detect issues like this
Detection can combine code review, automated analysis, and runtime monitoring:
- Search for API handlers that use client-supplied identifiers in database queries or update operations.
- Review whether each object access includes an ownership, tenant, role, or policy check tied to the authenticated identity.
- Flag authorization checks that occur only at route level rather than at the individual object level.
- Test requests using identifiers belonging to different users and verify consistent authorization failures.
- Monitor audit logs for unusual cross-user resource updates, reassignment attempts, or repeated sequential identifier access.
- Use static analysis and automated API security testing to identify missing object-level authorization controls.
Detection can combine code review, automated analysis, and runtime monitoring:
- Search for API handlers that use client-supplied identifiers in database queries or update operations.
- Review whether each object access includes an ownership, tenant, role, or policy check tied to the authenticated identity.
- Flag authorization checks that occur only at route level rather than at the individual object level.
- Test requests using identifiers belonging to different users and verify consistent authorization failures.
- Monitor audit logs for unusual cross-user resource updates, reassignment attempts, or repeated sequential identifier access.
- Use static analysis and automated API security testing to identify missing object-level authorization controls.
