Gitea, la plataforma de código Git autoalojada, corrigió una vulnerabilidad crítica que puede derivar en lectura de archivos sin autenticación. En las versiones 1.22.1 a 1.27.0, un atacante no necesita iniciar sesión ni tener permisos de escritura en el repositorio: con un repositorio público y un marcado en formato Org-mode especialmente preparado, puede acceder a archivos que la cuenta del servicio de Gitea tiene permitido leer.
La corrección llegó con Gitea 1.27.1. Además, esta versión también incorpora parches para otra falla de ejecución remota de código (CVE-2026-60004) reportada previamente.
Qué permite la vulnerabilidad de lectura de archivos
El fallo se registra como CVE-2026-59774, con severidad Crítica y CVSS 9.8. El escenario descrito por el fabricante indica que el atacante puede leer cualquier fichero al que pueda acceder la cuenta de servicio de Gitea, siempre que se cumplan condiciones concretas.
Según la información disponible, no se trata de una cadena de ejecución remota de código “de una sola petición”. Sin embargo, Gitea advierte que el problema puede escalar: si el atacante logra obtener determinados archivos de configuración (por ejemplo, app.ini para extraer un INTERNAL_TOKEN), entonces sería posible inyectar un hook de Git a través de un mecanismo interno de registro y forzar su ejecución durante un clon anónimo.
La cadena exacta fue documentada en el aviso del proyecto. Hasta donde se conoce en el reporte de referencia, no había una demostración de explotación publicada de forma independiente.
Condiciones necesarias para el acceso sin autenticación
La ruta afectada pasa por el endpoint de renderizado de marcado de Gitea: POST /{owner}/{repo}/markup. El controlador permite acceso opcional con inicio de sesión, resuelve el repositorio y verifica permisos del lector.
El punto clave para el ataque sin autenticación es que, cuando la petición es anónima, la comprobación de permisos se limpia para cualquier repositorio que sea público y tenga activada la unidad de código correspondiente. En la práctica, esto significa que un despliegue sin repositorios públicos no tendría una vía anónima utilizable contra este endpoint.
El origen del problema en el renderizador Org-mode
El fallo está ligado al modo en que Gitea procesa el marcado Org-mode. En Gitea 1.27.0 se inicializa go-org de cierta manera y no se reemplaza el callback de lectura de archivos por defecto.
En la versión referida de go-org, el callback de lectura utilizado equivale a ioutil.ReadFile. En Org-mode, la directiva #+INCLUDE permite incluir contenido desde rutas absolutas, pasando dichas rutas directamente a ese callback. De este modo, el atacante envía marcado que selecciona un modo apropiado (por ejemplo, un modo de “archivo”) y recibe de vuelta el contenido de archivos accesibles para la cuenta de servicio de Gitea.
Cómo saber si tu instancia puede estar expuesta
Primero, verifica tu versión. Esta lectura de archivos aplica a Gitea 1.22.1 hasta 1.27.0, y se corrige en 1.27.1. Si tu sistema no está en ese rango, el riesgo asociado a CVE-2026-59774 no debería estar presente por este motivo.
Además, aunque actualices, se recomienda evaluar si pudo haber exposición previa. El aviso del fabricante sugiere que, si hubo intentos del endpoint de marcado en una versión afectada, debes considerar que determinados secretos podrían haberse vuelto accesibles desde el lado del atacante.
En concreto, busca en tus logs peticiones anónimas POST /{owner}/{repo}/markup que:
- Seleccionen rendering relacionado con Org-mode.
- Incluyan rutas que parezcan apuntar al sistema de archivos, especialmente rutas absolutas.
Si el plan de escalado descrito en el aviso llegó a intentarse, entonces habría que tratar como comprometidos (o potencialmente accesibles) secretos que protege la instancia, incluyendo el token interno y otros materiales de autorización.
Qué hacer: actualiza a Gitea 1.27.1
La medida principal es actualizar. Gitea indicó que, en entornos de la nube, las instancias serían elevadas automáticamente durante la ventana de mantenimiento del ciclo de liberación. Si gestionas tu despliegue por tu cuenta, el consejo es claro: muévete a 1.27.1 de inmediato.
La actualización corrige la causa técnica modificando cómo se resuelve el contenido en el renderizador: al sobrescribir el callback de lectura, el include de Org-mode se devuelve como contenido renderizado plano, evitando que la ruta se traduzca a una lectura directa desde el sistema de archivos.
La corrección se implementó mediante cambios respaldados por parches y pruebas de regresión, incluyendo un test para el renderizado del include-path.
Si hubo explotación: rotación de tokens y credenciales
Actualizar es necesario, pero puede no ser suficiente si sospechas que el atacante ya pudo aprovechar el problema en una versión vulnerable. En ese caso, el aviso recomienda tratar como expuestos los elementos que podrían permitir la cadena de escalado hacia ejecución.
Como mínimo, se menciona la rotación de:
- INTERNAL_TOKEN
- Materiales de OAuth
- Claves de firma para JWT
- Credenciales de base de datos
Además, revisa rutas de hooks en los repositorios o directorios de hooks configurados: si la escalada fue intentada, podría haberse colocado contenido ejecutable donde no corresponde.
Detección práctica en tu entorno
El aviso no describe una guía formal de detección lista para usar, así que conviene armar una revisión basada en patrones de acceso y contenido de la petición. Prioriza las peticiones anónimas al endpoint de marcado y observa si el cuerpo del request sugiere Org-mode o inclusiones que podrían contener rutas absolutas.
También ayuda evaluar el tráfico alrededor del momento en que tu instancia ejecutaba una versión afectada (entre 1.22.1 y 1.27.0). Si detectas coincidencias fuertes, asume exposición potencial y aplica el plan de remediación indicado.
En el material de referencia se señala además que no se había visto explotación “en la naturaleza” al momento de los datos divulgados, y que tampoco constaba (a esa fecha) como explotada en catálogos conocidos del regulador. Aun así, tu propia evidencia de logs manda.
Contexto: ola reciente de correcciones de seguridad
El problema descrito se suma a una serie de trabajos de seguridad en Gitea. En meses previos se mencionaron correcciones de autenticación y de acceso en componentes relacionados con contenedores, incluyendo fallas que se estimaban con un impacto amplio en despliegues. Este historial refuerza la idea de tratar las actualizaciones de Gitea como una prioridad operativa.
Conclusión
La vulnerabilidad CVE-2026-59774 muestra cómo un fallo en el renderizado de Org-mode puede terminar en lectura de archivos desde servidores que ejecutan Gitea, incluso sin iniciar sesión. Si usas una versión entre 1.22.1 y 1.27.0, el paso más importante es actualizar a Gitea 1.27.1.
Y si existen señales de acceso al endpoint de marcado en el periodo vulnerable, actúa con criterio: revisa logs, verifica posibles inclusiones maliciosas, rota tokens y credenciales relevantes y contempla la revisión de directorios de hooks. Con esas acciones, reduces el riesgo de que la exposición previa se convierta en algo más que solo lectura.
Fuente: https://thehackernews.com/2026/08/critical-gitea-flaw-let-unauthenticated.html
