Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-25T19:16:55.340Z",
  "pubdate": "2026-08-25T19:16:55.340Z",
  "executiveSummary": "Airbyte Platform is susceptible to a severe authorization bypass vulnerability due to improper trust placed in user-supplied headers during cross-workspace resource access checks.\nThe vulnerability allows an authenticated attacker, holding membership in any legitimate Airbyte workspace, to perform unauthorized actions on resources—including connections, sources, and destinations—belonging to arbitrary workspaces.\nBy manipulating the X-Airbyte-Workspace-Id header, an attacker can influence the authorization decision process, causing the AuthorizationServerHandler to validate permissions against a user-controlled workspace while the backend logic subsequently operates on a resource identifier specified in the request body.\nBecause the system fails to verify that the target resource is strictly owned by the authorized workspace, the application suffers from a critical broken access control issue.\nAn attacker can read sensitive configuration data, trigger or cancel synchronization jobs, and perform destructive operations like deleting resources across the entire platform instance, regardless of original access control lists. This poses a significant risk to data confidentiality, integrity, and availability within multi-tenant Airbyte deployments.",
  "technicalDetails": "The root cause of this vulnerability lies in the decoupling of authorization context from resource ownership validation within the Airbyte Platform's request processing pipeline.\nThe AuthenticationHeaderResolver.resolveWorkspace component is designed to determine the workspace context for an incoming request. It prioritizes the X-Airbyte-Workspace-Id header over resource-specific identifiers such as connection, source, or destination IDs. The AuthorizationServerHandler extracts these identifiers directly from the raw JSON request body rather than relying on validated endpoint schemas.\nThe attack flow follows a predictable sequence: First, the attacker authenticates as a legitimate user within any workspace. Second, the attacker crafts a malicious request targeting a specific resource (e.g., a source or connection) belonging to a victim workspace. Third, the attacker includes a spoofed X-Airbyte-Workspace-Id header in the request, corresponding to a workspace they are authorized to access.\nWhen the platform processes the request, the AuthenticationHeaderResolver evaluates the user's permissions based on the spoofed workspace ID provided in the header. Since the attacker has valid credentials for that specific (often attacker-controlled or dummy) workspace, the authorization check passes successfully.\nCritically, once the authorization decision is finalized, the platform passes the request to the backend handler. This handler processes the resource identifier provided in the JSON body. Because the system lacks a subsequent validation step to ensure that the resolved resource actually belongs to the authorized workspace, the platform performs the requested operation (GET, POST, DELETE, etc.) on the victim's resource.\nThis logic flaw effectively bypasses workspace isolation. An attacker can enumerate resource identifiers and manipulate them by injecting them into the body of requests authenticated against their own workspace. The exploit requires only standard user-level privileges within the platform, no elevated administrative rights are necessary. The impact of this vulnerability is total, enabling unauthorized access to configuration data and the ability to interfere with critical data pipeline operations across the entire installation."
}