CVE-2025-2691 is a High severity (CVSS 8.2) server side request forgery bypass in the nossrf npm package before version 1.0.4. A hostname that resolves to a local or reserved address gets past the check. Upgrade nossrf to 1.0.4 or later.
What's affected
Affected: the npm package nossrf, versions before 1.0.4. Fixed: 1.0.4, according to the record and the Snyk entry.
The package exists to protect Node.js code from SSRF, which makes this a case where the guard itself was the weak part. If you rely on nossrf to decide whether a URL is safe to fetch, a bypass means your protection may not hold.
The Snyk page credits a researcher and notes that a proof of concept or detailed explanation exists. That is why you should not delay the upgrade.
How to check if you're exposed
Find it in your project, including as a transitive dependency:
npm ls nossrf
npm explain nossrf
For Yarn or pnpm:
yarn why nossrf
pnpm why nossrf
If any resolved version is below 1.0.4, update it. You can check lock files across many repositories at once by searching for the package name, or paste a manifest into the free in-browser dependency scan.
What to do now
- Search every Node.js repository and lock file for
nossrf. - Upgrade to 1.0.4 or later with
npm install nossrf@latestor by updating the parent package that pulls it in. - Commit the updated lock file and redeploy.
- Add a second layer: block outbound requests from the application to internal address ranges at the network level.
- Fetch remote URLs through a dedicated egress proxy that enforces an allow list.
- Re-test any feature that fetches user supplied URLs, such as webhooks, previews and image imports.
Why it matters
The record lists CWE-918. SSRF means an attacker persuades your server to make a request on their behalf, often to an internal service the attacker cannot reach directly. Typical targets include cloud metadata endpoints and admin interfaces bound to private addresses.
Filters that check a hostname before connecting can be fooled when the name resolves to a private address, because the check and the connection see different things. The record describes exactly that bypass. The CVSS vector rates confidentiality impact as high, which fits: the main danger is reading internal data. The record's KEV flag is false, so it is not in the CISA Known Exploited Vulnerabilities catalog.
The lasting fix is to enforce the rule where the connection is made, so that the resolved address is checked, and to back it up with network controls.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is a library check enough to stop SSRF?
Not on its own. Combine the library with network egress rules and an allow list, since a single check can be bypassed.
Which nossrf version should I use?
1.0.4 or later. Versions before 1.0.4 are affected.
Sources
Last reviewed: 19 October 2026.
