Ya se explota el RCE 9,9 de Airbyte y la rama 1.x no tendrá parche

Un usuario con permiso de solo lectura abre el Connector Builder de Airbyte, cambia al editor YAML, pega un manifiesto que declara un componente personalizado con el nombre de una clase de Python ya instalada en el contenedor y pulsa el botón de prueba. El manifest-server carga esa clase, la ejecuta con los argumentos que lleva el manifiesto y el resultado es la ejecución de comandos dentro del contenedor, con las credenciales de todas las fuentes y destinos conectados al alcance. Así funciona el fallo que Airbyte publicó el 17 de octubre de 2026 en el aviso GHSA-g35w-6r6v-h4r7 con una puntuación CVSS 3.1 de 9,9, y que JPCERT/CC dio por explotado el 4 de noviembre en el aviso JVN#12040144. Solo la versión 2.2.0 lo corrige y la rama 1.x no recibirá parche.

• El fallo permite ejecutar comandos en el contenedor del manifest-server de Airbyte desde una lectura de prueba del Connector Builder. Airbyte le da un CVSS 3.1 de 9,9 y JVN, un 8,8.
• En Airbyte 2.x anterior a 2.2.0 basta un usuario con rol Workspace Reader. En 1.x con el chart de Helm heredado no hace falta autenticación.
• JPCERT/CC confirmó el 4 de noviembre de 2026 que ya se explota. No tiene CVE, no está en NVD ni en el catálogo KEV y INCIBE-CERT no ha publicado aviso.
• La única corrección es Airbyte 2.2.0 (manifest-server 7.23.7), publicada el 10 de agosto. La rama 1.x no recibirá parche.
• Mientras llega la migración, aísla el servicio del Connector Builder en la red, recorta los roles Reader y rota las credenciales si la instalación estuvo expuesta.

Una clase de Python en el YAML del Connector Builder, el fallo que Airbyte cerró en julio

Airbyte es una plataforma de integración de datos de código abierto. Mueve registros desde bases de datos, APIs y servicios SaaS hasta almacenes analíticos, y para hacerlo guarda las credenciales de cada fuente y de cada destino. El Connector Builder es su editor de conectores de bajo código. El usuario describe en un manifiesto YAML declarativo cómo pedir datos a una API y un servicio aparte, el manifest-server (hasta la versión 2.1 se llamaba connector-builder-server), ejecuta una lectura de prueba para comprobar que la definición funciona.

El manifiesto admite componentes personalizados. Cuando los integrados no bastan, el desarrollador escribe una clase de Python y la referencia en el YAML por su nombre completo, con un tipo como CustomPaginationStrategy y un campo class_name que apunta al módulo y la clase. La documentación de Airbyte avisa de que «Custom Components are currently considered UNSAFE and EXPERIMENTAL» (los componentes personalizados se consideran actualmente inseguros y experimentales), y por eso la función está desactivada por defecto detrás de la variable de entorno AIRBYTE_ENABLE_UNSAFE_CODE.

La captura de la documentación de Airbyte muestra el panel Custom Components del Connector Builder, donde el desarrollador escribe la clase de Python que después referencia desde el manifiesto YAML.

Esa variable solo cerraba una de las dos puertas. Según el aviso, hasta la versión 2.2.0 el Connector Builder y el manifest-server no restringían qué clases de Python podía referenciar un manifiesto como componente personalizado. La comprobación de AIRBYTE_ENABLE_UNSAFE_CODE cubría el código inyectado en el fichero components.py, pero no la ruta de resolución de class_name. El método create_custom_component de la fábrica de componentes importaba cualquier clase con nombre completo y la instanciaba con los argumentos que el propio manifiesto aportaba. El atacante no necesita subir código. Le basta con apuntar a objetos de Python ya presentes en el contenedor y elegir los argumentos. Es una debilidad de reflexión insegura, la CWE-470, y el aviso le suma la CWE-306 por la falta de autenticación en los despliegues antiguos.

