Airbyte Vulnerability Checklist: Patch, Rotate and Hunt After the Exploited Connector Builder RCE

Self-hosted Airbyte is the pipe between your production systems and your data warehouse, and it holds the credentials for both ends. On 4 November 2026, Japan’s JPCERT/CC warned that a critical Airbyte flaw, rated CVSS 9.9 by the vendor, has been confirmed as exploited in the wild. That makes this an Airbyte vulnerability checklist day. Upgrading is the first step, but it is not the last: if someone ran code inside your Manifest Server before you patched, the upgrade does nothing about the secrets they could reach.

This is a practical, ordered checklist for the people who run self-managed Airbyte: data platform engineers, cloud teams and the security team that has to sign the incident off.

What the flaw is

Airbyte’s advisory, GHSA-g35w-6r6v-h4r7, is titled “Remote code execution via Connector Builder custom components when unsafe code is disabled.” In Airbyte’s words: “In Airbyte versions before 2.2.0, the Connector Builder and Manifest Server did not restrict which Python classes a declarative manifest could reference as a custom component.”

Put simply, a user submits a connector manifest for a Connector Builder test read. That manifest could name arbitrary Python classes, and the server would load them. Three details matter:

• The safety switch did not help. The issue worked even when AIRBYTE_ENABLE_UNSAFE_CODE was not enabled. Teams that had deliberately kept custom code turned off were still exposed.
• The bar for an attacker is low. On Airbyte 2.x before 2.2.0, any authenticated user with Workspace Reader or Organization Reader access, or higher, could execute commands in the Manifest Server container. A read-only role is enough.
• Legacy 1.x deployments are worse. On Airbyte 1.x deployed with the legacy Helm chart, the Connector Builder service did not inherit the global.auth.enabled setting. Any client with network access to that service could exploit it without logging in.

The CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. The “Scope: Changed” part is the important one: the compromise does not stay inside the component that is vulnerable. The advisory lists CWE-470 (unsafe reflection) and CWE-306 (missing authentication for a critical function). At the time of writing, the GitHub advisory lists no CVE ID; JPCERT/CC tracks it as JVN#12040144.

Fixed in: Airbyte 2.2.0, which ships airbyte/manifest-server 7.23.7 (airbyte-cdk 7.23.7). After the fix, custom components in Connector Builder manifests are rejected unless AIRBYTE_ENABLE_UNSAFE_CODE=true.

Not fixed: Airbyte 1.x will not receive a fix. Airbyte Cloud customers need take no action, according to the vendor.

Why the impact is bigger than one container

Airbyte’s own impact statement is frank: successful exploitation “may expose data, credentials and secrets available to the affected container, and may allow access to internal services reachable from it.”

Consider what a typical ELT deployment can reach. It holds read credentials for production databases and SaaS APIs, and write credentials for Snowflake, BigQuery, Redshift or an S3 bucket. It often runs in a Kubernetes cluster with network paths to internal services that nothing on the internet can reach directly. An attacker who gets code execution in that environment does not need to break in anywhere else. The pipeline already has the keys.

The advisory was published on GitHub around mid-October; exploitation reports followed in early November. According to SecurityOnline’s report on the JVN notice, JPCERT/CC has not said who is behind the attacks or how many systems were hit. Treat any unpatched self-managed instance that was reachable by untrusted users as a possible incident, not just a patching task.

The checklist

1. Find every instance — before you patch anything

