Actores de amenazas investigan la falla CVE-2026-20896 de Gitea Docker 13 días después de la divulgación – CYBERDEFENSA.MX

Se ha observado que los actores de amenazas intentan explotar una falla de seguridad crítica recientemente reparada en las imágenes de Gitea Docker. según Sysdig.

La vulnerabilidad en cuestión es CVE-2026-20896 (Puntuación CVSS: 9,8), una vulnerabilidad que surge de que la plataforma DevOps confía en el encabezado «X-WEBAUTH-USER» de cualquier dirección IP de origen, lo que permite efectivamente que un cliente de Internet no autenticado obtenga acceso elevado.

En una declaración compartida con The Hacker News por correo electrónico, el investigador de seguridad Ali Mustafa (@rz1027), a quien se le atribuye descubrir y reportar La falla, dijo que las imágenes de Gitea Docker incluían una plantilla «app.ini» que codifica «REVERSE_PROXY_TRUSTED_PROXIES = *» de forma predeterminada. El «aplicación.ini«El archivo es un archivo de configuración principal para administrar los parámetros del servidor, las conexiones de bases de datos, el comportamiento de seguridad y la configuración de la aplicación.

«Con el inicio de sesión de proxy inverso habilitado, ese comodín confía en cada IP de origen, por lo que cualquiera que pueda alcanzar el puerto podría enviar un encabezado X-WEBAUTH-USER y autenticarse como cualquier usuario, sin contraseña ni token», explicó Mustafa. «Con el registro automático activado, un nombre de usuario de administrador le otorga administrador».

Vale la pena señalar que el valor seguro documentado para la variable interna «REVERSE_PROXY_TRUSTED_PROXIES» es «127.0.0.0/8,::1/128», lo que significa que solo localhost, también conocido como la interfaz loopback, está permitido como servidor proxy confiable. Sin embargo, la imagen oficial de Docker no utiliza este código «*» predeterminado. En otras palabras, la verificación de la lista de permitidos es tan buena como no tenerla.

Ciberseguridad

Por lo tanto, cuando un administrador configura «ENABLE_REVERSE_PROXY_AUTHENTICATION = true» para poner a Gitea detrás de un proxy inverso de autenticación y deja la configuración «REVERSE_PROXY_TRUSTED_PROXIES» en su valor predeterminado, permite un encabezado HTTP personalizado X-WEBAUTH-USER desde cualquier IP de origen que pueda llegar al contenedor.

«Cualquier proceso que pueda llegar directamente al puerto HTTP del contenedor de Gitea, no a través del proxy de autenticación previsto, puede hacerse pasar por cualquier usuario cuyo nombre de inicio de sesión sea conocido o adivinable», según el aviso de Gitea. «Las cuentas de administrador (admin, gitea_admin, etc.) son los objetivos obvios».

La vulnerabilidad afecta a las versiones de imágenes de Gitea Docker anteriores a la 1.26.2 incluida. Ha sido abordado en versión 1.26.3 lanzado a fines del mes pasado, con el comodín «*» ahora eliminado y la autenticación de proxy inverso habilitada.

Desde entonces, la empresa de seguridad en la nube Sysdig ha revelado que detectó el primer intento de explotación en estado salvaje 13 días después de la divulgación pública de la vulnerabilidad. Hay alrededor de 6200 instancias de Gitea con acceso a Internet.

«Hasta ahora, las actividades han estado relacionadas con la investigación inicial del actor de amenazas», dijo a The Hacker News Michael Clark, director senior de investigación de amenazas de Sysdig.

«Mientras vimos la primera acción desde una IP del servicio ProtonVPN, 159.26.98[.]241 hasta ahora no ha progresado a ningún progreso de explotación o ataque. Creemos que esto se debe a que lo hemos visto temprano antes de que tuviera la oportunidad de desarrollarse más allá de esa fase inicial».

Dada la gravedad del problema, es esencial que los usuarios apliquen las correcciones lo antes posible para una protección óptima.

Imágenes maliciosas de KICS Docker y extensiones de código VS afectan la cadena de suministro de Checkmarx – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han advertido sobre imágenes maliciosas enviadas al funcionario «checkmarx/kicks» Repositorio de Docker Hub.

