Mozilla::CA CVE-2026-113812

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.

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.

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.