Una vulnerabilidad crítica de bypass de autenticación en la imagen Docker oficial de Gitea —el servidor Git autoalojado— está siendo explotada de forma activa en internet. Identificada como CVE-2026-20896 con un puntaje CVSS de 9.8, permite que un atacante sin credenciales se haga pasar por cualquier usuario, incluidos los administradores, y tome control de repositorios privados enteros.
El problema afecta a las instancias desplegadas con la imagen oficial hasta la versión 1.26.2 inclusive. Gitea ya publicó el parche en las versiones 1.26.3 y 1.26.4.
Una cabecera para hacerse pasar por el admin
Gitea soporta autenticación vía reverse proxy: cuando está habilitada, confía en la cabecera X-WEBAUTH-USER que le envía un proxy delante suyo para saber qué usuario está autenticado.
Para que eso sea seguro, Gitea solo debería aceptar esa cabecera desde IPs de confianza. La documentación fija ese valor por defecto en 127.0.0.0/8,::1/128 (solo loopback).
La imagen Docker oficial, en cambio, venía con el ajuste REVERSE_PROXY_TRUSTED_PROXIES=*, es decir, confiando en cualquier IP de origen. El resultado, según la explicación de Gitea, es que con la autenticación por proxy habilitada «un cliente no autenticado de internet se vuelve quien dice ser».
En la práctica, cualquier proceso que pueda alcanzar directamente el puerto HTTP del contenedor solo tiene que inyectar la cabecera X-WEBAUTH-USER con un nombre de usuario existente o adivinable —como el admin— para autenticarse como esa persona, sin contraseña ni token.
Por qué solo la imagen Docker
La falla no está en el código de Gitea sino en la configuración por defecto que trae la imagen de contenedor. Las plantillas del Docker oficial hardcodeaban el valor permisivo, apartándose del default documentado y seguro.
Por eso las instalaciones que no usan esa imagen quedan fuera del alcance. Según el aviso oficial, las distribuciones binarias y los despliegues autocompilados que parten de app.example.ini no están afectados.
El riesgo se agrava si además está activado ENABLE_REVERSE_PROXY_AUTO_REGISTRATION, porque entonces el atacante puede incluso crear cuentas nuevas. La vulnerabilidad fue reportada por el investigador rz1027.
De la publicación del aviso a la explotación activa
La ventana entre el parche y el abuso fue corta. El equipo de investigación de amenazas de Sysdig detectó el primer sondeo del fallo en la red aproximadamente 13 días después de que se publicara el aviso, rastreando el intento hasta un scanner automatizado que operaba a través de un nodo de salida de VPN.
El escenario es atractivo para los atacantes: se estima que hay alrededor de 6.200 instancias de Gitea expuestas en la web pública, muchas usadas por equipos que corren su propio Git on-premise o containerizado como repositorio privado. Un repositorio comprometido puede filtrar código fuente, secretos, tokens de CI/CD y llaves de despliegue.
Qué hacer ahora
La recomendación principal es actualizar de inmediato. Conviene ir directo a la 1.26.4, que además del fix de seguridad resuelve una regresión introducida en la 1.26.3 (un error context deadline exceeded que rompía la carga de las páginas de código de los repositorios).
Si actualizar no es posible en lo inmediato, las mitigaciones son:
- Restringir
REVERSE_PROXY_TRUSTED_PROXIESa las IPs específicas de los proxies legítimos, en lugar del comodín*. - Aislar el contenedor a nivel de red para que su puerto HTTP no sea alcanzable directamente desde internet.
- Revisar los logs de acceso en busca de actividad sospechosa: accesos administrativos inesperados o modificaciones de repositorios no autorizadas.
¿Ya revisaron sus instancias de Gitea?
El caso vuelve a mostrar que un default cómodo en una imagen de contenedor puede convertirse en la puerta de entrada a toda la infraestructura de desarrollo. Si tenés Gitea corriendo con la imagen Docker oficial, revisar la versión y el valor de REVERSE_PROXY_TRUSTED_PROXIES es una tarea de minutos.
¿Ya auditaron sus despliegues? Te leemos en los comentarios.


