🫖 Validador CVE-2026-60004 para Gitea

Una herramienta independiente de descubrimiento, evaluación y validación correlacionada con contrato para la vulnerabilidad de ejecución remota de código en el Git-hook diffpatch de Gitea.

scanner.py ofrece a pentesters, defensores e investigadores de seguridad una única herramienta sin dependencias para:

• 🔎 Descubrimiento pasivo de Gitea mediante el índice existente de LeakIX
• 🧭 Reconocimiento de rutas públicas y Swagger para un único objetivo
• 🩺 Evaluación de versión no destructiva
• 🧪 Validación de prueba de concepto acotada y autenticada
• 🧾 Evidencia JSON correlacionada con contrato y captura de salida de comandos
• 🛡️ Controles de objetivo único, compuertas de versión, archivos de salida privados y manejo de credenciales de mismo origen

⚠️ Aviso legal y ético

Este proyecto se proporciona únicamente para pruebas de seguridad autorizadas, validación defensiva, investigación y educación. Ejecute los modos activos exclusivamente contra sistemas que posea o para los que tenga permiso escrito explícito de evaluación. Usted es responsable de cumplir con todas las leyes, contratos, reglas de compromiso y requisitos de divulgación aplicables.

Los autores y colaboradores no son responsables por uso indebido, daños, interrupción del servicio, pérdida de datos o consecuencias legales. El PoC activo ejecuta un comando como el usuario del sistema operativo de Gitea y cambia el estado del servidor al crear un repositorio privado. Trátelo como cualquier otra herramienta de validación de RCE.

🧠 Resumen de la vulnerabilidad

CVE-2026-60004 afecta el flujo de trabajo diffpatch de repositorios de Gitea. Un escritor de repositorio puede enviar contenido de parche controlado que instala un Git hook en un clon temporal compartido y desnudo. Aplicar el parche manipulado dos veces desencadena una colisión add/add y provoca que el hook se ejecute como la cuenta de servicio de Gitea.

Forgejo y otros forks no se clasifican automáticamente como vulnerables. Su implementación debe revisarse de forma independiente.

✨ Qué hace cada modo

Los modos activos no aceptan listas de objetivos ni comodines.

📦 Requisitos

• Python 3.10 o más reciente
• Git disponible en PATH
• Acceso de red al objetivo Gitea seleccionado explícitamente
• Credenciales válidas de Gitea, o autorregistro explícitamente aprobado
• Una referencia de autorización/contrato por escrito para pruebas activas
• Opcional: una clave API de LeakIX para discover

El escáner usa únicamente la biblioteca estándar de Python. No se requiere pip install.

🚀 Instalación

git clone https://github.com/InfoSec-DB/CVE-2026-60004-Gitea-Validator.git
cd CVE-2026-60004-Gitea-Validator
python3 scanner.py --help

🩺 Comience con comprobaciones no destructivas

Verifique la versión reportada

python3 scanner.py verify \
  https://gitea.example \
  --contract-number ENG-2026-001 \
  --output evidence/version.json

Inventarie rutas públicas y metadatos Swagger

python3 scanner.py recon \
  https://gitea.example \
  --contract-number ENG-2026-001 \
  --output evidence/recon.json

La detección de versión es una señal de evaluación, no una prueba de explotabilidad. Los parches retroportados, las compilaciones personalizadas, los proxies inversos y los forks pueden requerir revisión manual.

🧪 Confirmación activa autorizada

Cuenta de prueba aprobada existente

Mantenga la contraseña fuera del historial del shell colocándola en el entorno para el comando:

GITEA_PASSWORD='replace-with-approved-test-password' \
python3 scanner.py confirm \
  https://gitea.example \
  --contract-number ENG-2026-001 \
  --username audit-user \
  --execute-poc \
  --write-client-marker \
  --output evidence/confirmation.json

A menos que se proporcione --yes-i-am-authorized para automatización, confirm le pide escribir la frase de confirmación vinculada al contrato. El comando remoto predeterminado es id.

Autorregistro desechable

Use esto únicamente cuando la creación de cuentas esté permitida por las reglas de compromiso:

python3 scanner.py confirm \
  https://gitea.example \
  --contract-number ENG-2026-001 \
  --register-test-account \
  --credential-log evidence/credentials.txt \
  --execute-poc \
  --write-client-marker \
  --output evidence/confirmation.json

La contraseña se almacena solo en el registro de credenciales privado, no se duplica en la evidencia JSON ni en el panel de resultados del terminal.

Perfil de prueba con un solo comando

python3 scanner.py test \
  https://gitea.example \
  --contract-number ENG-2026-001

🚨 test es un comando de conveniencia activo. En un objetivo afectado con registro habilitado, crea automáticamente una cuenta y un repositorio privado, escribe el marcador del contrato, ejecuta id y guarda los resultados en afterdark-results/. Intencionalmente no tiene aviso interactivo adicional, por lo que invocarlo es el reconocimiento de autorización.

Comando personalizado

Para validación de alcance limitado y explícitamente aprobada, confirm y test aceptan --cmd. Prefiera el perfil predeterminado id siempre que sea suficiente.

