Gitea CVE-2026-20896: el header que te convierte en admin

Si corrés Gitea desde la imagen oficial de Docker y alguna vez activaste la autenticación por reverse proxy, hay una chance concreta de que cualquiera con acceso de red a tu contenedor pudiera loguearse como gitea_admin sin contraseña. Eso es CVE-2026-20896: un auth bypass con CVSS 9.8 que no vive en el código de Gitea sino en un valor por defecto que la imagen de Docker traía mal configurado. Ya hay sondeo activo en internet, así que conviene entender qué pasó y revisar tu instancia hoy.

CVE-2026-20896 es una vulnerabilidad de bypass de autenticación (CVSS 9.8, crítica) en las imágenes Docker oficiales de Gitea 1.26.2 y anteriores. La imagen embarcaba REVERSE_PROXY_TRUSTED_PROXIES = * en su plantilla app.ini, en vez del valor seguro documentado. Con la autenticación por reverse proxy activa, ese comodín hace que Gitea confíe en el header X-WEBAUTH-USER desde cualquier IP de origen, permitiendo suplantar a cualquier usuario. Se corrigió en las versiones 1.26.3 y 1.26.4.

¿Cómo un solo header HTTP da acceso de administrador?

El mecanismo es la autenticación por reverse proxy: cuando la activás, Gitea delega el login en un proxy que autentica al usuario y le pasa el nombre en el header X-WEBAUTH-USER. Gitea confía en ese header y crea la sesión sin pedir contraseña. La premisa de seguridad es que solo el proxy pueda setear ese header; todo el resto del esquema depende de esa confianza.

El problema aparece cuando esa confianza no está acotada. Gitea usa la variable REVERSE_PROXY_TRUSTED_PROXIES para decidir a qué IPs de origen les cree el header. El default documentado y sano es 127.0.0.0/8,::1/128 — solo loopback, es decir solo el proxy corriendo al lado. Pero la imagen Docker oficial hardcodeaba *: confiar en todas las IPs. Con eso, cualquier proceso que alcance el puerto HTTP del contenedor directamente (sin pasar por el proxy que se suponía debía autenticar) puede mandar su propio X-WEBAUTH-USER y quedar logueado como quien quiera.

Como lo resumió Ali Mustafa (@rz1027), el investigador que reportó la falla: "Con el login por reverse-proxy habilitado, ese comodín confía en toda IP de origen, así que cualquiera que pudiera alcanzar el puerto podía enviar un header X-WEBAUTH-USER y quedar autenticado como cualquier usuario, sin contraseña y sin token."

¿Qué versiones de Gitea están afectadas y cuál es el fix?

Están afectadas las imágenes Docker de Gitea 1.26.2 y anteriores; el fix llegó en la 1.26.3 y se recomienda ir directo a la 1.26.4, que resuelve además una regresión introducida en la 1.26.3. En las versiones parcheadas se quitó el comodín * y la autenticación por reverse proxy pasó a ser opt-in con un default seguro.

Un detalle importante para dimensionar el riesgo: la falla solo es explotable si un admin puso ENABLE_REVERSE_PROXY_AUTHENTICATION = true. Si nunca tocaste esa opción, tu instancia no acepta el header y no estás expuesto por esta vía. Pero si la activaste confiando en el default de la imagen, estabas en riesgo aunque no te hubieras dado cuenta.

¿Cómo sé si mi instancia de Gitea está expuesta?

Revisá dos cosas: la versión de la imagen y el valor efectivo de REVERSE_PROXY_TRUSTED_PROXIES combinado con si la autenticación por proxy está activa. La forma más directa es inspeccionar la config y probar el comportamiento del header desde una IP que no sea la del proxy.

• Verificá la versión que corrés. Si tu imagen es 1.26.2 o anterior y usás autenticación por reverse proxy, asumí que estás afectado hasta demostrar lo contrario.
• Mirá el app.ini real del contenedor. Buscá la sección [security] y revisá ENABLE_REVERSE_PROXY_AUTHENTICATION y REVERSE_PROXY_TRUSTED_PROXIES. Un * ahí, con la auth por proxy activa, es la combinación peligrosa.
• Probá el header desde afuera del proxy. Si una request directa al puerto de Gitea con un X-WEBAUTH-USER arbitrario devuelve una sesión válida, estás expuesto.

Un chequeo manual rápido, apuntando directo al contenedor y no al proxy:

# Reemplazá host:puerto por el endpoint directo de tu contenedor Gitea
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "X-WEBAUTH-USER: gitea_admin" \
  http://TU-HOST:3000/api/v1/user

