Gitea CVE-2026-27771: fuga de imágenes privadas

Si corrés Gitea como tu forja Git self-hosted y usás su registry de contenedores integrado, hay una noticia que no podés dejar pasar: durante casi cuatro años, las imágenes que marcabas como "privadas" en el registry de Gitea eran, en la práctica, descargables por cualquier persona en internet, sin cuenta, sin token y sin ningún acceso previo. El fallo se cataloga como CVE-2026-27771, tiene un CVSS de 8.2 y se estima que dejó expuestas más de 30.000 instancias antes del parche. Peor todavía: miles siguen sin actualizar.

CVE-2026-27771 es una vulnerabilidad de control de acceso (auth bypass) en el registry de contenedores integrado de Gitea, la forja Git self-hosted de código abierto. El registry servía manifests y capas de imágenes marcadas como privadas ante peticiones anónimas de Docker/OCI, sin exigir credenciales. Afecta a todas las versiones anteriores a la 1.26.2 y expone código fuente, secretos y artefactos de build a cualquier atacante no autenticado.

¿Por qué "privado" en Gitea no significaba privado?

Gitea CVE-2026-27771: tus imágenes privadas nunca lo fueron

Porque la etiqueta "privada" era un control a nivel de la interfaz, no del protocolo. Un repositorio podía figurar como privado en la UI de Gitea, pero el endpoint del registry OCI —la capa que Docker y Kubernetes usan realmente para hacer pull— nunca validaba la autenticación antes de entregar los manifests y las capas de la imagen. El resultado: dos "verdades" distintas sobre quién podía ver qué.

Los investigadores de Orca Security que analizaron el caso lo resumieron sin rodeos: el registry de Gitea permitía que "cualquier persona en internet, sin cuenta, sin contraseña y sin acceso previo, descargara imágenes de contenedor que a primera vista parecerían privadas, como si fueran públicas". No hacía falta ni una vulnerabilidad exótica ni una cadena de exploits: bastaba un docker pull estándar apuntado a la instancia correcta.

¿Cómo funcionaba el bypass de autenticación a nivel técnico?

El bug era una falla de comprobación de permisos en el manejo de las peticiones de "package source" y registry: la implementación no aplicaba correctamente los controles de autenticación y autorización sobre los endpoints OCI que devuelven el manifest y las capas de una imagen. En criollo: el chequeo de "¿este repo es privado?" vivía en un lado del código, y el endpoint que sirve los bytes de la imagen vivía en otro, sin hablar entre sí.

Un atacante no autenticado podía emitir peticiones pull normales de Docker u OCI directamente contra la API del registry y recuperar imágenes marcadas como privadas sin credenciales, tokens ni acceso previo. Ni los investigadores de Horizon3.ai ni los de Orca publicaron un PoC con los comandos exactos, y es lógico: con 30.000+ instancias expuestas, soltar el copy-paste era regalar munición. Pero el patrón de ataque es tan simple que no hace falta el PoC para entender el riesgo.

Lo que quedaba al alcance de la mano no era poca cosa. Una imagen de contenedor "privada" suele arrastrar:

Código fuente propietario. Todo lo que copiaste al build (tu app, tus scripts, tu lógica de negocio) viaja dentro de las capas.
Secretos embebidos. Tokens, claves de API y credenciales que quedaron horneadas en la imagen —una mala práctica común— pasan a ser legibles por cualquiera.
Artefactos de build internos. Binarios, dependencias privadas y componentes que nunca pensaste publicar.
Configuración de infraestructura. Archivos de config, variables y pistas sobre cómo está armado tu stack por dentro.

Es decir: un problema de confidencialidad que, si había secretos dentro de las imágenes, escala rápido a un problema de integridad de todo tu entorno.

¿Qué versiones de Gitea están afectadas y cuál corrige el fallo?

Están afectadas todas las versiones de Gitea anteriores a la 1.26.2; el parche llegó en la 1.26.2, publicada el 20 de mayo de 2026. El fallo estuvo presente durante aproximadamente cuatro años, desde que se introdujo la funcionalidad del registry.

Algunos datos duros para dimensionar el alcance, según el reporte de Orca Security (mayo 2026) y la cobertura de SecurityWeek:

Más de 31.000 instancias expuestas. Se identificaron alrededor de 31.750 instancias de Gitea accesibles desde internet en más de 30 países.
Más de la mitad, en la nube. Cerca del 52% de esas instancias corría sobre plataformas cloud de gran escala, según el mismo análisis.
Sectores sensibles. Entre las organizaciones afectadas aparecieron proveedores de salud, fabricantes aeroespaciales, infraestructura de retail y proveedores de internet.
Descubierto en abril de 2026. El hallazgo se atribuye al agente de pentesting de NoScope, y se publicó el 27 de mayo de 2026.