GITEA_PASSWORD='replace-with-approved-test-password' \
python3 scanner.py confirm \
  https://gitea.example \
  --contract-number ENG-2026-001 \
  --username audit-user \
  --execute-poc \
  --cmd 'uname -a' \
  --output evidence/confirmation.json

🌐 Descubrimiento pasivo con LeakIX

export LEAKIX_API_KEY='replace-with-your-key'
python3 scanner.py discover \
  --method app \
  --pages 3 \
  --output evidence/leakix.json

Para inspeccionar registros de LeakIX de un host conocido sin contactar a ese host:

python3 scanner.py discover \
  --method host \
  --target gitea.example \
  --pages 1 \
  --output evidence/leakix-host.json

Los resultados del descubrimiento son pistas, no autorización para escanear o explotar los sistemas listados.

🔬 Cómo funciona el PoC integrado

1. Confirma que el producto/versión reportado pasa la compuerta de prueba activa.
2. Se autentica con una cuenta aprobada o crea una cuenta desechable cuando se solicita explícitamente.
3. Crea un repositorio privado con nombre único inicializado con una rama predeterminada.
4. Construye un parche que agrega un archivo ejecutable hooks/post-index-change.
5. Envía el parche dos veces al endpoint de API diffpatch del repositorio.
6. El hook ejecuta el comando seleccionado y escribe su salida combinada en objetos Git.
7. Un cliente Git temporal obtiene la referencia de salida única.
8. El escáner escribe evidencia correlacionada con contrato usando archivos privados 0600 y se niega a sobrescribir evidencia existente.

Las redirecciones HTTP autenticadas están restringidas al origen del objetivo seleccionado. La recuperación de salida de Git también deshabilita redirecciones mientras el encabezado de autorización está activo.

🧾 Manejo de evidencia y datos sensibles

Las ejecuciones activas pueden producir:

• confirmation.json — marcas de tiempo, objetivo, nombre de cuenta, evaluación de versión, código de retorno y salida capturada
• confirmation.command-output.txt — salida completa del comando remoto
• credentials.txt — contraseña generada de cuenta desechable, cuando se solicita
• Contenido de embedded-result.txt conservado dentro de la evidencia JSON

Estos archivos pueden contener datos sensibles del compromiso. Están ignorados por el .gitignore incluido, se crean con modo 0600 y deben cifrarse en reposo según su política de manejo de evidencia.

🧹 Lista de verificación de limpieza

La herramienta evita deliberadamente la eliminación automática para que la evidencia permanezca disponible para revisión. Después de las pruebas, un administrador del objetivo debe:

• Eliminar la cuenta audit-* generada, si se creó una
• Eliminar el repositorio privado afterdark-* generado
• Eliminar el marcador opcional /tmp/gitea-validation-*/client.txt
• Archivar o eliminar de forma segura credenciales y evidencia locales
• Actualizar Gitea a 1.27.1 o posterior
• Reproducir solo la validación mínima segura necesaria para confirmar la remediación

La ejecución exitosa del PoC demuestra ejecución de comandos como la cuenta de servicio de Gitea. No prueba por sí misma acceso root, persistencia, movimiento lateral o compromiso del host subyacente.

🛡️ Controles de seguridad

• URL de objetivo único exacto únicamente; sin soporte de comodines ni archivos de objetivos
• Número de contrato incluido en el User-Agent y marcador opcional
• Compuerta de versión activa bloquea versiones parcheadas conocidas
• Comando predeterminado limitado a id o whoami
• Interruptor explícito --execute-poc para confirm
• Autorregistro es opcional y se omite cuando está deshabilitado
• Aplicación de redirecciones de mismo origen para solicitudes HTTP autenticadas
• Redirecciones de Git deshabilitadas durante la recuperación de salida con credenciales
• Credenciales pasadas al proceso hijo en memoria/entorno, luego redactadas de la salida capturada
• Archivos de evidencia privados de creación exclusiva; los archivos existentes nunca se sobrescriben
• Tiempo de espera de 180 segundos para el proceso hijo y captura de salida acotada

✅ Ejecute las pruebas

Las pruebas incluidas son locales y no realizan solicitudes de red:

python3 -m unittest discover -s tests -v

🤝 Contribuciones

Las mejoras responsables son bienvenidas, especialmente correcciones de compatibilidad, reducción de falsos positivos, mejoras en la calidad de la evidencia y flujos de limpieza más seguros. Por favor, no envíe detalles de objetivos reales, credenciales, evidencia privada ni cargas útiles armamentizadas.

Para un problema de seguridad en esta herramienta en sí, siga SECURITY.md.

📚 Referencias y créditos

• Aviso oficial de Gitea: GHSA-rcr6-4jqh-j84m
• Lanzamientos de Gitea
• Reportero del CVE acreditado por el aviso upstream: NightRang3r
• Validador mantenido por el AfterDark Security Research Group

Hecho para investigadores cuidadosos que creen que un buen PoC debe ser reproducible, atribuible y aburrido de limpiar. 🛡️