En las imágenes Docker de la plataforma Gitea se ha descubierto la vulnerabilidad crítica CVE-2026-20896 con una puntuación CVSS 9.8, que permite a un atacante no autenticado acceder a cualquier cuenta, incluida la administrativa, sin contraseña ni token. La vulnerabilidad afecta a todas las versiones de las imágenes Docker de Gitea hasta la 1.26.2 inclusive y se ha corregido en la versión 1.26.3. Según datos de la empresa Sysdig, 13 días después de la divulgación pública ya se ha registrado actividad relacionada con el reconocimiento de instancias vulnerables, aunque por ahora no hay casos confirmados de explotación exitosa. Los administradores de Gitea que utilicen un despliegue en Docker con reverse proxy deben actualizar de inmediato.
Aspectos técnicos de la vulnerabilidad
El origen del problema está en el archivo de configuración app.ini, que es el archivo central de configuración de Gitea y controla los parámetros del servidor, las conexiones a la base de datos y el comportamiento de seguridad. En las imágenes Docker de Gitea, esta plantilla fijaba de forma rígida el parámetro REVERSE_PROXY_TRUSTED_PROXIES = *, lo que implicaba confiar en la cabecera HTTP X-WEBAUTH-USER procedente de cualquier dirección IP de origen.
El valor documentado como seguro para este parámetro es 127.0.0.0/8,::1/128, es decir, confiar solo en localhost. Sin embargo, la imagen Docker ignoraba este valor predeterminado y lo sustituía por el comodín *. En la práctica, la comprobación de la lista de proxies de confianza quedaba sin sentido.
El mecanismo de explotación funciona del siguiente modo:
- El administrador habilita el parámetro
ENABLE_REVERSE_PROXY_AUTHENTICATION = truepara situar Gitea detrás de un reverse proxy autenticador - El parámetro
REVERSE_PROXY_TRUSTED_PROXIESpermanece con el valor predeterminado (*) - Cualquier proceso capaz de acceder directamente al puerto HTTP del contenedor de Gitea —eludiendo el reverse proxy autenticador previsto— puede enviar una cabecera arbitraria
X-WEBAUTH-USER - El servidor acepta el valor de la cabecera como nombre de usuario autenticado sin comprobaciones adicionales
Tal como se indica en el boletín oficial de seguridad de Gitea, los objetivos evidentes son las cuentas administrativas con nombres previsibles: admin, gitea_admin y similares. Con el registro automático de usuarios habilitado, un atacante puede crear una cuenta con un nombre de administrador y obtener privilegios completos.
La vulnerabilidad fue descubierta y divulgada por el investigador de seguridad Ali Mustafa. El repositorio público del investigador contiene los detalles de la divulgación, lo que indica que existe información técnica disponible para reproducir el ataque.
Versiones afectadas y corrección
- Versiones vulnerables: imágenes Docker de Gitea hasta la versión 1.26.2 inclusive
- Versión corregida: 1.26.3 (se ha eliminado el comodín
*y la autenticación mediante reverse proxy ha pasado a un modo de activación explícita)
Es importante subrayar que la vulnerabilidad es específica de las imágenes Docker de Gitea. La instalación estándar a partir de binarios utiliza un valor predeterminado seguro. El problema surgió por una discrepancia entre el comportamiento documentado y la configuración real suministrada en la imagen de contenedor.
Actividad observada
Según datos de Sysdig, la primera actividad relacionada con esta vulnerabilidad se registró 13 días después de la divulgación pública. No obstante, debe tenerse en cuenta que esta información procede de una única fuente y tiene carácter de telemetría operativa.
Michael Clark, director sénior de investigación de amenazas en Sysdig, describió la actividad observada como reconocimiento inicial, que aún no ha pasado a la fase de explotación. Se registró la dirección IP 159.26.98[.]241, perteneciente al servicio ProtonVPN. El uso de un servicio VPN impide extraer conclusiones de atribución: podría tratarse tanto de reconocimiento dirigido como de escaneo automatizado.
El estado de la explotación debe clasificarse como escaneo, y no como explotación confirmada en entornos reales. Según estimaciones, hay disponibles en internet alrededor de 6 200 instancias de Gitea, aunque esta cifra no ha sido confirmada por mediciones independientes.
Evaluación del impacto
La criticidad de la vulnerabilidad viene determinada por varios factores. Gitea es ampliamente utilizado por equipos de desarrollo como alternativa autoalojada a GitHub y GitLab. La compromisión del acceso administrativo a Gitea abre la puerta a modificar código fuente, introducir commits maliciosos en la cadena de suministro de software, robar secretos y tokens de los repositorios, así como a moverse lateralmente dentro de la infraestructura de la organización.
El bajo umbral de entrada para la explotación —basta con enviar una única cabecera HTTP—, combinado con la puntuación CVSS 9.8 y la existencia de detalles técnicos públicos, convierte esta vulnerabilidad en prioritaria para su inmediata corrección.
Recomendaciones
- Actualización inmediata: actualice la imagen Docker de Gitea a la versión 1.26.3 o superior
- Verificación de la configuración: asegúrese de que en el archivo
app.iniel parámetroREVERSE_PROXY_TRUSTED_PROXIESestá establecido en127.0.0.0/8,::1/128y no en* - Auditoría del acceso de red: verifique que el puerto HTTP del contenedor de Gitea no sea accesible directamente desde internet y que solo acepte conexiones desde el reverse proxy de confianza
- Revisión de registros: analice los logs en busca de solicitudes con la cabecera
X-WEBAUTH-USERprocedentes de direcciones IP que no pertenezcan a su reverse proxy - Auditoría de cuentas: compruebe la existencia de cuentas sospechosas, especialmente con privilegios administrativos, creadas durante el periodo en que el sistema estuvo vulnerable
Las organizaciones que utilicen un despliegue de Gitea en Docker con autenticación a través de reverse proxy deben actualizar la imagen a la versión 1.26.3 y comprobar el valor de REVERSE_PROXY_TRUSTED_PROXIES en la configuración. Dado que existen detalles técnicos públicos, la puntuación CVSS es 9.8 y ya se ha observado escaneo, la ventana para actualizar con seguridad se está estrechando: la prioridad de mitigación debe ser máxima.