CVE-2022-33987 is a serious vulnerability found in the popular Node.js HTTP request library, got, before version 12.1. (and also fixed in 11.8.5). If you are building applications that make HTTP(S) requests using got, especially if some target URLs are user-supplied or can be manipulated, you should pay attention.
In this long read, I’ll explain what this bug is, how an attacker might exploit it, why it matters, and how to patch it. You’ll see sample code and links to the main advisories, all in simple terms.
What Is the Issue?
Normally, the got library makes requests via HTTP/S — but it also supports callbacks and custom URLs, including UNIX sockets. A specially crafted redirect can trick got into connecting to a local UNIX socket instead of a remote HTTP server.
That means if your Node.js service follows redirects and the attacker can control the original URL (or some redirect), they might get got to talk to any process listening on a local socket — think of things like Docker, Redis, Postgres, or other admin sockets.
The bug relates to the way got handles HTTP redirects. It accepts URLs like
http://unix:/path/to/socket:/request/path
If a remote server, or a user, is able to provide (or force a redirect to) such a URL, got will connect to whatever UNIX socket is named in the URL.
Exploit Example: Proof of Concept
Let’s look at how a simple Node.js app can be vulnerable.
Suppose your code looks like this
const got = require("got");
async function fetchRemote(url) {
// Following redirects is the default
const res = await got(url);
return res.body;
}
// Imagine the URL comes from a user or from an untrusted location
fetchRemote("http://attacker.com/start";).then(console.log).catch(console.error);
If attacker.com/start responds with a HTTP 302 Redirect and sets the Location header to something like:
Location: http://unix:/var/run/docker.sock:/containers/json
then got will connect to docker.sock, the UNIX domain socket for Docker’s API, and call /containers/json—listing all containers! Similar access patterns exist for other UNIX sockets.
Attacker controls a URL (for example, user-supplied, or external API).
2. Got fetches that URL, receives a 302/307 redirect.
Consequences: Why Is This Even Dangerous?
- Leaking sensitive data: Docker, Postgres, or Redis may be accessible only to local clients via UNIX sockets, but now your Node.js process can be tricked into connecting.
- Remote code execution: For example, if you can talk to Docker, you can spin up containers (potentially with the file system mounted), exfiltrate data, or even run root code.
Lateral movement: Attackers could pivot to other services.
- Bypassing network rules: Even if firewalls block access to internal services, UNIX sockets bypass the network stack.
Example 1: SSRF exploitation in cloud environments
If your Node.js app is fetching metadata URLs, attackers may trick the app into connecting to /var/run/metadata.sock instead of a HTTP API.
Example 2: Docker socket compromise
Connecting to the Docker socket is nearly as dangerous as root shell access. See Why you shouldn’t expose Docker for a deep dive.
Technical Details
- The got package accepts unusual URLs of the form http://unix:/path:/request.
The fix was to refuse UNIX-socket redirects when the next location is untrusted.
Reference to the fix:
- got PR #1781
- GitHub Security Advisory GHSA-x8cm-c7g9-rj6h
Check your dependencies
npm ls got
"got": "^12.1."
}
function isUnixSocketUrl(url) {
return url.startsWith("http://unix:") || url.startsWith("https://unix:");
}
throw new Error("UNIX socket URLs are blocked");
}
Official References
- NVD – CVE-2022-33987
- GitHub Advisory
- Release notes/fix
Final Thoughts
Don’t let redirect handling be a blind spot! If your Node.js app uses got for HTTP, check your versions and update. This bug shows how attackers can blend redirect tricks with local privilege escalation — all through a simple HTTP library bug.
Patch today! And remember: prefer not to follow redirects to untrusted locations, and always restrict local socket access when possible.
*This post is original content written for you and not copied elsewhere. Share it to help your team or community stay secure!*
Timeline
Published on: 06/18/2022 21:15:00 UTC
Last modified on: 06/28/2022 16:15:00 UTC