cURL / Mailing Lists / curl-library / Single Mail


[SECURITY ADVISORY] Negotiate not treated as connection-oriented

From: Daniel Stenberg <>
Date: Wed, 22 Apr 2015 08:08:22 +0200 (CEST)

Negotiate not treated as connection-oriented

Project cURL Security Advisory, April 22nd 2015 -


libcurl keeps a pool of its last few connections around after use to
fascilitate easy, conventient and completely transparent connection re-use for

When doing HTTP requests Negotiate authenticated, the entire connnection may
become authenticated and not just the specific HTTP request which is otherwise
how HTTP works, as Negotiate can basically use NTLM under the hood. curl was
not adhering to this fact but would assume that such requests would also be
authenticated per request.

The net effect is that libcurl may end up re-using an authenticated Negotiate
connection and sending subsequent requests on it using new credentials, while
the connection remains authenticated with a previous initial credentials

We are not aware of any exploits of this flaw.


This flaw can also affect the curl command line tool if a similar operation
series is made with that.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2015-3148 to this issue.
- Affected versions: from libcurl 7.10.6 to and including 7.41.0
- Not affected versions: libcurl >= 7.42.0
libcurl is used by many applications, but not always advertised as such!
libcurl 7.42.0 closes Negotiate connections after they're done, effectively
preventing wrongful re-use. We decided to do this blunt short-term fix to
avoid this current problem and then continue to work on a better fix.
A patch for this problem is available at:
We suggest you take one of the following actions immediately, in order of
A - Upgrade to curl and libcurl 7.42.0
B - Apply the patch and rebuild libcurl
C - Avoid using Negotiate with libcurl
It was first reported to the curl project on March 31 2015. We contacted
distros_at_openwall on April 18.
libcurl 7.42.0 was released on April 22nd 2015, coordinated with the
publication of this advisory.
Reported by Isaac Boukris
Thanks a lot!
List admin:
Received on 2015-04-22