CVE-2014-2522

Published Apr 18, 2014

Last updated 18 days ago

CVSS info 4.0

Overview

Description
curl and libcurl 7.27.0 through 7.35.0, when running on Windows and using the SChannel/Winssl TLS backend, does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate when accessing a URL that uses a numerical IP address, which allows man-in-the-middle attackers to spoof servers via an arbitrary valid certificate.
Source
cve@mitre.org
NVD status
Modified
Products
curl, libcurl

Risk scores

CVSS 2.0

Type
Primary
Base score
4
Impact score
4.9
Exploitability score
4.9
Vector string
AV:N/AC:H/Au:N/C:P/I:P/A:N

Weaknesses

nvd@nist.gov
CWE-20

Social media

Hype score
Not currently trending

Configurations

Related CVEs

  1. Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` header field meant for `proxyA`, to `proxyB`.•CVE-2026-7168
  2. When curl is told to use the Certificate Status Request TLS extension, often referred to as *OCSP stapling*, to verify that the server certificate is valid, it fails to detect OCSP problems and instead wrongly consider the response as fine.•CVE-2026-7009
  3. When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.•CVE-2026-6429
  4. Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.•CVE-2026-6276
  5. curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy•CVE-2026-6253

References

Sources include official advisories and independent security research.