Loading vulnerability…
CVE-2021-3450 is a certificate chain validation flaw in OpenSSL affecting versions 1.1.1h through 1.1.1j. The issue occurs in certificate verification when an application explicitly enables the X509_V_FLAG_X509_STRICT flag, which activates additional chain validation checks. A strict check added in OpenSSL 1.1.1h to reject certificates with explicitly encoded elliptic curve parameters was implemented incorrectly, causing the result of an earlier validation step that confirmed whether a certificate in the chain was a valid CA certificate to be overwritten. As a result, a non-CA certificate could be incorrectly accepted as capable of issuing other certificates. The flaw is partially constrained by OpenSSL's purpose-based verification logic: if a verification purpose is configured, subsequent checks still validate CA status. In libssl client and server verification routines, a purpose is set by default, but applications can remove or override that default and thereby reintroduce exposure.
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.
6 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.
A high-severity OpenSSL certificate validation flaw that can bypass CA certificate checks when X509_V_FLAG_X509_STRICT is explicitly enabled and certificate verification purpose is not properly set or is overridden.
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.