CVE-2026-80049: Airbyte Platform through 2.0.0 Cross-Workspace Authorization Bypass via Caller-Supplied workspaceId
Airbyte Platform resolves the workspace used for its authorization decision from a field the caller supplies. AuthorizationServerHandler copies recognised identifiers out of the raw JSON request body into X-Airbyte- headers, and AuthenticationHeaderResolver.resolveWorkspace consults X-Airbyte-Workspace-Id ahead of every resource-derived header, including those for connection, source and destination identifiers. Endpoints whose declared request bodies carry only a resource identifier are nonetheless reached with an added workspaceId field, because the extractor reads the body rather than the endpoint's schema, so the permission check is performed against the workspace the caller nominated while the handler acts on the resource identifier the caller supplied. Nothing afterwards compares the resource's owning workspace with the one that was authorized. A member of any workspace can therefore read source and destination configuration, trigger and cancel syncs, and delete connections, sources and destinations that belong to workspaces they have no access to, at whatever privilege level their own workspace membership grants them.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 2.0.0Patch Cross-Workspace Authorization Bypass via Caller-Supplied workspaceId - Compensating control
Restrict access to Airbyte API endpoints so that callers cannot supply or influence a workspaceId (e.g., ensure requests are authorized strictly against the caller’s server-side workspace context, not a caller-supplied field such as X-Airbyte-Workspace-Id).
Event History
Frequently Asked Questions
Who can exploit this issue?
Any authenticated member of an Airbyte workspace can exploit it against resources in other workspaces. The impact is limited by the privilege level granted to the attacker in their own workspace, but can include reading source and destination configuration, triggering or cancelling syncs, and deleting connections, sources, or destinations.
What does an attacker need to provide in a request?
The attacker needs a target resource identifier and a caller-supplied workspaceId field naming a workspace where they hold the required permission. The authorization check uses the supplied workspaceId, while the operation is performed on the separately supplied resource identifier.
Are only endpoints that explicitly accept a workspaceId affected?
No. Endpoints whose declared request body contains only a resource identifier can also be reached with an added workspaceId field, because the identifier extraction reads the raw JSON body rather than enforcing the endpoint request schema.