Ojo si usás Forgejo: el fork de Gitea comparte la misma implementación del registry de contenedores y fue confirmado como vulnerable de forma independiente. Si estás en Forgejo, este aviso te aplica igual —seguí el changelog oficial de tu versión para confirmar en qué release se corrigió.

¿Qué implica esto si corrés Gitea o Forgejo en producción?

Implica que tenés que asumir exposición, no descartarla. Si tu instancia estuvo accesible desde internet con una versión anterior a la 1.26.2 y usaste el registry para imágenes privadas, la posición segura es tratar esas imágenes —y cualquier secreto que contengan— como potencialmente comprometidas, aunque no tengas evidencia de un pull malicioso.

La razón es incómoda pero honesta: al no exigir autenticación, un acceso legítimo y uno malicioso se ven idénticos en muchos logs. No hay un patrón de "intento fallido" que delate al atacante, porque nunca hubo un rechazo. Por eso la respuesta no termina en "actualizá y listo".

¿Qué podés hacer HOY para blindar tu instancia?

Actualizá a Gitea 1.26.2 o superior cuanto antes; es la corrección oficial. Si no podés parchear en el momento, aplicá el workaround de configuración y, sobre todo, rotá cualquier secreto que pudiera haber viajado dentro de una imagen. Los pasos concretos, en orden de prioridad:

Actualizá el binario/imagen de Gitea a 1.26.2+. Es el fix real. En Forgejo, subí a la release que documente esta corrección en su changelog.
Si todavía no podés parchear, cerrá el acceso anónimo. Poné REQUIRE_SIGNIN_VIEW = true bajo la sección [service] de tu app.ini. Esto obliga a login para ver cualquier contenido —incluidos los repos que sí querías públicos—, así que es un tapón temporal, no una solución permanente.
Rotá los secretos que puedan estar en imágenes privadas. Tokens de API, claves de despliegue, credenciales de base de datos: si estuvieron horneados en una imagen expuesta, tratalos como quemados y regeneralos.
Sacá la instancia de la internet abierta si no necesita estar ahí. Una forja interna detrás de una VPN o de una red privada reduce drásticamente la superficie de ataque, más allá de este CVE puntual.
Dejá de hornear secretos en las imágenes. Este incidente es un buen recordatorio para pasar secretos por variables de entorno en runtime o por un gestor dedicado, no por capas del build.

Un ejemplo de la línea del workaround en app.ini:

[service]
REQUIRE_SIGNIN_VIEW = true

Preguntas frecuentes

¿CVE-2026-27771 requiere autenticación para explotarse?

No. Es un bypass de autenticación: un atacante sin cuenta, sin token y sin acceso previo podía descargar imágenes privadas con un pull estándar de Docker/OCI contra el registry.

¿En qué versión de Gitea se corrige?

En la 1.26.2, publicada el 20 de mayo de 2026. Todas las versiones anteriores están afectadas.

¿Forgejo también está afectado?

Sí. Forgejo comparte la implementación del registry de Gitea y fue confirmado como vulnerable en pruebas independientes. Verificá en su changelog la release que aplica el fix.

¿Qué CVSS tiene esta vulnerabilidad?

Tiene un CVSS de 8.2, categoría alta. La gravedad viene de que expone datos confidenciales (código, secretos, artefactos) sin ninguna barrera de acceso.

¿Alcanza con actualizar o también tengo que rotar credenciales?

Actualizar cierra el agujero hacia adelante, pero no deshace la exposición pasada. Si corriste una versión vulnerable expuesta a internet, rotá cualquier secreto que pudiera haber estado dentro de una imagen privada.

¿Cómo sé si me explotaron?

Es difícil de confirmar: como no había rechazo de autenticación, un acceso malicioso se parece a uno legítimo en los logs. Ante la duda, asumí exposición y rotá secretos en lugar de esperar una prueba que quizás no exista.

El patrón detrás del bug (y cómo no repetirlo)

Más allá de Gitea, CVE-2026-27771 es un caso de manual de una clase de fallo que se repite: cuando el control de acceso vive en una capa (la UI, la lógica de "repo privado") pero el dato se sirve desde otra (el protocolo OCI del registry), y ambas no comparten la misma comprobación, el "privado" se vuelve decorativo. La lección práctica para cualquier servicio que expongas es doble: chequeá la autorización en el punto más cercano posible a donde se entregan los bytes, y no confíes en que una etiqueta de la interfaz esté siendo respetada por todos los endpoints que sirven el mismo recurso.

Si te interesa el ángulo de qué termina viajando dentro de una imagen de contenedor y cómo auditarlo, esta nota se complementa bien con nuestra guía sobre usar SBOM con Trivy para saber qué dependencias viajan dentro de una imagen. Y si estás endureciendo tu pipeline, el CI/CD seguro para contenedores con firma de imágenes va en la misma dirección: reducir lo que un atacante puede hacer si algo se filtra.

Fuentes consultadas: Orca Security, The Hacker News, Horizon3.ai y SecurityWeek.