Self-hosted data tooling is often stood up by a data team in a project the security team never sees. Search all cloud accounts and clusters for Airbyte workloads: container images named airbyte/*, Helm releases, and VMs running Docker Compose deployments. Include staging, sandboxes and that proof-of-concept cluster from last year. Record the version and whether each instance is self-managed or Airbyte Cloud (Cloud needs no action).

2. Cut exposure while you schedule the upgrade

Airbyte’s interim mitigations are:

• Restrict network access to the Connector Builder / Manifest Server service so that only the Airbyte server can reach it.
• Limit Workspace Reader and Organization Reader access to trusted users.

For 1.x on the legacy chart, the network restriction is not optional. Without it, anyone who can reach the service can run code.

3. Upgrade to 2.2.0 or later, and retire 1.x

Upgrade every self-managed instance to 2.2.0+. Afterwards, confirm the running Manifest Server image is 7.23.7 or later. Do not stop at “the Helm release says 2.2.0”. 1.x has no fix, so a 1.x instance is either upgraded or decommissioned. “We’ll accept the risk” is not a real option for an unauthenticated RCE on a credential store.

4. Check that AIRBYTE_ENABLE_UNSAFE_CODE is set the way you think it is

After the fix, this flag is what decides whether custom components run. Airbyte warns that enabling it “intentionally allows custom code in Connector Builder manifests. Only enable it if all users with workspace access are trusted.” If it is true anywhere, write down why, and who approved it.

5. Review who holds Reader roles

The fix closes this bug, but it should change how you think about read-only access in this tool. List every user with Workspace Reader, Organization Reader or higher. Remove leavers, contractors and anyone who no longer needs access. Before 2.2.0, a Reader role could run code, so look at this list as if it had been an admin list.

6. Rotate every credential the instance could reach

This is the step that patching does not do for you. The advisory confirms that secrets available to the affected container were exposed. For any instance that was unpatched and reachable by untrusted users or networks:

• Rotate credentials for every source and destination connector: database users, SaaS API tokens, warehouse service accounts, object-storage keys.
• Rotate any cloud identity the Airbyte pods or VMs ran under (IAM role keys, service-account keys, workload identity bindings), and review what those identities were allowed to do.
• If Airbyte reads its secrets from an external secret manager, review that manager’s access logs for reads from the Airbyte workload outside normal sync patterns.

We made a similar point about vendor and supply-chain access in our third-party cloud access review. The question is always “what could this identity reach?”, not “was this host patched?”

7. Hunt before you close the ticket

Airbyte’s advisory does not publish indicators. SecurityOnline’s guidance, written in light of the exploitation reports, is to review container logs as well. Practical places to look:

• Connector Builder test reads submitted by unexpected users, or at unusual times.
• Process execution or outbound network connections from the Manifest Server container that do not fit its normal job.
• Unusual use of the connector credentials in step 6 at the far end: new query patterns in the warehouse, bulk reads from source databases, object-storage access from unfamiliar IPs.

If you find something, treat it as a data-platform breach and widen the scope to everything the pipeline could write to.

The CloudShieldSecure perspective

The hardest step on this list is the first one. Self-hosted data tools sit between the application team and the security team, and they rarely appear in either team’s inventory. CloudShieldSecure, built by CloudKonsult, continuously discovers workloads across your cloud accounts and Kubernetes clusters, flags versions that are exposed or out of date, and maps which cloud identities and secrets each workload can reach. That turns “patch Airbyte” into a specific list: these instances, these identities, these credentials to rotate. Continuous monitoring of identity and configuration then shows whether any of those credentials are behaving differently after the fact.

Recommended actions — summary

1. Inventory all self-managed Airbyte deployments, including non-production.
2. Restrict network access to the Connector Builder / Manifest Server now.
3. Upgrade to 2.2.0+ (Manifest Server 7.23.7+); decommission 1.x.
4. Confirm AIRBYTE_ENABLE_UNSAFE_CODE is off unless there is a documented reason.
5. Prune Workspace/Organization Reader membership.
6. Rotate every connector credential and workload identity that the instance could reach.
7. Review container, secret-manager and warehouse logs before closing.

Sources & references

• Airbyte security advisory GHSA-g35w-6r6v-h4r7 — https://github.com/airbytehq/airbyte/security/advisories/GHSA-g35w-6r6v-h4r7
• JPCERT/CC / JVN, JVN#12040144 — https://jvn.jp/en/jp/JVN12040144/index.html
• Airbyte self-managed v2.2 release notes — https://docs.airbyte.com/release_notes/self-managed/v-2.2
• SecurityOnline, “Airbyte Vulnerability Exploited in the Wild” (4 Nov 2026) — https://securityonline.info/airbyte-vulnerability-exploited/