squeeze440/crw-pocPoC — SSRF mediante el bypass de la capa de renderizado JS del filtro de seguridad de URL en crw (GHSA-5jp3-339h-vxqw, CVE-2026-87007, CVSS 7.5).
Estado del CVE: solicitado, pendiente de asignación. Este hallazgo se publica como GHSA-5jp3-339h-vxqw. Al asignarse el CVE, este repositorio se renombra
CVE-YYYY-NNNNN-crw-PoCy este banner se reemplaza con el enlace del CVE.
| Investigador | Dostxodjayev Abdullox (@squeeze440) |
| Aviso | GHSA-5jp3-339h-vxqw |
| CVSS 3.1 | 7.5 (Alto) |
| Debilidad | CWE-918 |
Resumen
En crw-server, la lista de permitidos/denegados de SSRF (crw_core::url_safety) se aplica solo una vez, contra la url proporcionada por el llamador, antes de que la solicitud se despache a un renderizador; los niveles de renderizado JS basados en CDP (LightPanda — el renderizador JS predeterminado — y Chrome) luego dirigen la página objetivo mediante Page.navigate y siguen cada redirección posterior, navegación activada por JS y XHR/fetch dentro de la página enteramente dentro de la propia pila de red del navegador, sin ninguna llamada adicional a url_safety en ningún momento, lo que permite a un llamador autenticado (o, en un despliegue predeterminado sin clave, no autenticado) que establece renderJs:true pivotar el rastreador hacia el espacio de direcciones RFC1918/loopback/link-local mediante una única redirección abierta externa y leer de vuelta la respuesta del servicio interno en el cuerpo de la respuesta de la API.
Producto
fastCRW / crw — crw-server (API REST, también accesible de forma idéntica a través de la capa de herramientas MCP en proceso crw-mcp, que llama a la misma ruta de código crw_server::routes::mcp::call_tool).
Versión probada
Commit 9f1e5ea5555bbf29cd41e454902be0cd804a15e4 (v0.28.0, punta de main en el momento de la prueba), compilado y ejecutado mediante el propio docker-compose.yml --profile heavy del proyecto.
CVSS v3.1 estimado
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N — 7.5 (Alto)
PR:N: el valor predeterminado de autoalojamiento incluido (config.docker.toml) no tiene sección [auth]/api_keys, coincidiendo con el valor predeterminado "abierto por diseño" ya documentado en GHSA-qq8c-fch4-cxq7. Un despliegue que sí configure claves de API degrada esto a PR:L (cualquier inquilino autenticado individual aún puede pivotar el motor compartido hacia la red interna en la que se ejecute) — el error no se mitiga añadiendo claves, solo se recondiciona.I:N/A:N: el PoC demuestra la lectura de vuelta de una respuesta HTTP interna (confidencialidad). No se ejerció ni se afirma ninguna acción de escritura/cambio de estado contra un objetivo interno.S:U: la divulgación está mediada enteramente a través del propio canal de respuesta de la API del componente vulnerable.Detalles
Causa raíz: la ruta del renderizador CDP/navegador nunca llama a crw_core::url_safety después de la única comprobación realizada en la capa de rutas.
crates/crw-server/src/routes/scrape.rs:29-34 (idénticamente en crawl.rs:47/136, map.rs:73/58, extract.rs:178/95, batch.rs:111/102, v2/*, routes/mcp.rs:25) — la única comprobación de SSRF en todo el ciclo de vida de la solicitud para una solicitud renderizada por JS: crw_core::url_safety::validate_safe_url_resolved(&parsed_url) se ejecuta una vez contra la url literal del llamador, antes de que el renderizador sea siquiera invocado.crates/crw-renderer/src/cdp.rs:2621-2631 — el futuro work de fetch_inner envía Page.navigate con la url sin procesar directamente al endpoint CDP (compartido tanto por los niveles chrome como lightpanda — ambos hablan CDP a través de esta misma función). Chrome/LightPanda luego realiza su propia resolución DNS y sigue cualquier redirección del lado del servidor, <meta http-equiv="refresh"> o cambio de location por JS internamente. No existe ninguna llamada a url_safety en ningún lugar de cdp.rs.crates/crw-renderer/src/blocklist.rs:1-124 — la única lógica de intercepción Fetch.requestPaused por solicitud que se ejecuta durante un renderizado CDP (conectada en cdp.rs alrededor de las líneas 930-1002). Filtra hosts de anuncios/rastreadores y tipos de recursos bloqueados (imágenes, fuentes, etc.) solo por razones de ancho de banda/ruido — nunca comprueba el destino de una solicitud contra rangos privados/loopback/link-local.crates/crw-crawl/src/single.rs:559-569 — el único lugar donde se inspecciona en absoluto el final_url posterior a la navegación. redirect_is_material() solo decide si adjuntar una cadena cosmética "redirected_to: <url>" a data.warnings (para señalar "obtuviste la página equivocada", según el comentario que hace referencia a northernair.ca) — nunca llama a url_safety::validate_safe_url* y nunca hace fallar la solicitud.crates/crw-renderer/src/http_only.rs:291 — el nivel HTTP simple (sin JS) envuelve correctamente su reqwest::Client en crw_core::url_safety::safe_redirect_policy(), que revalida (con resolución DNS) cada salto de redirección. Esta es exactamente la protección que falta en los niveles CDP. Confirmado dinámicamente: la misma solicitud PoC con renderJs:false se rechaza correctamente ("error following redirect", véase la captura de pantalla de referencia).Prueba de concepto
Confirmado dinámicamente contra la propia pila docker-compose.yml --profile heavy del proyecto (crw + lightpanda + chrome, compilada desde el commit probado).
crw/chrome/lightpanda (docker network: source_default), en la dirección privada 172.19.0.6 — un contenedor nginx simple que sirve una página con contenido realista de aspecto interno (título "Internal Ops Console", un valor con forma de token de sesión).curl -s -X POST http://127.0.0.1:3000/v1/scrape -H "Content-Type: application/json" \
-d '{"url":"http://172.19.0.6/","renderJs":false}'
→ {"success":false,"error":"Invalid request: Access to 172.19.0.6 is not allowed", ...}