La corrección llegó con el PR 1076 del CDK de Python, firmado por Aaron Steers y fusionado el 22 de julio de 2026. El cambio añade una comprobación al principio del método, antes de cualquier importación.

def create_custom_component(self, model, config, **kwargs):
    if not custom_code_execution_permitted():
        raise AirbyteCustomCodeNotPermittedError
    custom_component_class = self._get_class_from_fully_qualified_class_name(model.class_name)

Seis días después, el PR 1083 afinó la regla porque el cierre total rompía los conectores publicados por el propio Airbyte que usan componentes empaquetados. Desde entonces la confianza depende de la procedencia del manifiesto. El que se lee desde la imagen publicada del conector es de confianza, y el que llega inyectado desde el Connector Builder, el manifest-server o la línea de comandos queda bloqueado salvo que la variable esté activada. El resultado se publicó en el CDK 7.23.7 y en Airbyte 2.2.0, el 10 de agosto de 2026.

El vídeo es la demostración en directo del propio Airbyte (en inglés) sobre cómo se construye un conector en el Connector Builder y dónde encaja la configuración YAML que este fallo convierte en vector de ataque.

De Workspace Reader a comandos en el contenedor y, en Airbyte 1.x, sin ninguna credencial

Las condiciones de explotación dependen de la versión. En Airbyte 2.x anterior a 2.2.0 hace falta una cuenta autenticada con el rol Workspace Reader u Organization Reader, el más bajo de la plataforma. Cualquier analista con permiso para mirar un espacio de trabajo puede lanzar una lectura de prueba y, con ella, ejecutar comandos en el contenedor del manifest-server. De ahí el vector CVSS que publica Airbyte, con privilegios bajos, sin interacción del usuario y con cambio de alcance, porque el código sale del espacio de trabajo y llega al contenedor.

En Airbyte 1.x desplegado con el chart de Helm heredado la situación es peor. El servicio connector-builder-server no heredaba el ajuste global.auth.enabled, así que cualquier cliente con acceso de red a ese servicio podía explotar el fallo sin autenticarse. En un clúster donde ese servicio esté publicado fuera del espacio de nombres, o colgado por error de un balanceador, el ataque no necesita ninguna credencial.

El aviso GHSA-g35w-6r6v-h4r7 de Airbyte en GitHub separa los dos escenarios, el de 2.x con usuario autenticado y el de 1.x sin autenticación, y recoge la decisión de no corregir la rama antigua.

El impacto que describe el aviso es el que cabe esperar de un contenedor que habla con todo el stack de datos, con exposición de los datos, credenciales y secretos accesibles desde él y acceso a los servicios internos a los que llega. El propio texto fija dos límites. Afirma que «Airbyte Cloud customers do not need to take any action» (los clientes de Airbyte Cloud no tienen que hacer nada) y que «Airbyte 1.x will not receive a fix» (Airbyte 1.x no recibirá corrección). Quien siga en 1.x solo tiene una salida, migrar a 2.2.0 o posterior, y las notas de la versión avisan de que la migración de la base de datos es de un solo sentido y no permite volver a 2.1.x.

JPCERT/CC confirma la explotación y rebaja la nota de 9,9 a 8,8

El 4 de noviembre de 2026, JPCERT/CC e IPA publicaron el aviso JVN#12040144 con la etiqueta de urgente. El texto es escueto y contiene la frase que cambia la lectura del caso: «本脆弱性の悪用が確認されています» (se ha confirmado la explotación de esta vulnerabilidad). El aviso no dice quién ataca, desde cuándo ni cuántas instalaciones han caído, y hasta el 9 de noviembre ninguna organización ha reconocido públicamente una intrusión por esta vía. El descubrimiento se atribuye a Hyodo (兵藤壮泰), de la empresa japonesa ZOZO, que lo comunicó a IPA dentro del programa japonés de alerta temprana, y JPCERT/CC coordinó la publicación con Airbyte.

La página de JVN resume el fallo como reflexión insegura, lista las versiones 1.7.0 a 2.1.0 como afectadas y añade al final de la sección de detalles la nota sobre la explotación confirmada.