En una alerta publicada hoy, la empresa de seguridad de la cadena de suministro de software Socket reveló que actores de amenazas desconocidos lograron sobrescribir etiquetas existentes, incluidas v2.1.20 y alpine, al tiempo que introdujeron una nueva etiqueta v2.1.21 que no corresponde a una versión oficial. El repositorio de Docker se ha archivado al momento de escribir este artículo.

«El análisis de la imagen envenenada indica que el binario KICS incluido fue modificado para incluir capacidades de recopilación y exfiltración de datos que no están presentes en la versión legítima», dijo Socket.

«El malware podría generar un informe de escaneo sin censura, cifrarlo y enviarlo a un punto final externo, creando un riesgo grave para los equipos que usan KICS para escanear archivos de infraestructura como código que pueden contener credenciales u otros datos de configuración confidenciales».

Ciberseguridad

Un análisis más detallado del incidente ha descubierto que las herramientas de desarrollo relacionadas con Checkmarx también pueden haberse visto afectadas, como las recientes versiones de extensiones de Microsoft Visual Studio Code que vienen con código malicioso para descargar y ejecutar un complemento remoto a través del tiempo de ejecución de Bun.

«El comportamiento apareció en las versiones 1.17.0 y 1.19.0, se eliminó en la 1.18.0 y dependía de una URL de GitHub codificada para recuperar y ejecutar JavaScript adicional sin confirmación del usuario ni verificación de integridad», agregó Socket.

Las organizaciones que puedan haber utilizado la imagen KICS afectada para escanear configuraciones de Terraform, CloudFormation o Kubernetes deben tratar cualquier secreto o credencial expuesta a esos escaneos como probablemente comprometidos.

«La evidencia sugiere que este no es un incidente aislado de Docker Hub, sino parte de un compromiso más amplio de la cadena de suministro que afecta a múltiples canales de distribución de Checkmarx», señaló la compañía.

Hacker News se ha puesto en contacto con Checkmarx para obtener más información y actualizaremos la historia si recibimos una respuesta.

(Esta es una historia en desarrollo. Vuelva a consultarla para obtener más detalles).

Docker CVE-2026-34040 permite a los atacantes eludir la autorización y obtener acceso al host – CYBERDEFENSA.MX

Se ha revelado una vulnerabilidad de seguridad de alta gravedad en Docker Engine que podría permitir a un atacante eludir los complementos de autorización (AuthZ) en circunstancias específicas.

La vulnerabilidad, rastreada como CVE-2026-34040 (Puntuación CVSS: 8,8), surge de una solución incompleta para CVE-2024-41110, una vulnerabilidad de gravedad máxima en el mismo componente que salió a la luz en julio de 2024.

«Utilizando una solicitud API especialmente diseñada, un atacante podría hacer que el demonio Docker reenvíe la solicitud a un complemento de autorización sin el cuerpo», mantenedores de Docker Engine. dicho en un aviso publicado a finales del mes pasado. «El complemento de autorización puede permitir una solicitud que de otro modo habría rechazado si se le hubiera enviado el cuerpo».

«Cualquiera que dependa de complementos de autorización que introspeccionen el cuerpo de la solicitud para tomar decisiones de control de acceso se verá potencialmente afectado».

A múltiples vulnerabilidades de seguridad, incluidas Asim Viladi Oglu Manizada, Cody, Oleh Konko y Vladimir Tokarev, se les atribuye el mérito de descubrir e informar el error de forma independiente. El problema se solucionó en la versión 29.3.1 de Docker Engine.

Ciberseguridad

Según un informe publicado por el investigador Tokarev de Cyera Research Labs, la vulnerabilidad se debe al hecho de que la solución para CVE-2024-41110 no manejó adecuadamente los cuerpos de solicitud HTTP de gran tamaño, abriendo así la puerta a un escenario en el que se puede utilizar una única solicitud HTTP rellenada para crear un contenedor privilegiado con acceso al sistema de archivos host.

