superagent npm is a mature and generally safe HTTP client, but versions before 2.0.0 carry a prototype pollution flaw and versions before 3.8.1 can leak Authorization headers on redirect, so the version you resolve is what determines your exposure. SuperAgent has been a staple HTTP client for Node.js and the browser for years, and it is a dependency of popular testing tools like SuperTest, which means it often arrives transitively. This review covers the known issues in npm superagent, how to check which version you actually have, and the request-level practices that keep an HTTP client from becoming an SSRF or data-leak vector.
What SuperAgent Is
SuperAgent is a fluent, chainable HTTP request library. You build a request by chaining methods for the URL, headers, query parameters, and body, then fire it and handle the response. It works server-side in Node.js and in the browser, supports promises and async/await, and handles common concerns like content negotiation, redirects, and multipart uploads. Its ergonomics are why it spread so widely, and why it shows up as a transitive dependency in test suites even when nobody added it directly.
Known Vulnerabilities
Three issues in SuperAgent's history are worth knowing.
The most significant is prototype pollution. Affected versions of SuperAgent are vulnerable through their extend dependency: utility functions can be tricked into modifying Object.prototype when an attacker controls part of the structure passed to them, adding or altering properties that then appear on every object in the process. The fix is to upgrade to superagent@2.0.0, which pulls in a patched extend (versions 2.0.2, 3.0.2, or higher). Prototype pollution is dangerous precisely because its effects are non-local: a polluted prototype can break unrelated code paths, bypass checks, or in the wrong application shape enable code execution.
The second is an information-exposure issue in versions before 3.8.1, where SuperAgent could forward Authorization headers to third parties on cross-origin redirects. If your request follows a redirect to a different host, credentials meant for the original destination could be sent to the redirect target. The fix is superagent@3.8.1 or later.
The third is CVE-2017-16129, a denial-of-service issue affecting versions before 3.7.0. Upgrading past these lines clears all three, and current SuperAgent is considered safe to use when kept updated.
Checking Your Version
Because SuperAgent so often arrives transitively, inspect the full tree rather than trusting package.json:
npm ls superagent
npm why superagent
If a testing library pins an old SuperAgent, you may see a version below 2.0.0 resolved deep in devDependencies. That is lower risk than a runtime dependency (test tooling is not usually processing hostile input), but it still shows up in audits and is worth resolving:
npm audit --omit=dev
npm install superagent@latest
Tracing which dependency pins an old copy is exactly the transitive-visibility problem that software composition analysis solves. A tool such as Safeguard maps the resolved graph and points at the parent that dragged in the vulnerable version, rather than leaving you to npm why your way through it manually.
Safe HTTP Requests, Beyond the Version Bump
An HTTP client is an outbound-request primitive, which makes it a natural SSRF vector when the target URL is influenced by user input. Patching SuperAgent does not address that; request hygiene does.
Do not let users control the full request URL. If a feature needs to fetch a user-supplied URL (a webhook, an avatar, a "import from URL" flow), validate it against an allowlist of schemes and hosts, resolve the hostname and block private and link-local ranges, and reject cloud metadata addresses. Otherwise an attacker points your server at internal services it should never reach.
Constrain redirects. Given the historical header-leak issue, be explicit about redirect handling. Limit the number of redirects followed, and do not carry sensitive headers across an origin change. Even on a patched version, following untrusted redirects blindly is an SSRF amplifier.
Set timeouts and size limits. A request without a timeout can hang a handler indefinitely, and a response without a size cap can exhaust memory. Configure both:
const superagent = require('superagent');
const res = await superagent
.get(validatedUrl)
.redirects(2)
.timeout({ response: 5000, deadline: 10000 })
.maxResponseSize(2 * 1024 * 1024);
Treat response bodies as untrusted. A response from an external service is attacker-influenceable if that service is attacker-controlled or compromised. Validate and type-check parsed responses before acting on them, and never pass a response value into eval, a shell, or a template without escaping.
Should You Use SuperAgent?
Yes, on a current version. It is mature, widely used, and its known issues all have long-available fixes. Keep it above 3.8.1 at minimum (and 2.0.0 clears the prototype pollution line), watch for it arriving transitively through test tooling, and wrap your requests with allowlisting, redirect limits, and timeouts. Do that and superagent npm is a dependable client rather than a liability. Many teams weigh it against the built-in fetch now available in modern Node.js; both are fine, and the security fundamentals, validate the URL, bound the request, distrust the response, apply either way.
FAQ
Which superagent versions are vulnerable?
Versions before 2.0.0 carry a prototype pollution flaw via the extend dependency, versions before 3.8.1 can leak Authorization headers on cross-origin redirects, and versions before 3.7.0 are affected by CVE-2017-16129 (denial of service). Current releases are considered safe.
Why is superagent in my dependency tree if I never installed it?
It is a dependency of popular testing tools such as SuperTest, so it commonly arrives transitively. Run npm ls superagent to find every resolved version and npm why superagent to see which package pulled it in.
Can SuperAgent cause SSRF?
Not on its own, but any HTTP client becomes an SSRF vector when user input controls the target URL. Allowlist schemes and hosts, block private and metadata IP ranges, and limit redirects to prevent it.
Is prototype pollution in superagent still a risk?
Only on versions before 2.0.0. Upgrading pulls in a patched extend dependency (2.0.2/3.0.2 or higher) that closes the issue. Verify the resolved version rather than the declared one, since it is often transitive.