GHSA-h2xv-9jg2-5v55
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain network MITM/redirect position
-
ExploitPresent forged cert from compromised emSign-chained intermediate
-
ExecutionPerl client validates it against Mozilla::CA bundle
-
ImpactImpersonate TLS server and decrypt/alter traffic
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V12 - Secure Communication Certificate validation
|
| Exploitation Conditions | Three concrete conditions must hold: (1) the Perl TLS client (LWP, HTTP::Tiny, or anything via IO::Socket::SSL) must actually use the Mozilla::CA bundle rather than OpenSSL's default system CA locations - i.e. the OS store is missing (minimal containers, some Windows setups) or CA selection is overridden via configuration/environment variables such as PERL_LWP_SSL_CA_FILE; (2) the attacker must hold a man-in-the-middle position able to intercept or redirect the victim's TLS traffic; and (3) the attacker uses the publicly-available private keys of intermediates chaining to 'emSign ECC Root CA - G3' to present a forged server certificate. The primary limiting factor is that default IO::Socket::SSL behavior prefers the OS CA store, so deployments with a patched system trust store are not exposed through this code path even on an unpatched Mozilla::CA. |
| Impact | No CVSS vector, EPSS score, KEV entry, or POC flag was supplied in the input, so quantitative exploitation signals are entirely absent and must be stated as unknown rather than inferred. The advisory itself is CONFIRMED by the CPAN Security Group and the Mozilla-CA 20261020 changelog. Qualitatively this is a trust-store integrity flaw (CWE-295 Improper Certificate Validation): the shipped bundle trusts 'emSign ECC Root CA - G3', which chains to intermediates whose private keys are PUBLICLY available following the eMudhra/emSign incident. That public key material means the hardest part of a forgery attack is already done - an attacker needs no cryptographic break, only a man-in-the-middle position. However, real-world risk is tempered by two gating conditions: (1) LWP/HTTP::Tiny via IO::Socket::SSL prefer OpenSSL's default system CA locations and only fall back to Mozilla::CA when the system store is absent or overridden, so many deployments never touch the vulnerable bundle; and (2) the attacker must already be able to intercept or redirect victim traffic. Net assessment: high technical impact (full TLS server impersonation) but exploitation is conditional and positional, so this is a medium priority - prioritize Perl systems that lack an OS CA store or override CA selection, and do not treat it as a drop-everything network-wide emergency absent any EPSS/KEV evidence. |
| Exploit ScenarioDerived | An attacker on the same network path as a Perl-based client (or controlling DNS/routing) redirects the victim's HTTPS connection to an attacker-controlled endpoint and presents a server certificate signed by one of the publicly-compromised intermediates that chains to the trusted 'emSign ECC Root CA - G3'. Because the vulnerable Mozilla::CA bundle trusts that root, IO::Socket::SSL validates the forged chain and the client proceeds, letting the attacker read and modify the TLS session. No public exploit tooling for this CVE was identified, but the intermediate private keys are already publicly available, making forgery straightforward once a MITM position is obtained. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 20, 2026
TLS server authentication in Mozilla::CA (Perl) before 20261020 is undermined because the bundled CA store trusts 'emSign ECC Root CA - G3', a root whose subordinate intermediates circulate with publicly known private keys. Perl clients such as LWP and HTTP::Tiny that actually resolve their trust anchors from this bundle - typically minimal containers or Windows-style setups where OpenSSL's default system store is missing, or deployments that override CA selection through configuration or environment variables - will accept a forged certificate from an attacker who can intercept or redirect TLS traffic, allowing impersonation of arbitrary HTTPS endpoints. Assessed as CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, exposure is gated on the man-in-the-middle position and on the client genuinely using the Mozilla::CA bundle rather than the OS trust store; no KEV entry or public exploit code was identified in the available data at time of analysis, and EPSS scoring was not supplied.
RemediationAI
Vendor-released patch: Mozilla-CA 20261020 (install with 'cpanm Mozilla::CA' or via your CPAN shell), which syncs to the 2026-10-20 Mozilla repository state and removes the 'emSign ECC Root CA - G3' anchor. Upgrading alone is insufficient if the client never reads the module's bundle, so first determine which trust store the process loads: if IO::Socket::SSL is resolving to the OpenSSL or operating system store, apply the OS vendor's updates for this incident instead, since the same distrusted root must be removed there. If an immediate module upgrade is not possible, point the client at a curated CA file explicitly (for example by setting PERL_LWP_SSL_CA_FILE or the equivalent IO::Socket::SSL SSL_ca_file option to a system bundle that has already dropped emSign ECC Root CA - G3, or to a locally pruned copy of the Mozilla::CA PEM file with that root and its SHA-256 fingerprint removed) - the trade-off is that any certificate legitimately chaining to that root will then fail verification, which is the intended outcome given the leaked intermediate keys but should be communicated to application owners beforehand. Verify after any change by inspecting the loaded bundle rather than assuming defaults, and monitor bugzilla.mozilla.org/show_bug.cgi?id=2083449 plus the oss-security thread for follow-up anchors tied to the same compromise; there is no safe configuration under which the emSign ECC Root CA - G3 anchor should remain trusted, so avoid 'solutions' that simply disable certificate verification, which would expand exposure beyond this single root.
Affected ProductsAI
The affected component is the Perl distribution Mozilla-CA (module Mozilla::CA) at every version before 20261020, distributed via CPAN from the libwww-perl/Mozilla-CA repository and mirrored at metacpan.org/dist/Mozilla-CA; no CPE identifiers were supplied in the input data. Downstream, any Perl application that relies on this module's PEM bundle for TLS verification is in scope - most commonly LWP::UserAgent and HTTP::Tiny via IO::Socket::SSL where the OpenSSL system trust store is absent or where CA file selection has been overridden by configuration or environment variables. Note that the underlying certificate problem is broader than the Perl distribution: host system trust stores that have not yet removed 'emSign ECC Root CA - G3' are affected by the same compromised-intermediate event and require the operating system vendor's own updates, so users should determine which store their client actually consumes before assuming either that they are exposed or that they are fixed. Vendor and upstream advisories are at metacpan.org/release/LWP/Mozilla-CA-20261020/changes, seclists.org/oss-sec/2026/q4/268, and emudhra.we-have-a-problem.com.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Mozilla::CA is the CPAN distribution that packages Mozilla's CA certificate bundle in PEM format for Perl, kept in sync with the NSS certdata repository; it exists as a fallback so that IO::Socket::SSL and its consumers have a trust store even when no system bundle is installed. The 20261020 release, synced to the Mozilla repository snapshot of 2026-10-20, denylists the anchor 'emSign ECC Root CA - G3' (SHA-256 86a1ecba089c4a8d3bbe2734c612ba341d813e043cf9e8a862cd5c57a36bbe6b) because that root still issues a valid trust path for intermediate CA certificates whose private keys were publicly disclosed (documented at emudhra.we-have-a-problem.com and tracked in Mozilla bug 2083449). This is a CWE-295 improper certificate validation issue in the trust-anchor set rather than a parsing bug: the TLS handshake verification logic works as designed, but it anchors trust in a root that no longer provides meaningful assurance, so any certificate assembled from the leaked intermediates and their keys chains successfully. IO::Socket::SSL normally prefers OpenSSL's compiled-in default locations and only falls back to Mozilla::CA, and selection can be forced by configuration or environment variables such as PERL_LWP_SSL_CA_FILE - so exploitability depends entirely on which store the client process ends up loading.
Know when OpenSSL gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
Network attack but requires a MITM position and non-default fallback to the bundle so AC:H; no auth or UI; TLS impersonation yields high confidentiality and integrity, no availability impact.
Description PRE-NVD
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
In order to decrypt SM2 encrypted data an application is expected to call the API function EVP_PKEY_decrypt(). Rated cri
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehas
The TLS protocol 1.2 and earlier, when a DHE_EXPORT ciphersuite is enabled on a server but not on a client, does not pro
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
EUVD-2026-105771
CVE.org
EPSS
Exploit-DB