Summary
  • JPCERT/CC confirms the flaw is exploited in the wild.
  • The flaw is unsafe reflection in Connector Builder.
  • All Airbyte versions before 2.2.0 are affected.
  • Airbyte 1.x will not receive a fix.

What Airbyte fixed in 2.2.0

Airbyte published a security advisory for its Connector Builder. The flaw is unsafe reflection, listed as Common Weakness Enumeration (CWE) 470. Connector Builder and Manifest Server did not limit which Python classes a manifest could call. A user who could submit a manifest could load Python objects already in the container. That load could run arbitrary commands inside the container. The flaw worked even when unsafe code was turned off. Airbyte rates the flaw critical, with a Common Vulnerability Scoring System (CVSS) 3.1 score of 9.9. The Japan Computer Emergency Response Team Coordination Center (JPCERT/CC) lists 8.8 under CVSS 3.0 and 8.7 under CVSS 4.0. Use the 9.9 vendor score as the planning number.

Exploitation is confirmed

Japan Computer Emergency Response Team Coordination Center (JPCERT/CC) states the flaw is exploited in the wild. The advisory was published on November 4, 2026. Airbyte 2.x before 2.2.0 is affected. An authenticated user with Workspace Reader access or higher could run commands in the Manifest Server container. Airbyte 1.x with the legacy Helm chart is worse. There, any client with network access to Connector Builder could exploit it without logging in. Airbyte 1.x will not receive a fix. Airbyte Cloud customers need no action.

What to do now

Upgrade self-managed Airbyte to 2.2.0 or later. That release ships manifest-server 7.23.7. Restrict network access to Connector Builder and Manifest Server until the upgrade lands. Limit Workspace Reader and Organization Reader access to trusted users. Review container logs for odd manifest submissions. Rotate stored credentials that the container could reach.

The governance lesson

A data tool holds the keys to other systems. Connector Builder reaches sources, targets, and secrets. A flaw in that tool is a flaw in every pipeline it touches. Version 1.x has no fix, so an upgrade is the only path. Record the Airbyte version on each deployment. Record the upgrade date and the new version. Record who holds Reader access on each workspace. That record turns a version check into proof.

Sources

Next step

Upgrade self-managed Airbyte to 2.2.0, then confirm the version on every deployment.

Questions on this record
Which versions are affected?
All Airbyte versions before 2.2.0 are affected. Airbyte 1.x will not receive a fix. Upgrade to 2.2.0 or later.
Is exploitation confirmed?
Yes. JPCERT/CC states the flaw has been confirmed as exploited in the wild. The advisory was published on November 4, 2026.
Does Airbyte Cloud need action?
No. Airbyte states that Airbyte Cloud customers do not need to take any action.
Is there a CVE number?
No CVE number was listed in the advisories as of November 5, 2026. The GHSA advisory and the JVN record are the primary sources.

Related records

Guides and articles describe the work. The evidence that work produces is described in three proof pages and one architecture page.

proof.state
Proof of State. What the environment was, as of a date someone else picks: point-in-time records, content hashed and chained.
proof.change
Proof of Change. Who or what altered the environment, under what authority, with before and after state hashes.
proof.agency
Proof of Agency. What a machine was permitted to do before it acted, what it did, and what would have stopped it.
architecture
Architecture. How the chain is built and where it lives: inside your tenant, with no egress of evidence.

Further reading in this register

Verify the record this entry describes.

Published
Last updated
Unchanged since publication
Author
Leonard Esere