Gitea bajo ataque: falla en imagen Docker permite convertirse en admin con un único header HTTP
Sysdig detectó el primer intento de explotación 13 días después del parche, contra 6.200 instancias expuestas. El bug proviene de una línea del app.ini que confía en cualquier IP.
La empresa de seguridad en la nube Sysdig anunció este martes que detectó el primer intento de explotación real del CVE-2026-20896, una falla de bypass de autenticación con CVSS 9.8 en las imágenes Docker de Gitea. El intento salió de una dirección de ProtonVPN (159.26.98.241) y ocurrió 13 días después de que el proyecto publicara la versión 1.26.3, que corrigió el problema el 20 de junio. Existen alrededor de 6.200 instancias de Gitea expuestas a Internet, un número que combina servidores autohospedados de equipos de ingeniería e implementaciones internas de empresas que prefieren código fuente fuera de GitHub por razones de cumplimiento.
La causa raíz se resume en dos líneas del archivo app.ini que la imagen Docker de Gitea distribuía por defecto. La configuración REVERSE_PROXY_TRUSTED_PROXIES venía marcada con el carácter comodín asterisco, lo que hace que el servicio confíe en el header HTTP X-WEBAUTH-USER proveniente de cualquier dirección IP. Un cliente sin credenciales, capaz de alcanzar el puerto público del contenedor, envía este header con un nombre de usuario administrativo y recibe sesión de admin. Ali Mustafa, investigador que firma como rz1027, descubrió y reportó la falla; la corrección eliminó el comodín de la configuración predeterminada y transformó la autenticación por proxy inverso en una opción explícita.
Lo que vio Sysdig
Michael Clark, director senior de investigación de amenazas de Sysdig, dijo en una nota que la actividad observada hasta ahora se encuentra en la etapa de investigación inicial por parte del atacante y no ha avanzado hacia movimiento lateral o instalación de payload. "Creemos que lo identificamos temprano, antes de que tuviera la oportunidad de evolucionar más allá de esta fase", declaró Clark. El punto es relevante porque Gitea, a diferencia de los gestores de código administrados, suele estar ubicado dentro de segmentos de red con secretos, claves SSH y pipelines de CI que pueden comunicarse con la producción.
La ventana de silencio entre el parche del 20 de junio y la primera explotación el 3 de julio es típica del patrón que Sysdig y otros investigadores han comenzado a mapear en 2026: los atacantes esperan a que baje la polvareda, extraen detalles del commit que corrigió el bug y lanzan búsquedas a gran escala tan pronto como la mayoría de los operadores presume que la ola ha pasado. Cyberdaily estimó que menos de la mitad de los contenedores de Gitea expuestos fueron actualizados a 1.26.3 hasta el inicio de esta semana.
Dónde golpea el problema: Estados Unidos, Alemania y China
La base instalada de Gitea se concentra en tres geografías distintas. En Estados Unidos, equipos de DevOps de startups y áreas de plataforma que huyeron de GitHub por cuestiones de costo o latencia suelen ejecutar Gitea en la nube privada. En Alemania y el resto de la Unión Europea, Gitea se ha convertido en la opción preferida para empresas que necesitan mantener código fuente dentro de fronteras geográficas bajo GDPR, incluyendo divisiones de ingeniería de fabricantes automotrices e integradores públicos. En China, donde las restricciones de acceso a GitHub y las políticas de datos locales han empujado a la comunidad hacia forks abiertos, Gitea ha ganado tracción en bancos regionales, universidades y entidades estatales; el Gitee, fork chino del proyecto, hereda la misma base de código y puede compartir el problema en versiones desactualizadas.
En EE. UU., el riesgo inmediato es el robo de secretos y secuestro de pipelines de CI, lo que suele convertirse en acceso a producción en pocas horas. En Europa, la materialización del riesgo tiende a ser la detección por parte de la autoridad de protección de datos: un intruso ingresando como admin en un Git corporativo es un evento que dispara notificación obligatoria bajo GDPR en 72 horas. En Asia, donde muchas instalaciones aún ejecutan versiones anteriores a 1.24 sin procesos regulares de parcheo, el vector puede permanecer abierto durante semanas antes de cualquier investigación.
Qué hacer ahora
Los administradores deben, primero, confirmar la versión en ejecución. A partir de 1.26.3, el comportamiento por defecto cambió: REVERSE_PROXY_TRUSTED_PROXIES dejó de venir con asterisco y se convirtió en una lista explícita. Quienes operaron Gitea detrás de un proxy inverso legítimo deben volver a agregar manualmente las IPs de confianza. Quien descubra que el servicio nunca necesitó autenticación por proxy inverso puede simplemente desactivar la función.
Sysdig también recomienda revisar los logs en busca de solicitudes con el header X-WEBAUTH-USER provenientes de fuera de la red interna y verificar qué claves de despliegue y tokens de CI han sido accedidos en los últimos 20 días. En entornos donde Gitea almacena secretos de pipeline, la rotación preventiva de credenciales cuesta menos que el análisis de un incidente confirmado. La 1.26.3 ya está disponible desde hace más de dos semanas. La decisión que queda es si el próximo informe será sobre parche aplicado o sobre respuesta a incidente.