Several versions of curl and the curl library contain a pair of serious security flaws, one of which can enable an attacker to bypass authentication by reusing an OAuth2 bearer.
That vulnerability (CVE-2022-22576) was introduced nearly 10 years ago and it affects versions 7.33.0 through 7.82.0 and has been fixed in version 7.83.0. Because of the way that libcurl handles connections, it’s possible that it might reuse a connection for one user that has been authenticated with an OAuth2 bearer token for a separate user.
“Libcurl maintains a pool of live connections after a transfer has completed (sometimes called the connection cache). This pool of connections is then gone through when a new transfer is requested and if there is a live connection available that can be reused, it is preferred instead of creating a new one,” the advisory for the vulnerability says.
“Due to this security vulnerability, a connection that is successfully created and authenticated with a user name + OAUTH2 bearer could subsequently be erroneously reused even for user + (other OAUTH2 bearer), even though that might not even be a valid bearer. This could lead to an authentication bypass, either by mistake or by a malicious actor.”
The second vulnerability, a credential leak, was introduced in version 4.9 of curl, which was released in 1998. The bug (CVE-2022-27774) also affects every version of libcurl, the curl library, and is patched in version 7.83.0.
“Curl follows HTTP(S) redirects when asked to. curl also supports authentication. When a user and password are provided for a URL with a given hostname, curl makes an effort to not pass on those credentials to other hosts in redirects unless given permission with a special option,” the advisory says.
“This "same host check" has been flawed all since it was introduced. It does not work on cross protocol redirects and it does not consider different port numbers to be separate hosts. This leads to curl leaking credentials to other servers when it follows redirects from auth protected HTTP(S) URLs to other protocols and port numbers. It could also leak the TLS SRP credentials this way.”
Neither of these two vulnerabilities is known to have been exploited in the wild.