Gitea CVE-2026-59774: file read sin login que escala a RCE

Si autohospedás Gitea para tus repositorios, esta semana toca actualizar sin excusas. El 2 de agosto de 2026 se hizo público CVE-2026-59774, una falla crítica (CVSS 9.8) en el renderer de Org-mode que permite a un atacante sin autenticarse leer archivos arbitrarios del servidor y, encadenando un par de pasos, llegar a ejecución remota de código. No hace falta cuenta, ni permisos de escritura, ni un repo privado: alcanza con un repositorio público y un fragmento de markup malicioso.

CVE-2026-59774 es una vulnerabilidad de path traversal (CWE-22) en Gitea, la plataforma Git self-hosted escrita en Go. Afecta a las versiones 1.22.1 a 1.27.0 y está parcheada en la 1.27.0.1 y la 1.27.1. Un atacante anónimo puede enviar markup de Org-mode a un repo público y leer cualquier archivo que pueda ver el usuario del servicio Gitea —incluido app.ini—, lo que abre la puerta a exponer secretos y escalar a RCE.

¿Qué falla exactamente en Gitea con CVE-2026-59774?

La falla está en cómo Gitea renderiza archivos .org (Org-mode) usando la librería go-org. Según el advisory oficial GHSA-6v53-hr58-556r, "Gitea 1.27.0 initializes go-org using org.New() and does not replace its default ReadFile". Ese callback por defecto es ioutil.ReadFile, y la directiva #+INCLUDE de Org-mode acepta rutas absolutas y se las pasa directo. Resultado: el servidor lee el archivo que le pidas y te devuelve el contenido renderizado.

El punto de entrada es el endpoint POST /{owner}/{repo}/markup, que acepta peticiones anónimas sobre repositorios públicos. Con Mode: file y un nombre de archivo .org, el markup enviado se procesa como si fuera contenido del repo. La cadena vulnerable, en criollo:

• El endpoint no exige login. Cualquiera que llegue a la instancia y encuentre un repo público puede invocarlo.
• La directiva #+INCLUDE no está saneada. Admite paths absolutos como /etc/passwd o la ruta del app.ini y los pasa al lector de archivos sin filtrar.
• El callback por defecto lee lo que sea. Al no reemplazar ReadFile, go-org usa el de sistema, sin límite al directorio del repositorio.

¿Cómo se pasa de leer archivos a ejecutar código (RCE)?

La lectura de archivos por sí sola no es RCE directa: hay que encadenarla. El propio advisory describe el camino: un atacante lee app.ini, extrae el INTERNAL_TOKEN, inyecta un Git hook a través del internal logger y logra ejecución de comandos como el usuario del sistema operativo de Gitea durante un clone anónimo. Es decir, el file-read es el primer eslabón de una escalada, no un exploit de una sola petición.

Por qué importa el INTERNAL_TOKEN: es la credencial que Gitea usa para sus llamadas internas privilegiadas. Con ese token, ciertos endpoints internos dejan de estar fuera del alcance del atacante, y ahí es donde entra la inyección del hook. Los hooks de Git son scripts que corren en el servidor ante eventos del repositorio, así que un hook malicioso disparado por un clone se traduce en ejecución de comandos con los permisos del proceso Gitea.

¿Qué versiones de Gitea están afectadas y cuál corregir?

Están afectadas las versiones 1.22.1 hasta la 1.27.0 inclusive. La corrección llegó en la 1.27.1 (y el backport 1.27.0.1), que reemplaza el ReadFile por defecto de go-org por uno que restringe el acceso al árbol del repositorio.

La vulnerabilidad fue descubierta por el sistema ofensivo autónomo XBOW Security, triada por Guido Leo (alias NightRang3r), y reportada de forma independiente por Shai Rod, según el reporte de The Hacker News.

¿Está siendo explotada activamente en la práctica?

Acá conviene bajar un cambio y separar el ruido de los titulares del dato duro. Varios medios titularon "explotación activa", pero Gitea no reporta explotación confirmada in-the-wild y, según The Hacker News, al 5 de agosto de 2026 el CVE tampoco figuraba en el catálogo Known Exploited Vulnerabilities (KEV) de CISA. The Hacker News aclara además que "found no independently published exploit demonstrating it".

