Se urge a los usuarios de Gitea a actualizar su software inmediatamente debido a una vulnerabilidad crítica (CVE-2026-58443). Este fallo de seguridad permite que tokens de acceso de repositorios públicos puedan escribir indirectamente en ramas de solicitudes de extracción (pull requests) privadas y activar flujos de trabajo de Actions privados. El problema afecta a las versiones hasta la v1.26.4 y ha sido solucionado en la versión v1.27.0.

Se insta a los usuarios de Gitea a actualizar inmediatamente después de que se revelara una vulnerabilidad crítica que permite que los tokens de acceso a repositorios solo públicos escriban indirectamente en ramas de solicitudes de extracción (pull requests) privadas y activen flujos de trabajo de Actions privados.

Identificada como CVE-2026-58443, la vulnerabilidad afecta a las versiones de Gitea hasta la v1.26.4 y ha sido corregida en la v1.27.0. El fallo reside en el punto final de la API de actualización de solicitudes de extracción de Gitea:

POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/update.

Un token restringido a repositorios públicos, con el alcance write:repository, no debería poder acceder ni modificar un repositorio privado.

Sin embargo, los atacantes pueden explotar la ruta de la solicitud de extracción pública para enviar cambios desde un repositorio base público hacia una rama de destino de una solicitud de extracción privada.

Esto crea una omisión de autorización porque Gitea valida la restricción del token contra el repositorio base público nombrado en la ruta de la API.

Vulnerabilidad de Gitea

Aunque la aplicación verifica posteriormente el acceso al repositorio de destino privado utilizando los permisos normales basados en roles de la cuenta de usuario, no vuelve a aplicar la restricción de "solo público" del token activo.

Por lo tanto, un token que falla al intentar una escritura directa en un repositorio privado aún puede modificar una rama privada a través de la función de actualización de la solicitud de extracción.

Según el aviso de GitHub (GHSA-xxjv-752h-3vp2), la vulnerabilidad está calificada como Crítica con una puntuación CVSS de 9.6 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H), lo que significa que puede ser explotada remotamente con privilegios bajos y sin interacción del usuario, afectando principalmente la integridad y la disponibilidad.

Investigadores de seguridad demostraron que un atacante podría primero crear contenido en un repositorio base público y luego invocar el punto final de actualización vulnerable para una solicitud de extracción dirigida a una rama privada.

Gitea fusionaría o reorganizaría los commits del repositorio público en esa rama privada en el lado del servidor. El problema se vuelve más grave cuando Gitea Actions está habilitado en el repositorio privado.

Un envío exitoso al servidor puede activar flujos de trabajo configurados para eventos de envío (push) en el repositorio privado. En la prueba de concepto, el commit inyectado inició un flujo de trabajo privado correspondiente, creando un ActionRun y el trabajo asociado.

El atacante necesita un token válido de solo público con alcance de escritura de repositorio. La cuenta de usuario asociada a este token también debe tener permisos de escritura normales en la rama de destino de la solicitud de extracción privada.

Además, el ataque requiere un repositorio base público y una relación de solicitud de extracción existente que permita actualizaciones desde la rama base hacia la rama privada.

Esto significa que el fallo no otorga acceso anónimo a repositorios privados. Sin embargo, socava un límite de seguridad importante de los tokens.

Las organizaciones pueden emitir tokens de solo público para limitar las consecuencias de una exposición accidental o mal uso en la automatización. Esta vulnerabilidad permite que dicho token restringido realice una escritura en un repositorio privado bajo condiciones específicas de solicitud de extracción.

Los administradores de Gitea deben actualizar inmediatamente a la v1.27.0 y, hasta que se implementen los parches, revisar los tokens de solo público con permisos de escritura de repositorio, restringir las capacidades de actualización de solicitudes de extracción y auditar las relaciones de fork y solicitudes de extracción de público a privado.

Los equipos también deberían inspeccionar los registros de Actions en busca de cualquier flujo de trabajo inesperado activado por un envío en repositorios privados, prestando especial atención a los flujos iniciados tras la actividad de la API de actualización de solicitudes de extracción que involucren repositorios base públicos.

La vulnerabilidad está clasificada como CWE-863, Autorización Incorrecta. El aviso acredita al investigador ohxorud-dev por informar el problema, con bircni publicando el aviso.