Loading vulnerability…
CVE-2021-3450 is an improper certificate-chain validation flaw in OpenSSL 1.1.1h through 1.1.1j. When X509_V_FLAG_X509_STRICT is enabled, an added check rejecting explicitly encoded elliptic-curve parameters can overwrite the result of an earlier check establishing that a certificate is a valid CA. Consequently, a non-CA certificate in a chain may be treated as able to issue subordinate certificates. Certificate-verification purposes implemented by libcrypto perform a subsequent CA check and normally prevent the bypass.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a local proof-of-concept for CVE-2021-3450-class OpenSSL certificate verification behavior. It is not a remote exploit and does not attack a network service directly; instead, it builds a malformed X.509 chain and invokes OpenSSL verification APIs to demonstrate whether a CA:FALSE certificate can improperly act as an intermediate CA. Repository structure: the core logic is in src/poc.c and src/poc_fixed.c. The original poc.c hardcodes certificate filenames in the current directory, while poc_fixed.c corrects path handling by loading certificates from ./certs/. Supporting shell scripts automate prerequisite checks, downloading and compiling OpenSSL 1.1.1h, building the PoC against either OpenSSL 1.1.1h or system OpenSSL 3.x, generating the certificate chain, and running the binary. The configs/ directory contains OpenSSL configuration files for the root and malformed intermediate certificates. Exploit capability: generate a trusted root, a mutant intermediate certificate with basicConstraints CA:FALSE but keyCertSign/cRLSign enabled, and a subleaf certificate signed by that mutant intermediate. The C program then creates an X509_STORE containing only the root, pushes the malformed intermediate into the untrusted chain, and calls X509_verify_cert() under three modes: baseline, strict+purpose, and strict without purpose. The third mode is explicitly labeled as the CVE-2021-3450 trigger path. If verification succeeds, the PoC reports that the mutant survived, meaning the invalid intermediate was accepted as a CA. Operationally, this is a self-contained local validation harness rather than a weaponized exploit. It requires local compilation and locally generated certificate files. The only external network observable is the HTTPS download of OpenSSL 1.1.1h from openssl.org during setup.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
13 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
An OpenSSL vulnerability mentioned only in related content, not part of the main article.
Unknown.
A vulnerability addressed by this advisory; no technical description is provided in the content.
Unknown
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.