• El riesgo es real, no la explotación confirmada. Que no haya casos públicos verificados no baja la criticidad: es CVSS 9.8, sin auth y con detalles técnicos ya publicados.
• El primitivo de file-read tuvo preview público antes del advisory formal. Con la mecánica del #+INCLUDE descrita en detalle, reproducir la lectura de archivos es trivial para cualquiera con las fuentes en mano.
• La ventana de exposición es lo que preocupa. Toda instancia self-hosted sin parchear y accesible desde internet es un blanco fácil, tenga o no un exploit "famoso" circulando.

Traducido: no esperes a que aparezca en el KEV para actualizar. Cuando una falla sin autenticación tiene la cadena de explotación documentada, el tiempo entre "PoC público" y "escaneos masivos" se mide en días.

¿Qué tenés que hacer HOY si corrés Gitea?

Lo primero y no negociable: actualizar a Gitea 1.27.1 (o 1.27.0.1 si estás en la rama 1.27.0). Si tu instancia estuvo expuesta con una versión afectada, además hay que asumir compromiso de secretos y rotar. Pasos concretos:

1. Si estuviste expuesto, rotá todo lo que el servicio podía leer. El INTERNAL_TOKEN, el SECRET_KEY, tokens OAuth, claves de firma JWT y credenciales de base de datos en app.ini.
2. Inspeccioná los directorios de hooks. Buscá archivos ejecutables inesperados dentro de .git/hooks de los repos, señal de un hook inyectado.

Revisá los logs en busca de abuso. Buscá peticiones al endpoint de markup, sobre todo con Org-mode o rutas absolutas:

grep -E 'POST /.+/.+/markup' /var/lib/gitea/log/access.log

Actualizá el binario o la imagen. Si usás Docker, apuntá al tag corregido y recreá:

docker pull gitea/gitea:1.27.1
docker compose up -d

Verificá tu versión actual. Desde el binario o el contenedor:

gitea --version
# o dentro del contenedor
docker exec <container> gitea --version

Como mitigación de fondo, mantené tu Gitea detrás de un reverse proxy con reglas claras y no lo expongas más de lo necesario. Si además corrés tu instancia en un servidor cloud con acceso completo al sistema, tenés margen para aplicar el parche al instante y rotar secretos sin depender de ventanas de mantenimiento de terceros —justo lo que un Cloud Server de Donweb te permite: control total del OS para actualizar en el momento.

Preguntas frecuentes sobre CVE-2026-59774

¿CVE-2026-59774 permite RCE con una sola petición?

No. La única petición te da lectura arbitraria de archivos; la ejecución de código requiere encadenar: leer app.ini, extraer el INTERNAL_TOKEN, inyectar un Git hook vía el internal logger y dispararlo con un clone anónimo.

¿Me afecta si mi Gitea no tiene repositorios públicos?

El vector documentado usa un repositorio público con el renderizado de código habilitado para llegar al endpoint /markup sin autenticarse. Aun así, la recomendación es actualizar sí o sí: la superficie exacta depende de tu configuración y no conviene apostar.

¿Qué versión corrige la falla?

Gitea 1.27.1 (con backport a 1.27.0.1). Reemplaza el callback ReadFile por defecto de go-org para que no salga del árbol del repositorio.

¿Tengo que rotar credenciales aunque haya actualizado?

Solo si tu instancia estuvo expuesta con una versión afectada. En ese caso, tratá como comprometido todo lo que el usuario del servicio podía leer y rotá el INTERNAL_TOKEN, claves de firma, tokens OAuth y credenciales de base de datos.

¿Está en el catálogo KEV de CISA?

Al 5 de agosto de 2026 no figuraba en el KEV y Gitea no reportó explotación in-the-wild confirmada. Eso no reduce la urgencia: la criticidad es 9.8 y no requiere autenticación.

El patrón se repite: Gitea y las fallas sin autenticación

No es la primera vez que Gitea suma un CVE crítico sin login en poco tiempo. Si venís siguiendo el tema, te sirve leer también nuestras notas sobre "Gitea CVE-2026-20896: el header que te convierte en admin" y "Gitea CVE-2026-27771: tus imágenes privadas nunca lo fueron". El denominador común es claro: renderizadores y endpoints que procesan input de usuario anónimo sin límites estrictos. La lección práctica para cualquier plataforma self-hosted es tratar todo endpoint accesible sin auth como superficie de ataque de primer orden, cerrar el renderizado de formatos que incluyan archivos externos y actualizar rápido cuando el proyecto publica un fix de seguridad. En Git self-hosted, la comodidad de tener todo puertas adentro solo rinde si la disciplina de parcheo va al mismo ritmo.

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