[BUG] SeleniumScrapingTool has no SSRF protection — LLM-controlled URLs reach private/internal addresses (CVE-2026-112308)

Abierto
  • ¿Algo no está bien?
#9,261 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@gangjig ya está trabajando en esto.

Desde el 8/11/2026.

  • #9262 de @gangjig — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
python
Área
backend, security

Línea de trabajo

Read lib/crewai-tools/src/crewai_tools/tools/selenium_scraping_tool/selenium_scraping_tool.py and compare its URL handling with the sibling scraping tools that use validate_url from crewai_tools.security.safe_path. The issue describes validation at schema validation, fixed URL construction, and _make_request, with regression tests for private URL rejection. Done means private, loopback, link-local, and reserved addresses are rejected before browser navigation; linked PR #9262 is already open.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Description

SeleniumScrapingTool accepts any http(s) URL and navigates a local headless Chrome to it, with no private/reserved-IP validation:

  • lib/crewai-tools/src/crewai_tools/tools/selenium_scraping_tool/selenium_scraping_tool.py contains no call to validate_url (the helper in crewai_tools.security.safe_path that sibling tools already use).
  • _make_request performs only a ^https?:// regex check before self.driver.get(url).
  • When the URL is fixed at construction time, the args_schema is swapped for a Fixed schema without a website_url field, bypassing format validation as well.

This means an LLM-controlled website_url can reach loopback, RFC1918, link-local, and cloud metadata addresses (e.g. 169.254.169.254) from the host running the crew, and the fetched content is returned into the LLM's output. This is tracked as CVE-2026-112308 (CWE-918; CVSS 3.1 7.4 / 4.0 8.3). The CVE lists affected versions as crewai-tools ≤ 1.15.28, but the code on current main is still unguarded, so later versions appear affected as well.

Other scraping tools in the same package (e.g. FirecrawlScrapeWebsiteTool, ScrapflyScrapeWebsiteTool, and ScrapeWebsiteTool via safe_get) already validate URLs with validate_url before fetching — Selenium is the remaining gap in that cluster.

Prior attempt

PR #6870 (by @SashaMIT) implemented exactly this fix in August 2026, but it was auto-closed on 2026-09-17 with the needs-issue label because, as a first-time-contributor PR, it did not reference an open issue. The fix was never reviewed on its merits and the author did not return to re-file it, so I am opening this issue first, as the contributing process asks. I have a fix ready that follows the same approach (route the URL through validate_url at schema validation, fixed-URL construction, and _make_request, plus regression tests for private-URL rejection) and will open a PR referencing this issue.

Expected behavior

SeleniumScrapingTool should reject URLs that resolve to private, loopback, link-local, or otherwise reserved addresses — consistent with the other scraping tools — before any browser navigation happens.

Lenguaje dominante
Python
Estrellas
60.6k
Forks
9.1k
Merge medio
1 d 4 h
PR fusionados (30 d)
214

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de crewAIInc/crewAI

Todos los issues de crewAIInc/crewAI

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.