Airbyte Connector Builder RCE (GHSA-g35w-6r6v-h4r7): exploitation confirmed, upgrade self-managed deployments

On 4 November 2026, JVN published advisory JVN#12040144 for an arbitrary-code-execution vulnerability in Airbyte. The same issue is documented in Airbyte’s GitHub security advisory GHSA-g35w-6r6v-h4r7 (published 17 October 2026). JVN states that exploitation of this vulnerability has been confirmed in the wild. Self-managed deployments below 2.2.0 should treat this as an urgent upgrade and hardening task. Airbyte Cloud customers do not need to take action.

What changed

• 17 October 2026: Airbyte published GHSA-g35w-6r6v-h4r7, describing remote code execution via Connector Builder custom components even when AIRBYTE_ENABLE_UNSAFE_CODE was not enabled. The fix ships in Airbyte 2.2.0 with airbyte/manifest-server 7.23.7 (airbyte-cdk 7.23.7).
• 10 August 2026: Airbyte 2.2 was released; the release notes update the bundled Manifest Server image to tag 7.23.7 (from 7.10.0). Plan the upgrade carefully: Airbyte documents 2.2.0 as a one-way migration that drops tables 2.1.x depends on, so take a database backup before upgrading.
• 4 November 2026: JVN#12040144 published. English wording: “Note that the vulnerability has been confirmed to be exploited in the wild.” Japanese: 「なお、本脆弱性の悪用が確認されています。」

No CVE identifier is listed in the GitHub advisory’s CVE field or in the JVN advisory’s CVE column as of this draft. Refer to the issue by GHSA-g35w-6r6v-h4r7 and JVN#12040144 until a CVE is assigned.

What the vulnerability is

At a high level, before 2.2.0 the Connector Builder and Manifest Server did not adequately restrict which Python classes a declarative connector manifest could reference as a custom component. A party able to submit a manifest for a Connector Builder test read could cause the service to load and invoke unintended objects already present in the container, leading to arbitrary command execution inside the Connector Builder or Manifest Server container. This applied even when unsafe custom code was disabled via configuration.

JVN classifies the issue as unsafe reflection (CWE-470) and rates it CVSS 8.7 (v4.0) / 8.8 (v3.0). Airbyte’s advisory rates it Critical under CVSS 3.1 and also cites CWE-306 (missing authentication for critical functionality) alongside CWE-470.

We are not publishing technical exploitation details, payloads, or reproduction steps. The defensive point is that the affected services must be upgraded and kept off untrusted networks.

Who is affected

Treat any self-managed deployment below 2.2.0 as in scope. Prefer the broader vendor/English JVN bound (< 2.2.0) over the narrower Japanese product list when inventorying.

Impact differs by major line, per Airbyte:

• Airbyte 2.x before 2.2.0: an authenticated user with Workspace Reader or Organisation Reader access (or higher) could execute commands in the Manifest Server container.
• Airbyte 1.x with the legacy Helm chart: the Connector Builder service did not inherit global.auth.enabled, so any client with network reachability to Connector Builder could abuse the issue without authenticating.
• Airbyte 1.x will not receive a fix. Upgrade to 2.2.0 or later.
• Airbyte Cloud: no action required.

Successful abuse may expose data, credentials and secrets available to the affected container, and may allow access to internal services reachable from it.

What to do now

1. Inventory every self-managed Airbyte deployment (production, staging, lab). Record the Airbyte version and whether Connector Builder / Manifest Server are reachable beyond the Airbyte server.
2. Upgrade to Airbyte 2.2.0 or later. Follow Airbyte’s 2.2 release notes: take a database backup first; the 2.2.0 migration is one-way and rolling back to 2.1.x is not supported. If you mirror or pin images, ensure Manifest Server tag 7.23.7 is available before upgrading.
3. Until upgraded, restrict network access so that only the Airbyte server can reach the Connector Builder / Manifest Server services. Do not expose these services to the internet or to broad internal networks.
4. Tighten roles: limit Workspace Reader and Organisation Reader (and higher) to trusted users only. On 1.x legacy Helm deployments, treat any network path to Connector Builder as a potential unauthenticated exposure until you are off that line.
5. Do not enable AIRBYTE_ENABLE_UNSAFE_CODE=true unless every user with workspace access is trusted. Airbyte notes that setting enables intentional custom code in Connector Builder manifests.
6. After upgrade, confirm the running Manifest Server image is 7.23.7 (or newer if your chart advances), re-check that Builder/Manifest Server remain reachable only from the Airbyte server, and review who holds Reader-or-higher roles.

What this is not

This post does not include exploit steps, PoCs, bypass techniques, or payload examples. Defenders need the affected version range, the fixed release, network and role hardening, and the JVN confirmation that exploitation has been observed — not a reproduction guide.

Sources

• JVN#12040144 (Japanese)
• JVN#12040144 (English)
• GitHub Security Advisory GHSA-g35w-6r6v-h4r7
• Airbyte 2.2 self-managed release notes