curl is one of the world's most trusted command-line tools for sending data with URLs. But in early 2022, a subtle bug made it possible for information to sneak between connections—under the right (but not so rare) conditions—on any system using curl from version 7.65. up to and including 7.82.. This is tracked as CVE-2022-27775.
Let's break down what happened, look at a code example, and see how attackers could have exploited this vulnerability.
What Actually Happened?
Most modern systems support IPv6 addresses, and with them comes a rarely-discussed feature: zone IDs (also known as *scope IDs*). When you connect to an IPv6 address like fe80::1%eth, the %eth part refers to your system's *network interface*.
curl maintains a pool of connections, known as *connection reuse*. This way, if it needs to send multiple requests to the same server, it can save resources by reusing an existing TCP connection.
Problem: Older versions of curl ignored the zone ID when checking if a connection already existed to a specific IPv6 address.
- So, fe80::1%eth and fe80::1%eth1 were treated as the *same* destination, even though they're different network interfaces.
- If different users, applications, or requests used connections with the same base address but different zone IDs, curl could *incorrectly* reuse a connection and send/receive sensitive data from the wrong context.
Patched: 7.83.
Full advisory: curl security advisory 2022-05-11
Exploit Scenario
Suppose you have two users on the same multiuser system, or two VM/container environments using IPv6 link-local addresses with different zone IDs. Both use curl to connect to the *same IPv6 address* (like fe80::1), but through *different interfaces*.
An attacker could setup a service at that address on both interfaces. If curl gets confused and reuses a connection meant for %eth when making a request via %eth1, information belonging to one user or context could be exposed to the other.
Simple Exploit Steps
1. User A connects to http://[fe80::1%eth]/secret1
2. Attacker's process connects to http://[fe80::1%eth1]/secret2
3. Both curl requests may swap/share a connection due to the bug
4. Data from User A’s request (cookies, authentication, even content) can cross over to the attacker's network interface
Code Snippet: Proof of Concept
Here’s a minimal C program using libcurl showing how two requests across different zone IDs could “share” a connection.
#include <stdio.h>
#include <curl/curl.h>
int main(void) {
CURL *curl1, *curl2;
CURLcode res;
curl_global_init(CURL_GLOBAL_DEFAULT);
curl1 = curl_easy_init();
curl2 = curl_easy_init();
if (curl1 && curl2) {
// First, connect to IPv6 address on eth
curl_easy_setopt(curl1, CURLOPT_URL, "http://[fe80::1%eth]/userA/";);
res = curl_easy_perform(curl1);
// Now, connect to same base address but on eth1
curl_easy_setopt(curl2, CURLOPT_URL, "http://[fe80::1%eth1]/userB/";);
res = curl_easy_perform(curl2);
curl_easy_cleanup(curl1);
curl_easy_cleanup(curl2);
}
curl_global_cleanup();
return ;
}
On a vulnerable system, both requests may reuse a single connection even though they were meant for different network zones/interfaces. This could lead to leaking cookies, auth tokens, POST data, or other sensitive headers. (Server setup for this scenario is left as an exercise.)
Real-World Impact
- Multi-user systems: Sensitive session cookies or credentials could be visible between users behind the scenes.
The Fix
The official patch updated the connection pool logic to remember the *zone ID* as part of the destination address. Now, fe80::1%eth and fe80::1%eth1 are treated as completely different.
Official
- curl Security Advisory
- GitHub Patch
- NVD CVE Entry
Background
- IPv6 Zone IDs Explained (Red Hat)
- Connection reuse in curl docs
Summary
CVE-2022-27775 shows that even little changes in how IP addresses are written—like a zone ID for an interface—can cause big privacy problems. The bug in curl’s connection pooling allowed data to leak across users or interfaces. Patching is easy and protects you from this sneaky attack.
Timeline
Published on: 06/02/2022 14:15:00 UTC
Last modified on: 08/02/2022 03:15:00 UTC