TL;DR:
A bug in libcurl using NSS can let a hostile server trap your client in a never-ending busy loop just by asking for certificate info. It’s tracked as CVE-2022-27781. We’ll break down how the exploit works, show code, and help you stay safe.
What is libcurl’s CURLOPT_CERTINFO?
libcurl is a super popular library for making network requests. Optionally, it can tell you details about the TLS server’s SSL certificate chain using:
curl_easy_setopt(curl, CURLOPT_CERTINFO, 1L);
When this is set, libcurl collects and passes back information about all certificates in the server’s SSL chain.
The Vulnerability
In versions of libcurl built with the NSS backend, a bug in the code handling CURLOPT_CERTINFO means that a malicious server can send a weird or broken certificate that tricks libcurl into a busy-loop. Your client CPU will peg at 100% until you kill it—bad news for apps and services that trust their peers.
The key issue:
> *An unexpected certificate structure can fool nss_get_ca_chain() into looping forever.*
Here’s a C code snippet
#include <curl/curl.h>
#include <stdio.h>
int main(void) {
CURL *curl = curl_easy_init();
if(curl) {
curl_easy_setopt(curl, CURLOPT_URL, "https://malicious.example.com";);
curl_easy_setopt(curl, CURLOPT_CERTINFO, 1L); // <== THIS IS THE DANGER
CURLcode res = curl_easy_perform(curl);
if(res != CURLE_OK)
fprintf(stderr, "curl_easy_perform() failed: %s\n", curl_easy_strerror(res));
else {
struct curl_certinfo *ci = NULL;
curl_easy_getinfo(curl, CURLINFO_CERTINFO, &ci);
// Normally, you'd print cert info here...
}
curl_easy_cleanup(curl);
}
return ;
}
If the server is hostile and knows about this bug, your client will never return from curl_easy_perform().
Researchers (see references) built a test server that hands out a looping chain. The client hangs
curl --certinfo https://evil-server.example
# --> The process stalls forever, burning CPU
How to Stay Safe
- Update libcurl: Fixed in libcurl v7.83. and above. Download new releases: https://curl.se/download.html
- Check your build: This only matters if you link against NSS. Most modern Linux distros use OpenSSL or another backend, but verify with:
curl -V
# Look for 'NSS' in the features or 'libcurl/...' line
<br>- <b>Workaround:</b> Don’t use CURLOPT_CERTINFO unless you must, *especially* when connecting to unknown servers.<br>- <b>Monitor for high CPU:</b> Apps that suddenly peg a core after a curl request may be vulnerable to this.<br><br>---<br><br>## References<br><br>- NVD: CVE-2022-27781<br>- curl advisory and technical writeup<br>- GitHub commit fixing the issue<br>- Red Hat Security<br>- Debian Security Tracker<br><br>---<br><br>## Wrapping Up<br><br>While it’s not a remote code execution or info leak, CVE-2022-27781 is a perfect example of how even "safe" features can go wrong in surprising ways—and why servers must be trusted, regardless of how careful clients are. Keep your libraries patched, especially if you deal with certificates from untrusted sources.<br><br>If you have any vulnerable apps or production code using CURLOPT_CERTINFO` with NSS, patch immediately!
Timeline
Published on: 06/02/2022 14:15:00 UTC
Last modified on: 08/29/2022 01:15:00 UTC