Someshhackz-Spec

**Name of the Vulnerable Software and Affected Versions** Capgo versions prior to 12.261.1 **Description** The backend improperly restricts the roles that the `apikey manager` organization role can assign to new API keys. When an authenticated user with `apikey manager` permissions (specifically `org.manage apikeys` and `org.read`) calls the 'POST /apikey' endpoint, the system fails to verify if the caller possesses the permissions of the role being assigned. The validation process relies on a deny-list and a priority-rank comparison in the `createRoleBindingForPrincipal()` function. Since the deny-list omits several deploy roles—`app developer`, `app uploader`, `channel developer`, and `channel uploader`—and the `apikey manager` has a higher priority rank than these roles, the check is bypassed. This allows a user with limited privileges to create an API key with deploy roles and push arbitrary Over-the-Air (OTA) JavaScript updates to all end users of the organization's applications. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Capgo (capgo.app) versions prior to 12.261.0 **Description** An incomplete access-control fix in the `public.sso providers` table allows a user with `org admin` permissions and the `org.update settings` permission to perform vertical privilege escalation. While the `enforce sso provider client update guard()` function restricts updates to certain columns, the `provider id`, `metadata url`, and `attribute mapping` variables remain writable. Due to permissive table grants and row-level security policies that do not restrict specific columns, an attacker can use a PATCH request via PostgREST to change the `provider id` to an identity provider (IdP) they control. By asserting the organization owner's email through their own IdP, the attacker can merge their identity with the owner's account, resulting in account takeover, password nullification, and lockout of the legitimate owner. This requires the organization to have an active SSO provider configured and the attacker to already possess `org admin` status. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.