Hay dos discrepancias entre las fuentes que conviene dejar por escrito. La primera es la puntuación. Airbyte asigna un CVSS 3.1 de 9,9 con el vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, mientras que JVN publica un CVSS 3.0 de 8,8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) y un CVSS 4.0 de 8,7. La diferencia está en el alcance. Airbyte considera que el código ejecutado en el manifest-server traspasa el límite de seguridad del componente vulnerable (S:C) y JVN lo deja dentro (S:U). La segunda es el rango de versiones. Airbyte habla de todo lo anterior a 2.2.0 y JVN acota de 1.7.0 a 2.1.0. Ninguna de las dos fuentes explica ese límite inferior, así que quien administre una versión anterior a 1.7.0 debe asumir que también está expuesto.

El fallo tampoco tiene CVE. A 9 de noviembre de 2026 ni el aviso de GitHub ni el de JVN muestran identificador, y una búsqueda por Airbyte en NVD devuelve cuatro registros anteriores, ninguno de ellos este. El detalle afecta a quien priorice parches por CVE. Los escáneres que dependen de NVD no lo marcan y no entrará en el catálogo KEV de CISA mientras no exista identificador, por mucho que la explotación esté confirmada.

La cronología deja 68 días entre la publicación de 2.2.0 y el aviso que explicaba qué corregía. Nuestra lectura es que Airbyte trató el fallo como un cambio más del CDK, y durante esas diez semanas las instalaciones autoalojadas no tuvieron forma de saber que 2.2.0 era una actualización de seguridad. Cuando el aviso llegó, ya anunciaba que 1.x no tendría parche, y dieciocho días después JPCERT/CC confirmó la explotación. Es el mismo patrón que describimos el 8 de noviembre con Plex2Shell en los NAS de QNAP, un parche de agosto, un aviso tardío y ataques confirmados antes de que la mayoría supiera que debía actualizar.

Quién sigue expuesto, de los despliegues 1.x con Helm heredado a la ausencia de aviso en España

No hay recuento público de instalaciones de Airbyte accesibles desde internet. Al cierre de esta noticia ni Shodan, ni Censys ni Shadowserver han publicado una cifra para este producto, y el blog no va a inventarla. Airbyte suele vivir en clústeres de Kubernetes de equipos de datos, instalado con Helm o con abctl, casi siempre detrás de un acceso interno y con un número de usuarios que crece con cada analista que necesita mirar una conexión. El rol Workspace Reader se reparte con generosidad porque solo permite leer, y esta vulnerabilidad convierte ese permiso en ejecución de código.

El perfil de la víctima es el mismo que el del fallo CVSS 10 de GitLab que contamos en octubre, una plataforma interna de ingeniería que concentra los secretos de decenas de sistemas. Un contenedor de Airbyte comprometido da acceso a las credenciales de las bases de datos de producción, de los almacenes analíticos y de las APIs de los SaaS conectados, y a cualquier servicio interno que el pod alcance, el mismo botín de credenciales de IA y nube que se llevó la versión troyanizada de LiteLLM en octubre.

En España, INCIBE-CERT no había publicado aviso sobre este fallo a 9 de noviembre de 2026, y tampoco hay nota del CCN-CERT. La ausencia de CVE lo explica en parte, porque los avisos de INCIBE-CERT se construyen sobre identificadores y este fallo todavía no tiene. Quien use Airbyte en una organización española no va a recibir la alerta por los canales habituales y tendrá que llegar a ella por el repositorio del proyecto.

Airbyte arrastra tres avisos con CVE en cuatro meses, y el Connector Builder es el componente que más veces aparece en la lista. Los registros de NVD los recogen así, y el de 2024 ya apuntaba al mismo servicio.

El de agosto, CVE-2026-80049, permitía saltar entre espacios de trabajo con un identificador aportado por el cliente, y los dos de octubre, CVE-2026-92203 y CVE-2026-92204, los publicó ZDI en los conectores de SharePoint y OneDrive. El de 2024, CVE-2024-38363, era una ejecución de código por inyección de plantillas en la imagen del connection builder, el antecesor directo del servicio que ahora vuelve a fallar.

