Another public disclosure worth reading, not a finding of ours. In August 2025 Firecrawl published GHSA-p2wg-prhf-jx79, tracked as CVE-2025-57818: an authenticated user could point a webhook at an internal URL and have the server make the request for them.
The facts
- Identifier: CVE-2025-57818 (GHSA-p2wg-prhf-jx79).
- Severity: High, CVSS 7.4.
- Published: 26 August 2025.
- Affected: Firecrawl before 2.0.1. Patched: 2.0.1.
- Mechanism: authenticated users could configure a webhook to an internal URL and send POST requests with arbitrary headers, which may have allowed access to internal systems.
- Fix: webhook URLs are prevented from resolving to internal or private IP ranges. The vendor stated no user data was exposed.
The general case
Any feature that accepts a URL from a user and then fetches it server-side is a server-side request forgery sink. Webhooks are the most common version of that feature in modern SaaS, and they are rarely modelled as attacker-controlled input, because they are filed mentally under “integration” rather than “user input”.
They are user input. The user supplies a destination and your infrastructure makes the request, from inside your network, with your egress identity.
OWASP moved SSRF (CWE-918) under A01 Broken Access Control in the 2025 Top 10. That reclassification is the right way to think about it: an SSRF is an access control failure where the attacker borrows your server’s position on the network.
What a tester will try
- Cloud metadata endpoints, starting with 169.254.169.254, and the provider-specific variants.
- Loopback and private ranges: 127.0.0.1, ::1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, plus link-local.
- Alternate encodings of the same addresses: decimal, octal, IPv6-mapped, and hostnames that resolve to them.
- A hostname the attacker controls that resolves to a public address on first lookup and a private one on the second: DNS rebinding defeats validate-then-fetch.
- Redirects. The URL you validated returns a 302 to somewhere you would not have allowed.
- Header injection into the outbound request, which is what makes an SSRF into internal services with header-based auth so much worse than an unauthenticated fetch.
What actually holds
- Resolve the hostname, validate the resolved address against a deny-list of internal ranges, and then connect to that address. Validating a string and fetching a hostname separately is the bug.
- Do not follow redirects on user-supplied URLs, or re-validate on every hop.
- Send webhook traffic through an egress proxy with its own allow-list, so a bypass in application code does not become network access.
- Strip or fix outbound headers. The caller does not need to control them.
- Remove ambient credentials from the egress path. Metadata endpoints should not be reachable from the service that fetches user URLs.
Item 3 is the one that survives the next mistake. Everything above it is code that can regress.
