Productos FTTH

Tienda FFTH desde 2004

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Nuevo fallo de RCE en Gitea permite a redactores de repositorios ejecutar comandos de shell mediante Git Hooks


Gitea corrigió una vulnerabilidad crítica de ejecución remota de código (CVE-2026-60004) que permitía a usuarios con acceso de escritura ejecutar comandos en el servidor. El fallo afectaba a versiones desde la 1.17 hasta la 1.27.0, siendo explotable incluso por visitantes debido al registro abierto por defecto. Se recomienda actualizar urgentemente a la versión 1.27.1 para solucionar este problema de seguridad.



Gitea, la plataforma Git autoalojada, ha corregido una vulnerabilidad crítica de ejecución remota de código (RCE). Un usuario con acceso de escritura ordinario en un repositorio puede convertir el contenido de un parche controlado por el atacante en un hook de Git activo y ejecutar comandos de shell como la cuenta de servicio de Gitea.

Rastreada como CVE-2026-60004 (puntuación CVSS: 9.8), el fallo afecta a las versiones de Gitea 1.17 y posteriores antes de la 1.27.1, y ha sido solucionado en la versión 1.27.1. La llamada a la API vulnerable requiere autenticación y permiso de escritura en el repositorio. Sin embargo, Gitea permite el registro por defecto, por lo que un visitante externo puede crear una cuenta normal y un repositorio en una instalación sin cambios, y luego explotar el error sin credenciales preexistentes.

La solución es actualizar a la versión 1.27.1. Gitea indicó el 27 de julio que las instancias de Gitea Cloud se actualizarían automáticamente. El aviso de Gitea del 28 de julio no menciona si el fallo ha sido explotado en la práctica, pero incluye un código de prueba de concepto (PoC) público.

Desactivar el registro abierto puede eliminar la vía de creación de cuentas públicas mientras se despliega la actualización, pero no soluciona el fallo ni protege contra los usuarios existentes con acceso de escritura al repositorio. El fallo fue reportado por el investigador de seguridad Shai Rod, conocido como NightRang3r. Gitea acredita a NightRang3r como el informante en su aviso.

La ruta afectada de Gitea (enlace) invoca reqToken(), que rechaza las solicitudes sin un usuario conectado. La ruta sin credenciales previas proviene de la configuración por defecto del proyecto (enlace), que deja el registro abierto, no requiere correo electrónico ni aprobación manual, no marca a los nuevos usuarios como restringidos y no impone un límite predeterminado de creación de repositorios.

El error se encuentra en el endpoint POST /api/v1/repos/{owner}/{repo}/diffpatch. Según el aviso de seguridad de Gitea (enlace), el endpoint aplica un parche suministrado dentro de un clon temporal bare compartido. Las versiones vulnerables invocan git apply con --index, --recount, --cached y --binary, añadiendo la opción de fallback de tres vías -3 cuando el servidor ejecuta Git 2.32 o posterior.

Un atacante envía el mismo parche dos veces para crear una colisión add/add. El fallback de tres vías entonces extrae la ruta indexada aunque la operación utilice --cached. Debido a que el clon temporal es bare, su raíz es $GIT_DIR. Por lo tanto, un archivo ejecutable colocado en hooks/post-index-change aterriza en el directorio de hooks de Git y se vuelve activo. Git lo ejecuta mientras actualiza el índice. El PoC inicia sesión con una cuenta normal, crea un repositorio privado inicializado, envía el parche malicioso dos veces y recupera la salida del comando. No necesita una llamada externa. El hook almacena la salida en objetos de Git, crea una rama que contiene el resultado y permite que el atacante lo obtenga a través de HTTP inteligente autenticado.

Hasta el 29 de julio de 2026, ninguna de las fuentes primarias citadas informa si el fallo fue explotado antes o después de que la versión 1.27.1 estuviera disponible.

Una explotación exitosa otorga al atacante los privilegios de la cuenta del sistema operativo de Gitea. Dependiendo de cómo esté aislada la instancia, Gitea afirmó que esto podría exponer secretos de la aplicación y del entorno, repositorios montados, credenciales y contenidos de la base de datos, credenciales de OAuth y servicios internos accesibles. La explotación todavía requiere acceso de escritura al repositorio, Git 2.32 o posterior, una ruta diffpatch habilitada y un sistema de archivos temporal ejecutable y escribible. El registro por defecto permite que un extraño obtenga el acceso de escritura requerido en una instalación sin cambios.

La corrección es fácil de pasar por alto en el registro de cambios. Gitea cambió el clon temporal de bare a no-bare. El comentario del código (enlace) advierte explícitamente que los comandos de Git que utilizan --index pueden operar en el árbol de trabajo. El cambio fue fusionado y retrocedido el 26 de julio de 2026.

La versión 1.27.1 fue lanzada (enlace) el 27 de julio, y el aviso de seguridad le siguió el 28 de julio. Las notas de la versión enumeraron el cambio bajo MISC como "refactor: git patch apply", no bajo SECURITY.

Rod había anticipado el RCE junto con un problema separado de inclusión de archivos (enlace), con un PoC recuperando /etc/passwd de un host Gitea 1.27.0. Ese problema parece corresponder a un cambio separado incluido en la 1.27.1 (enlace) que alteró el renderizador de modo Org de Gitea para que las rutas #+INCLUDE se devuelvan como texto plano en lugar de ser leídas del sistema de archivos del servidor. Gitea no ha publicado un aviso separado ni un CVE para el problema de inclusión de archivos.

Fuente:
THN


0 comments :

Post a Comment

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.