Loading story…
A newly disclosed vulnerability, CVE-2026-5194, affects wolfSSL and can cause ECDSA certificate verification routines to accept digests smaller than required because hash/digest size and OID checks are missing. The flaw is classified as CWE-295 and weakens certificate-based authentication by reducing the assurance that an ECDSA signature was validated against the proper digest constraints.
The issue impacts ECDSA/ECC verification in wolfSSL configurations where EdDSA or ML-DSA is also enabled, and the risk is greater when the public CA key is known. Public references point to a wolfSSL GitHub pull request as well as MITRE and NVD tracking, while severity data published by Tenable includes CVSS v2, v3, and v4 scoring that describes a network-reachable issue with significant confidentiality and integrity impact in newer versions.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
4 events from the most recent confirmed update back to the earliest known activity.
The Canadian Centre for Cyber Security states that wolfSSL published a security advisory on June 23, 2026 addressing vulnerabilities in wolfSSL. The notice says versions prior to 5.9.2 are affected and recommends reviewing vendor guidance and upgrading to wolfSSL 5.9.2.
A new vulnerability, CVE-2026-5194, was recorded affecting wolfSSL. The flaw involves missing hash/digest size and OID checks that can let ECDSA certificate verification accept undersized digests in configurations where EdDSA or ML-DSA is also enabled, weakening certificate-based authentication when the public CA key is known.
wolfSSL released version 5.9.1 containing the fix for CVE-2026-5194, addressing improper acceptance of weak or undersized digests during signature validation. The release provided the vendor-shipped remediation after the earlier source-code fix was merged.
wolfSSL merged pull request #10131 into the master branch, adding stricter digest-size enforcement and OID agreement checks during signature generation and verification. The change was labeled for release 5.9.1 and aligns with the weakness later disclosed as CVE-2026-5194.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
9 references tracked. Mallory keeps watching after this page renders.
cyber.gc.ca
Open sourcehackread.com
Open sourcescworld.com
Open sourcecyber.gc.ca
Open sourcebleepingcomputer.com
Open sourcecvefeed.io
Open sourcetenable.com
Open sourcegithub.com
Open sourcesecurity-tracker.debian.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A public disclosure reported that **wolfSSL** versions `5.7.2` through `5.9.0-stable` contain a flaw in the **ML-DSA-44** signing path that frees a heap buffer holding private signing material without clearing it first. In native ML-DSA builds enabled with `--enable-mldsa` or `--enable-dilithium`, a same-process attacker can recover secret key material from reused heap memory and forge signatures on arbitrary messages. Researcher Abhinav Agarwal demonstrated end-to-end signature forgery on Linux and macOS, with forged signatures accepted by `wc_dilithium_verify_msg()` in compiled `libwolfssl` binaries. wolfSSL confirmed the issue and addressed it through fixes referenced in pull requests **#10100** and **#10113**, with the remediation shipping in **wolfSSL 5.9.1-stable**. The vendor did not assign a CVE and reportedly classified the finding as a bug rather than a vulnerability, even as its broader release advisory warned of multiple cryptographic verification weaknesses affecting certificate validation and signature handling. The disclosure also noted that similar missing-memory-clearing problems had previously been corrected in wolfSSL code paths for Dilithium key generation, Ed25519 signing, and Ed448 signing.
Jun 29, 2026
Two high-severity memory-corruption vulnerabilities were disclosed in widely used TLS-related software components. **CVE-2026-5264** affects wolfSSL and stems from DTLS 1.3 ACK message processing, where a remote attacker can send a crafted ACK packet to trigger a heap buffer overflow. The flaw is classified as `CWE-122` and is network-reachable with low attack complexity and no privileges or user interaction required, raising concern for applications that expose DTLS 1.3 services. A separate flaw, **CVE-2026-5402**, was disclosed in Wireshark’s TLS protocol dissector and affects versions `4.6.0` through `4.6.4`. The vulnerability is also a heap-based buffer overflow (`CWE-122`) and could allow denial of service and possible code execution when malicious traffic is processed, with the CVSS vector indicating high impact to confidentiality, integrity, and availability. Public references point to a wolfSSL GitHub pull request for the DTLS issue and to a GitLab issue and official Wireshark security advisory for the dissector flaw.
Jun 29, 2026
Go disclosed **CVE-2026-33810**, a certificate validation flaw in `crypto/x509` in Go 1.26 that can cause excluded DNS name constraints to be enforced incorrectly for wildcard Subject Alternative Names. The bug appears when a wildcard SAN such as `*.example.com` is evaluated against an excluded constraint written with different letter casing, such as `EXAMPLE.COM`, allowing the wildcard domain to bypass the exclusion during certificate chain verification. The issue affects otherwise trusted certificate chains anchored in `VerifyOptions.Roots` or the system certificate pool, narrowing exposure to chains that already terminate at a trusted root CA. Go tracked the bug as issue **#78332**, credited the report to Riyas from Saintgits College of Engineering, k1rnt, and @1seal, and later published a fix on the `release-branch.go1.26`; downstream vendors including SUSE also opened advisories for the vulnerability.
Jun 29, 2026