Falla 9.8 en Gitea Docker se convierte en objetivo activo: un único encabezado da acceso admin a repositorios

Sysdig confirmó, en un informe republicado esta semana por The Hacker News, que la CVE-2026-20896 en Gitea Docker dejó de ser una hipótesis y pasó a ser un objetivo activo en Internet. El primer intento de explotación en producción ocurrió 13 días después de la publicación de la falla, saliendo de un nodo de salida de ProtonVPN en 159.26.98.241, con un patrón de escaneo típico de campaña amplia: escaneo de servicios expuestos, intento de bypass, recolección de respuesta.

El defecto es grosero por lo que permite. La puntuación CVSS alcanza 9.8 porque la imagen Docker oficial se subía con una plantilla app.ini que fijaba REVERSE_PROXY_TRUSTED_PROXIES = *. Combinado con la configuración de autenticación por encabezado, el servidor pasaba a aceptar el encabezado X-WEBAUTH-USER proveniente de cualquier IP y a tratarlo como identidad confirmada. En otras palabras, un cliente no autenticado de la Internet abierta puede presentarse como cualquier usuario de Gitea, incluido el administrador, sin tocar una contraseña, clave SSH o token.

Lo que está expuesto

Sysdig contabiliza alrededor de 6,200 instancias Gitea expuestas a Internet en el momento en que la explotación comenzó a aparecer. No toda esta base corre la imagen Docker vulnerable, pero el subconjunto afectado incluye exactamente el perfil que más interesa a operadores criminales: equipos de desarrollo internos de medianas empresas, servidores de código de startups, laboratorios corporativos que prefirieron autoalojarse en lugar de usar GitHub o GitLab, y proveedores gestionados que empaquetaron Gitea en contenedores para reventa.

El contenido de estos repositorios suele valer más que el código mismo. Claves privadas de CI/CD, tokens de nube, credenciales de base de datos en archivos de configuración, definiciones de infraestructura como código con endpoints internos, notebooks de datos e historial de commits con secretos revertidos y nunca purgados, aparecen en la mayoría de los entornos autoalojados que no fueron sometidos a auditoría formal. Un acceso admin a Gitea da visión de todos los repos privados de la organización sin generar un registro de autenticación normal, porque el servidor genuinamente cree que la solicitud es legítima.

Cómo llegó al estado actual

La vulnerabilidad fue divulgada por los mantenedores de Gitea junto con el release 1.26.3, orientando a los administradores a actualizar de inmediato o eliminar la línea REVERSE_PROXY_TRUSTED_PROXIES = * del archivo app.ini. Según Sysdig, esta ventana de 13 días entre la publicación y el primer intento observado sigue la media que la empresa ha medido en campañas de N-day: bots públicos consumen el feed de CVEs, generan firmas de escaneo y disparan escaneos masivos, muchas veces antes de que los equipos internos hayan concluido el inventario de instancias afectadas.

El hecho de que la explotación haya partido de un nodo ProtonVPN no indica autoría específica. Es una práctica común en campañas de reconocimiento oportunista, y Sysdig registró que, hasta el momento del informe, no había relatos confirmados de post-explotación exitosa o filtraciones directamente atribuidas a la falla. Esto no es un consuelo: el intervalo entre escaneo y uso suele medirse en horas cuando el exploit funciona como en este caso, sin necesidad de un payload sofisticado.

Qué hacer ahora

Para operadores de Gitea Docker, el playbook es corto y urgente. Actualizar a 1.26.3, eliminar o restringir REVERSE_PROXY_TRUSTED_PROXIES a las rangos realmente confiables, revisar logs de acceso de las dos últimas semanas en busca de requests con X-WEBAUTH-USER inesperado y forzar rotación de cualquier credencial que aparezca en texto claro dentro de repos privados. Equipos que exponen el Gitea a través de ingreso público sin WAF al frente deben tratar la instancia como comprometida hasta prueba en contrario, especialmente si la versión está atrás de la 1.26.3 desde hace más de algunos días.

El caso muestra un patrón que se repite en productos DevOps: una configuración predeterminada pensada para facilitar el despliegue interno se convierte en una puerta abierta cuando la misma imagen se sube a producción con exposición pública. El REVERSE_PROXY_TRUSTED_PROXIES = * tiene sentido en un entorno donde solo un reverse proxy conocido habla con el contenedor. Dejar este valor como predeterminado de una imagen oficial, distribuida para escenarios que nadie puede prever, es el tipo de elección de ingeniería que suele acabar en una CVE crítica. La respuesta rápida del equipo de Gitea corrige el defecto, pero la lección, para quienes gestionan flotas de contenedores, es que la revisión de seguridad debe entrar antes del pull, no después de la primera alerta.