En un escenario de ataque hipotético, un atacante que tiene el acceso a la API de Docker restringido por un complemento AuthZ puede socavar el mecanismo al rellenar una solicitud de creación de contenedor a más de 1 MB, lo que provoca que se elimine antes de llegar al complemento.

«El complemento permite la solicitud porque no ve nada que bloquear», Tokarev dicho en un informe compartido con The Hacker News. «El demonio Docker procesa la solicitud completa y crea un contenedor privilegiado con acceso raíz al host: sus credenciales de AWS, claves SSH, configuraciones de Kubernetes y todo lo demás en la máquina. Esto funciona con todos los complementos de AuthZ en el ecosistema».

Es más, un agente codificador de inteligencia artificial (IA) como OpenClaw ejecutándose dentro de una zona de pruebas basada en Docker se puede engañar para que ejecute una inyección rápida oculta dentro de un repositorio GitHub específicamente diseñado como parte de un flujo de trabajo normal del desarrollador, lo que resulta en la ejecución de código malicioso que explota CVE-2026-34040 para eludir la autorización utilizando el enfoque anterior y crear un contenedor privilegiado y montar el sistema de archivos host.

Con este nivel de acceso, el atacante puede extraer credenciales para servicios en la nube y abusar de ellas para tomar el control de cuentas en la nube, clústeres de Kubernetes e incluso SSH en servidores de producción.

No termina ahí. Cyera también advirtió que los agentes de IA pueden descubrir el bypass por su cuenta y activarlo mediante la construcción de una solicitud HTTP rellenada al encontrar errores al intentar acceder a archivos como kubeconfig como parte de una tarea de depuración legítima emitida por un desarrollador (por ejemplo, depurar el problema de falta de memoria del K8). Este enfoque elimina la necesidad de instalar un repositorio envenenado que contenga instrucciones maliciosas.

Ciberseguridad

«El complemento AuthZ negó la solicitud de montaje», explicó Cyera. «El agente tiene acceso a la API de Docker y sabe cómo funciona HTTP. CVE-2026-34040 no requiere ningún código de explotación, privilegios o herramientas especiales. Es una única solicitud HTTP con relleno adicional. Cualquier agente que pueda leer la documentación de la API de Docker puede construirla».

Como solución temporal, se recomienda evitar el uso de complementos de AuthZ que dependen de la inspección del cuerpo de solicitud para tomar decisiones de seguridad, limitar el acceso a la API de Docker a partes confiables siguiendo el principio de privilegio mínimo o ejecutar Docker en modo desarraigado.

«En el modo sin raíz, incluso la ‘raíz’ de un contenedor privilegiado se asigna a un UID de host sin privilegios», dijo Tokarev. «El radio de explosión cae de ‘compromiso total del host’ a ‘usuario comprometido sin privilegios’. Para entornos que no pueden desraizarse por completo, –userns-remap proporciona un mapeo de UID similar».

Trivy Hack difunde Infostealer a través de Docker, Triggers Worm y Kubernetes Wiper – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han descubierto artefactos maliciosos distribuidos a través de Docker Hub luego del ataque a la cadena de suministro de Trivy, destacando el creciente radio de explosión en los entornos de desarrolladores.

La última liberación limpia conocida de trivia en Docker Hub es 0.69.3. Desde entonces, las versiones maliciosas 0.69.4, 0.69.5 y 0.69.6 se eliminaron de la biblioteca de imágenes del contenedor.

«Las nuevas etiquetas de imagen 0.69.5 y 0.69.6 se publicaron el 22 de marzo sin las correspondientes versiones o etiquetas de GitHub. Ambas imágenes contienen indicadores de compromiso asociados con el mismo ladrón de información de TeamPCP observado en etapas anteriores de esta campaña», dijo el investigador de seguridad de Socket, Philipp Burckhardt. dicho.

El desarrollo se produce a raíz de un compromiso de la cadena de suministro de Trivy, un popular escáner de vulnerabilidades de código abierto mantenido por Aqua Security, que permite a los actores de amenazas aprovechar una credencial comprometida para impulsar a un ladrón de credenciales dentro de versiones troyanizadas de la herramienta y dos acciones de GitHub relacionadas «aquasecurity/trivy-action» y «aquasecurity/setup-trivy».

