Explotan un bypass de autenticación crítico en la imagen Docker oficial de Gitea

Contenedor Docker con un candado abierto dejando pasar una cabecera de autenticación falsa hacia un repositorio de código
0 0 votos
Valora la Publicación

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_PROXIES a 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.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →
Suscribirse
Notificarme de
guest

0 Comentarios
Viejos
Nuevos Más votados
Scroll al inicio
0
Nos encantaría conocer tu opinión: ¡comenta!x