Airbyte Manifest Flaw Exploited in the Wild: A Crafted Connector Manifest Runs Code on Self-Managed Data Pipelines (CVSS 9.9, Patch 2.2.0)

Critical · 2026-11-09 · By H.A

A national CERT confirms active exploitation of a critical unsafe-reflection flaw in self-managed Airbyte, where a crafted connector manifest loads unintended classes to run code; a read-only role is enough on 2.x and legacy 1.x needs no authentication at all.

Overview

Japan's JPCERT/CC has confirmed that a critical code-execution flaw in self-managed Airbyte, the open-source data-integration platform, is being exploited in the wild. A malicious declarative connector manifest can make the Connector Builder / Manifest Server load and call unintended Python classes that are already installed in the container. The result is command execution, even when Airbyte's "unsafe code" option is switched off.

The fix is Airbyte 2.2.0. The 1.x line will not get a patch. Airbyte Cloud customers do not need to do anything.

Airbyte containers usually hold credentials for both source and destination systems: production databases, warehouses, SaaS APIs and cloud storage. A compromise can spread well beyond the Airbyte host.

The Vulnerability

• Component: Connector Builder and Manifest Server (declarative manifests with custom components)
• Weakness: unsafe reflection. The manifest controls which class is loaded (CWE-470), and on some deployments critical functions lack authentication (CWE-306).
• Severity: the vendor rates it Critical, CVSS 3.1 9.9. JVN scores it CVSS 3.0 8.8 / CVSS 4.0 8.7. The difference comes from the vendor treating scope as changed.
• Affected: self-managed Airbyte before 2.2.0
• Fixed: 2.2.0 (ships airbyte/manifest-server and airbyte-cdk 7.23.7)
• CVE: none assigned in the vendor advisory at the time of writing

Who can exploit it:

• Airbyte 2.x: any authenticated user with Workspace Reader or Organization Reader access, or higher. Read-only roles are enough to get code execution.
• Airbyte 1.x on the legacy Helm chart: no authentication at all. The Connector Builder service did not inherit the global.auth.enabled setting, so anyone who could reach it over the network could exploit it.

Timeline

• 17 October 2026: Airbyte publishes its security advisory and the 2.2.0 fix.
• 4 November 2026: JPCERT/CC publishes JVN#12040144 and states the flaw "has been confirmed to be exploited in the wild".
• Now: No public indicators of compromise or victim counts have been released.

Tradecraft

Attack details have not been published. Based on the flaw, the likely path is:

1. Get any low-privilege Airbyte account (through credential stuffing, a reused password or an invited guest), or reach an unauthenticated 1.x Connector Builder directly.
2. Submit a crafted declarative manifest that references a dangerous class already in the container's Python environment.
3. Run commands as the Airbyte user inside the Connector Builder / Manifest Server container.
4. Read connector configurations and environment variables to collect database, warehouse and cloud credentials. Then move to those systems or exfiltrate data through legitimate-looking sync jobs.

Detection

• Check your version and look for exposed Connector Builder services:

# running image versions
docker ps --format '{{.Image}}' | grep -i airbyte
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep -i -E 'airbyte|manifest-server|connector-builder'

• Review Connector Builder / Manifest Server logs for manifests with unusual class_name values that point outside your own custom component modules.
• Hunt for shell or network utilities (sh, bash, curl, wget, python -c, nc) spawned inside the manifest-server or connector-builder containers.
• Watch for outbound connections from those containers to destinations other than your configured sources, destinations and registries.
• Audit recent logins and new users with Reader roles, especially from unfamiliar IPs.
• Look for unexpected new connections, destinations or sync jobs pointing to unknown storage.

Recommended Actions

• Upgrade self-managed Airbyte to 2.2.0 or later now. Plan a migration off 1.x, which will stay vulnerable.
• Until patched, restrict network access so that only the Airbyte server can reach the Connector Builder / Manifest Server.
• Limit Workspace Reader and Organization Reader roles to trusted users, and remove stale or guest accounts.
• Do not set AIRBYTE_ENABLE_UNSAFE_CODE=true unless every workspace user is fully trusted.
• If the instance was reachable while unpatched, rotate every credential stored in Airbyte connections: database users, warehouse service accounts, API tokens and cloud keys. Then review access logs on those downstream systems.
• Never expose the Airbyte UI or API directly to the internet. Put it behind SSO and VPN or an identity-aware proxy.

Analyst Assessment

Data-pipeline tools are attractive, under-watched targets. One compromised Airbyte instance can hand an attacker credentials for a company's main data stores. Exploitation needs only a read-only role on 2.x, or nothing at all on legacy 1.x Helm deployments, and JPCERT/CC has confirmed active attacks. Treat this as an emergency patch for any internet-reachable or multi-user Airbyte deployment. The lack of a CVE id means vulnerability scanners keyed on CVE feeds may miss it, so check versions manually. Rotating credentials matters as much as patching: upgrading does not revoke secrets an attacker may already have copied.