CVE-2012-6153: Apache Commons HttpClient SSL Server Spoofing

Summary

17/10/2018
Yes i
High
Not published

CVE-2012-6153: Improper certificate validation in org.apache.httpcomponents:httpclient. Affects org.apache.httpcomponents:httpclient versions < 4.2.3. Fixed in 4.2.3. How to fix ↓

Also tracked for

The same CVE-2012-6153 is tracked separately for each ecosystem and vendor. Its fix information is the same; the package and affected versions differ.

Free scan

Check if this vulnerability affects your application

Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.

Check my app free

No signup required · Results in about 60 seconds

Sponsored MarkAI Find prospects already talking about the problem you solve AI watches the communities your customers use to find qualified prospects, then alerts you when a conversation is worth joining. See MarkAI

Background

Apache Commons HttpClient is a popular Java library used for sending HTTP requests and handling HTTP responses. It provides a comprehensive set of features for interacting with HTTP servers. However, versions prior to 4.2.3 are vulnerable to SSL server spoofing attacks.

Vulnerability Detail

The vulnerability (CVE-2012-6153) exists in the AbstractVerifier class of the Apache Commons HttpClient library. It occurs due to improper verification of the server hostname against the domain name in the X.509 certificate. This allows an attacker to perform a man-in-the-middle attack by presenting a certificate with a subject that specifies a common name in a field other than the CN field. The incomplete fix for CVE-2012-5783 is responsible for this vulnerability. An attacker can exploit this vulnerability to impersonate an SSL server and intercept sensitive information exchanged between the client and the server.

How To Fix

Latest published version: 4.5.14 as of 22 Oct 2026

Upgrading to it may include breaking changes; the version below is the minimum fixed release for this vulnerability.

If you need the minimum change

4.2.3

This is the first release that contains the fix.

Tip — Not sure which version your app runs? Vulert can match this fix to it. Scan free →

Workaround

If upgrading to a fixed version is not immediately possible, a workaround can be implemented by manually verifying the server's certificate during the SSL handshake. This can be done by implementing a custom X509HostnameVerifier and using it with the HttpClient library. Here's an example of a custom verifier that performs strict hostname verification:

import org.apache.http.conn.ssl.AbstractVerifier;
import javax.net.ssl.SSLException;
import java.security.cert.X509Certificate;

public class StrictHostnameVerifier extends AbstractVerifier {

    @Override
    public void verify(String host, X509Certificate cert) throws SSLException {
        super.verify(host, cert);
        String[] altNames = cert.getSubjectAlternativeNames();
        if (altNames == null || altNames.length == 0) {
            throw new SSLException("No subject alternative names found in the certificate");
        }
        boolean match = false;
        for (String altName : altNames) {
            if (host.equals(altName)) {
                match = true;
                break;
            }
        }
        if (!match) {
            throw new SSLException("Certificate subject does not match the server hostname");
        }
    }

}

To use this custom verifier, set it on the HttpClient's SSL socket factory:

import org.apache.http.conn.ssl.SSLSocketFactory;
import org.apache.http.conn.ssl.X509HostnameVerifier;

X509HostnameVerifier verifier = new StrictHostnameVerifier();
SSLSocketFactory socketFactory = new SSLSocketFactory(verifier);
HttpClient httpClient = new DefaultHttpClient();
httpClient.getConnectionManager().getSchemeRegistry().register(new Scheme("https", 443, socketFactory));

This workaround enforces strict hostname verification and mitigates the SSL server spoofing vulnerability.

Conclusion

The SSL server spoofing vulnerability in Apache Commons HttpClient (CVE-2012-6153) can be mitigated by upgrading to version 4.2.3 or later. If immediate upgrade is not possible, implementing a custom hostname verifier can serve as a temporary workaround. For further assistance and support in vulnerability remediation, please contact DevNack.com.

See every vulnerability recorded for org.apache.httpcomponents:httpclient →

Share this vulnerability

FAQ

The vulnerability allows an attacker to impersonate an SSL server and intercept sensitive information exchanged between the client and the server. This can lead to unauthorized access, data leakage, and potential compromise of user credentials.

Versions prior to 4.2.3 of Apache Commons HttpClient are affected by this vulnerability.

Yes, upgrading to version 4.2.3 or later of Apache Commons HttpClient fixes this vulnerability.

Yes, a workaround is available by implementing a custom X509HostnameVerifier that performs strict hostname verification. The details of the workaround are provided in the 'workaround' section above.

You can use Vulert's playground (https://vulert.com/scanner) to check if your application is affected by this vulnerability. Vulert monitors and alerts in real-time for open-source vulnerabilities, using just the pom.xml file of your project.

Related vulnerabilities

Recent vulnerabilities recorded for org.apache.httpcomponents:httpclient.

How To Fix

Latest published version: 4.5.14 as of 22 Oct 2026

Upgrading to it may include breaking changes; the version below is the minimum fixed release for this vulnerability.

If you need the minimum change

4.2.3

This is the first release that contains the fix.

Tip — Not sure which version your app runs? Vulert can match this fix to it. Scan free →

Subscribe to Vulert on Telegram
Daily digest of new CVEs, critical and high severity, affected packages and fixes — plus a weekly roundup.
Join the channel →
Help improve this record
Report an issue or send feedback