GHSA-cp3j-m783-3ph5: High severity go/github.com/identrail/identrail vulnerability
Summary
identrail's GitHub App connection-completion endpoint binds a fully client-supplied installationid to the caller's workspace without verifying that the installation belongs to, or was installed by, the workspace that initiated the connect flow. identrail then mints a GitHub App installation access token for the supplied installationid using the app's own JWT, so an authenticated tenant can link any other identrail customer's GitHub App installation into their own workspace and read that victim organization's private repositories.
Affected code (default-on path, no feature flag)
- Route: internal/api/router.go:3590 — POST /v1/workspaces/:workspaceid/projects/:projectid/github/connect/complete. installationid is read from the JSON body or the attacker-controlled X-GitHub-Installation-ID header (router.go:3582-3588). - Service: internal/api/githubconnect.go:781 CompleteGitHubConnection. The state token IS rigorously bound to the caller's scope (githubconnect.go:818: if stateRecord.TenantID != scope.TenantID || stateRecord.WorkspaceID != project.WorkspaceID || stateRecord.ProjectID != project.ProjectID { ... }), but the only check on installationid is request.InstallationID <= 0 (:794). The raw client value is persisted as the workspace's connection (:840). - Cross-tenant read primitive: internal/connectors/github/repositories.go:39 ListInstallationRepositories → internal/connectors/github/app.go:170 mints a token via POST /app/installations/{installationId}/accesstokens signed with the App JWT, succeeding for any installation where identrail's app is installed.
The feature-flagged V2 path CompleteGitHubConnector (githubconnect.go:447, default off) shares the gap and is additionally weaker (matches pending connector by state value alone with no caller-scope re-check); a single fix should cover both.
Intent proof
The code binds state to {TenantID, WorkspaceID, ProjectID} and re-verifies it at completion (:818), demonstrating it understands binding is required. The asymmetry — state bound, installationid unbound — is the missed check.
Exploitation
1. Attacker is any authenticated identrail tenant; they call StartGitHubConnection for their own workspace and receive a state. 2. Attacker calls the completion route with {state: <their state>, installationid: V} where V is a victim org's identrail GitHub App installation id (installation ids are not secret — they appear in post-install redirect URLs, webhook payloads, the org's GitHub App settings, and are enumerable integers). 3. CompleteGitHubConnection accepts (state matches attacker scope), ListInstallationRepositories(V) mints a token for V and lists the victim org's private repos, and the connection is persisted under the attacker's workspace. 4. Attacker now reads the victim org's private repository inventory and can drive posture scans/repo reads via their own workspace.
Impact: cross-tenant disclosure of another customer organization's private GitHub repositories and metadata.
Remediation
Bind installationid with the same rigor as state: capture it from GitHub's signed post-install redirect (setupurl/callbackurl) and pin it to the pending state at start time, and/or after minting verify the installation's account matches the org the initiating workspace is authorized for.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/identrail/identrailto a version that resolves this vulnerability.Fixed in 1.0.2 - Configuration
In CompleteGitHubConnection, after reading InstallationID from the JSON body or the X-GitHub-Installation-ID header (internal/api/router.go:3582-3588), add a caller-scope authorization check so the supplied installation_id is authorized for the initiating {TenantID, WorkspaceID, ProjectID} (similar to the existing state re-check at internal/api/github_connect.go:818). Only proceed to POST /app/installations/{installationId}/access_tokens and repository listing if the installation belongs to the org associated with the initiating workspace/project; do not accept an attacker-supplied victim installation_id. Apply the same fix to the V2 completion path referenced as CompleteGitHubConnector in internal/api/github_connect.go:447 so both code paths consistently enforce the installation-to-initiator binding.
identrail GitHub connection completion endpoint (POST /v1/workspaces/:workspace_id/projects/:project_id/github/connect/complete) installation_id binding/authorization = Bind request.InstallationID to the initiating workspace/project scope and verify the installation belongs to (was installed for) that org before minting any GitHub App access token
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated identrail tenant can exploit it by completing a GitHub connection for their own workspace while supplying another customer's GitHub App installation ID. The connection-completion endpoint accepts the installation ID from either the JSON body or the X-GitHub-Installation-ID header.
Does the connection state token prevent cross-tenant repository access?
No. The state token is checked against the caller's tenant, workspace, and project, but that validation does not verify that the supplied GitHub installation belongs to the workspace that initiated the flow.
Is this limited to an optional GitHub integration configuration?
No. The affected connection-completion path is described as default-on and does not require a feature flag.
How can I determine whether my deployment contains the vulnerable behavior?
Inspect the POST /v1/workspaces/:workspace_id/projects/:project_id/github/connect/complete path and CompleteGitHubConnection implementation. Affected code accepts a client-supplied installation_id and mints an installation token without verifying that the installation belongs to, or was installed by, the initiating workspace.