Ciberseguridad

El ataque ha tenido impactos posteriores, ya que los atacantes aprovecharon los datos robados para comprometer docenas de paquetes npm y distribuir un gusano autopropagante conocido como CanisterWorm. Se cree que el incidente es obra de un actor de amenazas rastreado como TeamPCP.

Según el equipo de OpenSourceMalware, los atacantes han desfigurado los 44 repositorios internos asociados con Aqua Security.aquasec-com» organización GitHub cambiando el nombre de cada uno de ellos con el prefijo «tpcp-docs-«, estableciendo todas las descripciones en «TeamPCP posee Aqua Security» y exponiéndolas públicamente.

Se dice que todos los repositorios se modificaron en una ráfaga programada de 2 minutos entre las 20:31:07 UTC y las 20:32:26 UTC del 22 de marzo de 2026. Se ha evaluado con alta confianza que el actor de amenazas aprovechó una cuenta de servicio «Argon-DevOps-Mgt» comprometida para este propósito.

«Nuestro análisis forense de la API de GitHub Events apunta a un token de cuenta de servicio comprometido, probablemente robado durante el compromiso anterior de Trivy GitHub Actions de TeamPCP, como vector de ataque», dijo el investigador de seguridad Paul McCarty. dicho. «Esta es una cuenta de servicio/bot (ID de GitHub 139343333, creada el 12 de julio de 2023) con una propiedad crítica: une ambas organizaciones de GitHub».

«Un token comprometido para esta cuenta le da al atacante acceso de escritura/administración a ambas organizaciones», agregó McCarty.

El desarrollo es la última escalada de un actor de amenazas que se ha ganado una reputación por apuntar a infraestructuras de nube, mientras construye progresivamente capacidades para exponer sistemáticamente las API de Docker, los clústeres de Kubernetes, los paneles de Ray y los servidores Redis para robar datos, implementar ransomware, realizar extorsión y extraer criptomonedas.

Su creciente sofisticación se ejemplifica mejor con la aparición de un nuevo malware de limpieza que se propaga a través de SSH a través de claves robadas y explota las API de Docker expuestas en el puerto 2375 en toda la subred local.

Se ha descubierto que una nueva carga útil atribuida a TeamPCP va más allá del robo de credenciales y borra clústeres completos de Kubernetes (K8) ubicados en Irán. El script de shell utiliza el mismo recipiente ICP vinculado a CanisterWorm y luego ejecuta comprobaciones para identificar los sistemas iraníes.

Ciberseguridad

«En Kubernetes: implementa DaemonSets privilegiados en cada nodo, incluido el plano de control», investigador de seguridad de Aikido, Charlie Eriksen. dicho. «Los nodos iraníes se borran y se reinician a la fuerza a través de un contenedor llamado ‘kamikaze’. Los nodos no iraníes instalan la puerta trasera CanisterWorm como un servicio systemd. Los hosts iraníes que no son K8 obtienen ‘rm -rf / –no-preserve-root’».

Dada la naturaleza continua del ataque, es imperativo que las organizaciones revisen su uso de Trivy en las canalizaciones de CI/CD, eviten el uso de versiones afectadas y traten cualquier ejecución reciente como potencialmente comprometida.

«Este compromiso demuestra la larga cola de ataques a la cadena de suministro», dijo OpenSourceMalware. «Una credencial obtenida durante el compromiso de Trivy GitHub Actions hace meses fue utilizada como arma hoy para desfigurar toda una organización interna de GitHub. La cuenta de servicio Argon-DevOps-Mgt, una única cuenta de bot que une dos organizaciones con un PAT de larga duración, era el eslabón débil».

«Desde la explotación de la nube hasta los gusanos de la cadena de suministro y los limpiadores de Kubernetes, están creando capacidades y apuntando al propio ecosistema de proveedores de seguridad. La ironía de que una empresa de seguridad en la nube se vea comprometida por un actor de amenazas nativo de la nube no debe pasar desapercibida para la industria.