Si esa llamada te responde como si fueras gitea_admin en lugar de rechazarte, el header se está aceptando desde una IP que no debería ser confiable. Existe además un checker público (cve-2026-20896-gitea-poc) que automatiza esta verificación; usalo solo contra infraestructura propia.

¿Cómo mitigo CVE-2026-20896 ahora mismo?

La solución de fondo es actualizar la imagen a 1.26.4 o superior. Si no podés desplegar ya, el mitigante inmediato es reemplazar el comodín por el rango de loopback en tu app.ini o vía variable de entorno, para que Gitea solo confíe en el proxy local.

• Actualizá la imagen. Pasá a gitea/gitea:1.26.4 o la última estable disponible; es el fix oficial.
• Acotá las IPs confiables. Poné REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.0/8,::1/128 (o la IP concreta de tu proxy), nunca *.
• Desactivá lo que no uses. Si no dependés de auth por reverse proxy, dejá ENABLE_REVERSE_PROXY_AUTHENTICATION = false y cerrás la superficie de ataque por completo.
• No expongas el puerto interno. El puerto HTTP del contenedor no debería ser alcanzable desde internet; solo el reverse proxy tendría que llegar a él.

En el app.ini el bloque correcto queda así:

[security]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.0/8,::1/128

Después de tocar la config, reiniciá el contenedor y volvé a correr el chequeo del header desde una IP externa: ahora la request directa tiene que ser rechazada.

¿Por qué este bug importa más allá de Gitea?

Porque es un recordatorio de que el eslabón débil no siempre está en el código de la aplicación sino en cómo se empaqueta y distribuye. Acá el software estaba bien; lo que fallaba era el default de la imagen Docker, un archivo de configuración que la mayoría de la gente nunca revisa porque asume que "el oficial viene seguro".

La explotación en la vida real ya arrancó. Según reportó The Hacker News citando a Sysdig, el primer intento in-the-wild se detectó 13 días después de la publicación del aviso, desde un nodo de salida de VPN; Michael Clark, senior director de Sysdig, aclaró que ese primer movimiento todavía no había derivado en un ataque concreto. Los reportes hablan de alrededor de 6.200 instancias de Gitea expuestas a internet, no todas necesariamente vulnerables, pero sí una superficie amplia para escanear. La lección práctica es simple: cuando adoptás una imagen de contenedor, auditá sus defaults de seguridad como si fueran tu propia config, porque en producción lo son.

Si te interesa el patrón, esta no es la primera vez que Gitea aparece con un problema de exposición: ya cubrimos "Gitea CVE-2026-27771: tus imágenes privadas nunca lo fueron", otro caso donde el comportamiento por defecto no coincidía con la expectativa de privacidad.

Preguntas frecuentes

¿Estoy afectado si nunca activé la autenticación por reverse proxy?

No. CVE-2026-20896 solo es explotable con ENABLE_REVERSE_PROXY_AUTHENTICATION = true. Si dejaste esa opción en su valor por defecto (desactivada), Gitea ignora el header X-WEBAUTH-USER y esta vía de ataque no aplica a tu instancia.

¿Alcanza con actualizar o también tengo que cambiar la config?

Actualizar a 1.26.4 o superior resuelve el default inseguro de la imagen. Aun así, es buena práctica dejar REVERSE_PROXY_TRUSTED_PROXIES con el rango de loopback o la IP de tu proxy de forma explícita, para no depender de que el default vuelva a cambiar en una imagen futura.

¿Qué versión de Gitea tengo que instalar?

Instalá 1.26.4 o la última estable. La 1.26.3 ya trae el fix del bypass pero introdujo una regresión que la 1.26.4 corrige, así que conviene saltar directo a esa.

¿Este problema estaba en el código de Gitea o en Docker?

En la imagen Docker. El core de Gitea usa por defecto el valor seguro 127.0.0.0/8,::1/128; era la plantilla app.ini de la imagen oficial la que hardcodeaba *. Por eso instalaciones no dockerizadas con el default de upstream no estaban expuestas por esta configuración.

¿Ya se está explotando en la práctica?

Sí, hay sondeo activo. Según los reportes, la primera actividad in-the-wild se observó 13 días después de la divulgación pública. Aunque el primer intento detectado no llegó a comprometer instancias, la falla es trivial de disparar, así que la ventana para parchear es corta.

Fuentes

• The Hacker News — Threat Actors Probe Gitea Docker Flaw CVE-2026-20896
• BleepingComputer — Hackers exploit critical auth bypass in Gitea Docker image
• GitLab Advisory Database — CVE-2026-20896
• Security Affairs — Critical Gitea Docker Bug Under Active Exploitation

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting