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

Aperta
  • Qualcosa non va?
#9,261 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@gangjig ci sta già lavorando.

Dal 8/11/2026.

  • #9262 di @gangjig — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
python
Ambito
backend, security

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
60.6k
Fork
9.1k
Merge medio
1g 2h
PR unite (30g)
214

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di crewAIInc/crewAI

Tutte le issue di crewAIInc/crewAI

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.