GitHub Trust Center API Auth Bypass and Cross-Tenant IDOR Vulnerabilities

Security Notes Summary 1. Privilege Escalation to OWNER via Overview: Elevating membership to OWNER is an operation restricted to existing OWNERS, an enforcement carried out by . The mutation (and its MCP function) creates a membership with a caller-chosen role but only grants the permission, which is restricted to the ADMIN role and never re-checks for OWNER permissions. Consequently, an Organization ADMIN can invoke to activate an attacker-controlled entity with the role, thereby gaining full OWNER privileges through the standard authorization flow (including Organization deletion, SAML/SSO and SCIM configuration, and Owner promotion/removal), even though ADMIN is explicitly denied these rights. Impact: Organization ADMIN can bypass OWNER privilege restrictions to obtain full OWNER privileges. Remediation: Both entry points now enforce owner-only authorization when the requested role is OWNER, mirroring . Ownership grants are subsequently merged into the fail-open allow/deny IAM policies (based on the requested ) to secure the OWNER fail-open across both the membership creation and membership update paths. 2. Cross-Tenant and Hidden Item Disclosure via in the Trust Center API Overview: The public Trust Center GraphQL API exposes with optional authentication. Its six type branches ( , , , , , and ) load objects from client-provided GIDs without comparing them against the access controls of the target Trust Center organization or its visibility filters. Unauthenticated access can read hidden items from such Trust Centers, as well as leaked names, descriptions, contact details, and connected items from any other organization (including those with undisclosed GIDs). Impact: Unauthenticated access can read hidden items and leaked information. Remediation: Each Trust API resolver now derives its scope from the organization of the active compliance page via . Reads are restricted to the page's tenant. Cross-tenant or unknown IDs are surfaced as "not found" rather than leaking data. 3. Broken Access Control in the Public E-Signature NDA API Overview: The public Trust Center mutations and are gated only by the existence of a session. The underlying service builds its tenant scope from the client-provided and never verifies whether the signature belongs to the caller. Any self-service Trust Center access holder possessing another access holder's signature GID can complete the other's NDA signature (overwriting signer IP, user agent, and triggering certificate sealing) or inject arbitrary audit events, breaking non-repudiation and compromising the integrity guarantees of the e-signature system. Impact: Self-service Trust Center access holders can complete other access holders' NDA signatures or inject arbitrary audit events. Remediation: signature operations now take scope provided by the caller rather than deriving it from the request ID, and / verify signature ownership before processing. Signer and actor emails are always derived from the verified signer identity rather than client input and are compared against the signer's stored . 4. Cross-Tenant IDOR via Unvalidated Foreign Key References Overview: Two console GraphQL resolvers authorize the parent object, then resolve objects related to tenant scopes derived from the related object's organization GID, rather than from the authorization result. An authorized member of one organization can attach the GID of a Risk or Data Protection Officer profile from another organization to their own finding or processing activity, and then read it back, revealing: - : Discloses another organization's risk details (name, description, treatment, category, severity, owner). - : Discloses another organization's PII (full name, email address, job title). Impact: Authorized members can read sensitive information from other organizations. Remediation: and now validate that referenced Risks and Data Protection Officer profiles belong to the caller's scope before storing the references, and the affected resolvers (along with other resolvers following the same pattern) now authorize the related object's own ID rather than the parent object. 5. GraphQL Alias Flood Denial of Service Overview: GraphQL endpoints ( , , and ) instantiate their servers without limits on query size or complexity. A single request containing thousands of alias resolver calls (e.g., repeated thousands of times) is parsed, executed, and marshaled upon completion, allowing attackers to drive excessive CPU and memory usage and degrade services for other tenants. Impact: Attackers can cause excessive CPU and memory usage, degrading service performance. Remediation: The shared GraphQL handler now enforces resolver token limits, which reject excessive queries before execution, applies a fixed query complexity limit, and utilizes an LRU query cache. These controls are configurable via the environment variables. 6. Open Redirect Bypass in Saferedirect Overview: Relative redirect URLs are now normalized before validat

Goal Reached Thanks to every supporter — we hit 100%!

GitHub Trust Center API Auth Bypass and Cross-Tenant IDOR Vulnerabilities

More from this source