Summary
Capgo contains an incomplete access-control fix that leaves the provider_id field of SSO provider records writable by authorized organization administrators. An attacker who already has org_admin access in an organization with active SSO may redirect the organization's trust relationship to an IdP they control, potentially causing account takeover, privilege escalation, and owner lockout.
Affected context
The issue occurs in Capgo deployments using the public.sso_providers table and PostgREST-based updates. It is relevant when an organization has an active SSO provider, organization administrators can update provider records, and row-level policies restrict target rows without restricting sensitive columns such as provider_id. The vulnerable configuration can allow a tenant administrator to alter the identity provider used as the trust anchor for an email domain.
Exploit preconditions
- Attack surface: PostgREST access to SSO provider records
- Required access: An authenticated user holding the
org_admintier permission, includingorg.update_settings, in the target organization - Target state: The organization has an active SSO provider configured
- Trigger point: An update to the SSO provider's writable identity-provider reference
- Why exploitation is possible: The access-control guard protects selected fields but does not restrict
provider_id, while broad table grants and row-level policies permit the authorized administrator to modify the trust-anchor column
Why this happens
The underlying flaw is an incomplete authorization boundary at the column level. A database trigger freezes several security-sensitive fields, but leaves provider_id writable, and the table grants and row-level policies do not compensate for that omission.
This maps to CWE-639: Authorization Bypass Through User-Controlled Key, because a user with limited administrative authority can influence the identifier used to select or trust an identity provider. The insecure pattern is treating row-level authorization as sufficient while allowing a lower-privileged principal to change a security-critical relationship within the authorized row.
Potential impact
- An attacker may redirect SSO validation to an identity provider they control.
- An attacker could authenticate while asserting an organization owner's email identity.
- The application may attach the attacker's SSO identity to an existing privileged account.
- The legitimate owner's password, identities, or sessions could be invalidated.
- The attacker may gain organization-owner or super-admin privileges.
- Legitimate users could be locked out and organizational data or settings could be exposed or altered.
General mitigation guidance
Mitigation generally requires treating the identity-provider binding as a security-critical, immutable relationship rather than an ordinary organization setting.
Common defensive patterns include:
- Enforcing column-level authorization for
provider_id,metadata_url, and attribute-mapping fields. - Allowing only a narrowly scoped, separately authorized workflow to create or replace an SSO trust anchor.
- Using database permissions, views, stored procedures, or dedicated APIs that expose only approved fields for each role.
- Ensuring row-level policies and field-level controls jointly enforce least privilege.
- Requiring independent verification and strong reauthentication for changes to identity-provider configuration.
- Preventing lower-privileged organization administrators from modifying authentication trust anchors.
- Auditing provider changes and applying alerts, approval workflows, and rollback controls.
- Preserving existing credentials and identities until a validated ownership-change process is complete.
How teams detect issues like this
High-level detection can combine database, application, and source-code review:
- Review grants and privileges on SSO configuration tables, with particular attention to
anonandauthenticatedroles. - Inspect row-level policies and triggers for column coverage, checking whether security-sensitive identifiers remain writable.
- Use static analysis and code review rules to flag broad update endpoints for authentication or identity-provider records.
- Test authorization matrices by role, verifying that organization administrators cannot change trust-anchor fields.
- Monitor audit logs for changes to
provider_id, identity-provider metadata, domain bindings, and privileged-account identities. - Alert on SSO configuration changes followed by unusual owner authentication, identity replacement, session invalidation, or privilege changes.
- Automated security review tools may help identify mismatches between table grants, row-level policies, and field-level authorization.