Subir a 2.2.0, aislar el manifest-server y rotar las credenciales de las fuentes

Antes de tocar nada conviene saber qué versión corre y si el servicio vulnerable está al alcance de alguien que no debería. Estos comandos listan las imágenes desplegadas en el espacio de nombres de Airbyte, comprueban si la variable que habilita el código personalizado está activada y muestran qué servicios están publicados.

kubectl -n airbyte get deploy -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'
kubectl -n airbyte get deploy -o yaml | grep -B2 -A1 AIRBYTE_ENABLE_UNSAFE_CODE
kubectl -n airbyte get svc,ingress

Si la imagen del manifest-server es anterior a 7.23.7, o aparece un despliegue connector-builder-server, la instalación es vulnerable. Estas son las acciones, por orden de urgencia.

1. Actualiza a Airbyte 2.2.0 o posterior con el chart de Helm V2 o con abctl. Haz antes copia de la base de datos, porque la migración no permite volver a 2.1.x, y comprueba que tu registro de imágenes sirve manifest-server 7.23.7 o los pods no arrancarán.
2. Si sigues en 1.x y no puedes migrar hoy, cierra el acceso de red al connector-builder-server para que solo el pod del servidor de Airbyte llegue a él. La política de red de más abajo sirve de contención mientras planificas la migración.
3. Revisa quién tiene Workspace Reader y Organization Reader y deja solo a los usuarios de confianza. Si AIRBYTE_ENABLE_UNSAFE_CODE está en true y nadie sabe por qué, desactívalo.
4. Busca en los registros del manifest-server y del connector-builder-server lecturas de prueba con componentes personalizados que nadie reconozca, procesos hijos inesperados y conexiones salientes hacia direcciones que no son fuentes ni destinos configurados.
5. Si la instalación estuvo expuesta y no puedes descartar la intrusión, rota todas las credenciales que Airbyte guarda (bases de datos, almacenes analíticos, tokens de SaaS y claves de nube) y las del propio clúster que el pod pudiera leer.
6. Notifica el incidente a INCIBE-CERT si eres una empresa y al CCN-CERT si perteneces al sector público.

Esta política de red limita el tráfico entrante al manifest-server a los pods del servidor de Airbyte dentro del mismo espacio de nombres, con las etiquetas que use tu chart.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: manifest-server-solo-airbyte-server
  namespace: airbyte
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: manifest-server
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app.kubernetes.io/name: server

La migración desde 1.x no es un parche. Airbyte 2.0 cambió el chart de Helm, la versión 2.1 retiró el connector-builder-server a favor del manifest-server y activó la autenticación por defecto en los despliegues nuevos, y 2.2 dejó de aceptar credenciales HTTP Basic en la API. Si gestionas el clúster, la guía del blog sobre seguridad en Kubernetes recoge cómo aislar espacios de nombres y limitar lo que un pod puede leer, y nuestro repaso de cómo proteger las APIs explica por qué una API interna sin autenticación acaba siendo externa.

Dudas habituales sobre Airbyte tras el aviso

Qué es Airbyte y para qué sirve

Airbyte es una plataforma de integración de datos de código abierto con cientos de conectores. Extrae datos de bases de datos, APIs y aplicaciones SaaS y los carga en almacenes como BigQuery, Snowflake o PostgreSQL para analítica e inteligencia artificial. Existe en versión gestionada, Airbyte Cloud, que no está afectada por este fallo, y en versión autoalojada sobre Kubernetes, que es la que hay que actualizar.

Cómo instalar Airbyte sin dejar expuesto el Connector Builder

Instala directamente la versión 2.2.0 o posterior con abctl o con el chart de Helm V2, que traen la autenticación activada por defecto y el manifest-server en lugar del antiguo connector-builder-server. No actives AIRBYTE_ENABLE_UNSAFE_CODE salvo que todos los usuarios con acceso a espacios de trabajo sean de confianza, publica solo el servicio del servidor web y deja el resto de pods accesibles únicamente desde dentro del clúster.