Summary
identrail does not verify that a supplied GitHub installation ID belongs to the requesting workspace before associating it with a project. An authenticated tenant that can initiate a GitHub connection may use another customer's non-secret installation ID to access private repository inventories, content, metadata, or posture-scan data when the shared GitHub App is installed there.
identrail does not verify that a supplied GitHub installation ID belongs to the requesting workspace before associating it with a project. An authenticated tenant that can initiate a GitHub connection may use another customer's non-secret installation ID to access private repository inventories, content, metadata, or posture-scan data when the shared GitHub App is installed there.
Affected context
The issue affects identrail GitHub connection workflows where an installation ID is accepted from a request body or HTTP header. The vulnerable behavior is present when the GitHub App is installed in multiple customer organizations and the service persists or uses an installation ID without confirming ownership by the caller's tenant, workspace, or project. The related V2 connector path also requires careful scope validation when matching pending connection state.
The issue affects identrail GitHub connection workflows where an installation ID is accepted from a request body or HTTP header. The vulnerable behavior is present when the GitHub App is installed in multiple customer organizations and the service persists or uses an installation ID without confirming ownership by the caller's tenant, workspace, or project. The related V2 connector path also requires careful scope validation when matching pending connection state.
Exploit preconditions
- Attack surface: Authenticated GitHub connection completion endpoints
- Required access: A valid identrail tenant account capable of initiating a legitimate GitHub connection
- Trigger point: Submission of a GitHub installation ID during connection completion
- Target condition: The installation ID belongs to another customer's organization and identrail's GitHub App is installed there
- Why exploitation is possible: The service checks that the identifier is positive but does not verify that it is owned by the caller's tenant, workspace, or project before requesting installation credentials
- Attack surface: Authenticated GitHub connection completion endpoints
- Required access: A valid identrail tenant account capable of initiating a legitimate GitHub connection
- Trigger point: Submission of a GitHub installation ID during connection completion
- Target condition: The installation ID belongs to another customer's organization and identrail's GitHub App is installed there
- Why exploitation is possible: The service checks that the identifier is positive but does not verify that it is owned by the caller's tenant, workspace, or project before requesting installation credentials
Why this happens
The underlying bug is a missing object-level authorization check. Although the connection state is bound to the caller's tenant, workspace, and project in the primary flow, the GitHub installation object supplied by the caller is not independently authorized against that scope. The service therefore treats a caller-controlled identifier as trusted and uses the application's GitHub credentials to access the referenced installation. This maps primarily to CWE-639: Authorization Bypass Through User-Controlled Key and also reflects CWE-862: Missing Authorization.
The underlying bug is a missing object-level authorization check. Although the connection state is bound to the caller's tenant, workspace, and project in the primary flow, the GitHub installation object supplied by the caller is not independently authorized against that scope. The service therefore treats a caller-controlled identifier as trusted and uses the application's GitHub credentials to access the referenced installation. This maps primarily to CWE-639: Authorization Bypass Through User-Controlled Key and also reflects CWE-862: Missing Authorization.
Potential impact
- An attacker may enumerate private repositories belonging to another customer
- Repository content and metadata could be exposed across tenant boundaries
- Unauthorized posture scans could be initiated against a victim organization
- Sensitive organizational structure and source-code information could be disclosed
- Cross-tenant trust boundaries could be weakened through unauthorized connector persistence
- An attacker may enumerate private repositories belonging to another customer
- Repository content and metadata could be exposed across tenant boundaries
- Unauthorized posture scans could be initiated against a victim organization
- Sensitive organizational structure and source-code information could be disclosed
- Cross-tenant trust boundaries could be weakened through unauthorized connector persistence
General mitigation guidance
Mitigation generally centers on enforcing object-level authorization at every boundary where external identifiers are accepted or used.
Common defensive patterns include:
- Resolve GitHub installation ownership server-side rather than trusting request-supplied identifiers
- Bind installation records to the authenticated tenant, workspace, and project before persistence or token creation
- Revalidate caller scope when consuming pending connection state, including connector-specific flows
- Prefer opaque, server-managed connection references over externally supplied provider identifiers
- Apply least privilege to GitHub App permissions and limit repository access where practical
- Record authorization decisions and reject ambiguous or cross-tenant installation mappings by default
Mitigation generally centers on enforcing object-level authorization at every boundary where external identifiers are accepted or used.
Common defensive patterns include:
- Resolve GitHub installation ownership server-side rather than trusting request-supplied identifiers
- Bind installation records to the authenticated tenant, workspace, and project before persistence or token creation
- Revalidate caller scope when consuming pending connection state, including connector-specific flows
- Prefer opaque, server-managed connection references over externally supplied provider identifiers
- Apply least privilege to GitHub App permissions and limit repository access where practical
- Record authorization decisions and reject ambiguous or cross-tenant installation mappings by default
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review rules for request-controlled identifiers passed to provider APIs
- Review of authorization checks before persistence, token creation, and repository enumeration
- Tests that attempt to use installation identifiers from a different tenant, workspace, or project
- API policy checks requiring tenant and resource ownership validation for every connector operation
- Audit-log correlation between connection requests, installation IDs, token creation, and repository access
- Automated security review tools that flag missing object-level authorization and insecure direct object references
Organizations can look for this class of issue through:
- Static analysis and code review rules for request-controlled identifiers passed to provider APIs
- Review of authorization checks before persistence, token creation, and repository enumeration
- Tests that attempt to use installation identifiers from a different tenant, workspace, or project
- API policy checks requiring tenant and resource ownership validation for every connector operation
- Audit-log correlation between connection requests, installation IDs, token creation, and repository access
- Automated security review tools that flag missing object-level authorization and insecure direct object references
