Go · github.com/identrail/identrail
Identrail Cross-tenant IDOR: Client-supplied GitHub App installation_id is bound to the caller's workspace without ownership verification
identrail's GitHub App connection-completion endpoint binds a fully client-supplied installation_id 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 installation_id 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.
internal/api/router.go:3590 — POST /v1/workspaces/:workspace_id/projects/:project_id/github/connect/complete. installation_id is read from the JSON body or the attacker-controlled X-GitHub-Installation-ID header (router.go:3582-3588).internal/api/github_connect.go:781 CompleteGitHubConnection. The state token IS rigorously bound to the caller's scope (github_connect.go:818: if stateRecord.TenantID != scope.TenantID || stateRecord.WorkspaceID != project.WorkspaceID || stateRecord.ProjectID != project.ProjectID { ... }), but the only check on installation_id is request.InstallationID <= 0 (:794). The raw client value is persisted as the workspace's connection (:840).internal/connectors/github/repositories.go:39 ListInstallationRepositories → internal/connectors/github/app.go:170 mints a token via POST /app/installations/{installationId}/access_tokens signed with the App JWT, succeeding for any installation where identrail's app is installed.The feature-flagged V2 path CompleteGitHubConnector (github_connect.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.
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, installation_id unbound — is the missed check.
StartGitHubConnection for their own workspace and receive a state.{state: <their state>, installation_id: 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).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.Impact: cross-tenant disclosure of another customer organization's private GitHub repositories and metadata.
Bind installation_id with the same rigor as state: capture it from GitHub's signed post-install redirect (setup_url/callback_url) 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.
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.