CVE-2021-43527 is a critical heap buffer overflow in Mozilla's Network Security Services (NSS) library that can lead to remote code execution when an application verifies a maliciously crafted DER-encoded DSA or RSA-PSS signature. Nicknamed "BigSig," it carries a CVSS 3.1 base score of 9.8 and affects NSS versions before 3.73 and before the 3.68.1 ESR release. What makes it noteworthy is not just the severity but the reach: NSS is embedded in a long list of applications, so the flaw touched far more software than most people realized at disclosure.
What NSS is and why this matters
NSS (Network Security Services) is a widely used cryptographic library that handles TLS, S/MIME, certificate handling, and signature verification. It is not an obscure component. It ships inside email clients, document viewers, and other software that needs to validate signed content. That ubiquity is exactly why a single memory-safety bug in NSS becomes a broad problem: every application that links NSS and uses it to verify signatures inherits the flaw.
The vulnerability was reported by Tavis Ormandy of Google Project Zero and disclosed in December 2021.
The technical root cause
The bug lives in how NSS handles the verification of DER-encoded signatures. When NSS processed a DSA or RSA-PSS signature, it copied signature data into a fixed-size buffer without adequately checking the size of the incoming data. A signature crafted to be larger than that buffer overflowed it on the heap.
A heap buffer overflow overwrites memory adjacent to the intended buffer. Depending on what sits there, the consequences range from a crash to, in the worst case, an attacker gaining control over program execution, which is why this one rated as remote code execution rather than a mere denial of service.
The key detail for defenders is that triggering it only requires getting the target application to verify a signature you control. That is a low bar for anything that automatically processes signed email, documents, or certificates.
What is affected and what is not
This is the part that caused the most confusion, so it is worth stating clearly.
Applications that use NSS to verify signatures in CMS, S/MIME, PKCS #7, or PKCS #12 structures were exposed. That includes email clients such as Thunderbird, document and office software such as LibreOffice, and various PDF and document viewers that relied on NSS for signature verification.
Critically, Mozilla Firefox was not affected by this particular flaw, despite NSS being a Mozilla project. Firefox does not use the vulnerable code paths in the same way, so the browser most people associate with Mozilla was not the exposure point. This is a good reminder that "the library is vulnerable" and "this product is exploitable" are different statements; the vulnerable code has to actually be reached.
Remediation
The fix is straightforward: upgrade NSS to a patched release.
- NSS 3.73 or later on the mainline branch
- NSS 3.68.1 ESR or later on the extended-support branch
Because most software does not bundle NSS directly for you to upgrade in isolation, the practical path is to update the application or operating system package that ships it. On Linux distributions this means applying the vendor's nss package update; on desktop applications it means moving to a version built against the patched library.
A representative check and update on a Debian-based system:
# Check the installed NSS version
dpkg -l | grep libnss3
# Apply the distribution's security update
sudo apt-get update && sudo apt-get install --only-upgrade libnss3
The wrinkle with a library like NSS is that it hides inside other software. You may have patched your OS packages but still run a bundled application that ships its own vulnerable copy. This is exactly the transitive-dependency problem that makes NSS flaws hard to fully eradicate.
Finding it in your environment
Because NSS is so widely embedded, the hard part is knowing everywhere it lives. A few approaches:
- Query your OS package manager for the installed NSS version on every host
- Inspect container images, which frequently bundle their own NSS
- Check desktop applications that ship their own cryptographic libraries rather than using the system copy
This is where software composition analysis pays off. An SCA tool that parses your artifacts and dependency trees can flag a vulnerable NSS version even when it arrives bundled inside another package, which manual auditing tends to miss. The same discipline applies to any deeply embedded library; the general approach is covered in our enterprise vulnerability assessment guide.
FAQ
How severe is CVE-2021-43527?
It is rated critical, with a CVSS 3.1 base score of 9.8. The high score reflects that it can be exploited over the network with low complexity, requires no privileges or user interaction beyond getting the target to process a crafted signature, and can result in remote code execution affecting confidentiality, integrity, and availability.
Which versions of NSS are affected?
NSS versions prior to 3.73, and prior to 3.68.1 on the ESR branch, are vulnerable. Upgrading to NSS 3.73 or 3.68.1 ESR (or any later release) resolves the flaw. In practice you apply this by updating the operating system or application package that ships NSS.
Was Firefox vulnerable to CVE-2021-43527?
No. Although NSS is a Mozilla project, Firefox did not use the affected code paths in the vulnerable way, so the browser was not exploitable through this flaw. The exposure was in applications that use NSS to verify DER-encoded signatures in email, documents, and similar signed content, such as Thunderbird and LibreOffice.
How do I find every place NSS is installed?
Check your OS package manager on each host, inspect container images (which often bundle their own copy), and audit desktop applications that ship their own crypto libraries. Software composition analysis automates this by scanning artifacts and dependency trees, catching bundled and transitive copies that manual checks overlook.