CVE-2025-15346: 
Python vulnerability analysis and mitigation

CVE-2025-15346 is an improper authentication vulnerability in the wolfssl Python package (wolfssl-py) that allows attackers to bypass mutual TLS (mTLS) client authentication by omitting a client certificate during the TLS handshake. The flaw affects all versions up to and including 5.8.2, with the patched version being 5.8.4.post0 (tagged as v5.8.4-stable). It was disclosed on January 8, 2026, and credited to Matan Radomski from Microsoft. The vulnerability carries a CVSS v4.0 base score of 9.3 (Critical) (GitHub Advisory).

The root cause is a missing WOLFSSL_VERIFY_FAIL_IF_NO_PEER_CERT flag in the implementation of verify_mode = CERT_REQUIRED within wolfssl/__init__.py (CWE-287: Improper Authentication; CWE-306: Missing Authentication for Critical Function). In the vulnerable code, CERT_REQUIRED was defined as 1 (equivalent to SSL_VERIFY_PEER only), meaning the library would verify a client certificate if one was presented but would not reject connections where no certificate was provided at all — effectively behaving as CERT_OPTIONAL. The fix redefines CERT_REQUIRED as _SSL_VERIFY_PEER | _SSL_VERIFY_FAIL_IF_NO_PEER_CERT (value 3), ensuring connections without a client certificate are rejected. The patch was merged on December 17, 2025, and is publicly visible in commit b4517de (wolfssl-py commit, wolfssl-py PR #62).

Successful exploitation allows an unauthenticated remote attacker to establish TLS connections to services that rely on mTLS for client identity verification, completely bypassing the intended authentication control. This compromises both confidentiality (unauthorized access to protected data or APIs) and integrity (ability to perform unauthorized actions as an unauthenticated client). Any Python application using wolfssl-py with verify_mode = CERT_REQUIRED to enforce client certificate authentication is affected, potentially enabling unauthorized access, data exfiltration, or lateral movement within environments that trust mTLS-authenticated connections (GitHub Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been observed as of the time of disclosure (GitHub Advisory). The vulnerability is trivially exploitable — an attacker simply omits the client certificate during the TLS handshake, requiring no special tools or privileges. The EPSS score is approximately 0.057% (21st percentile), indicating a currently low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The attack is automatable and requires no user interaction, which elevates its risk profile for internet-exposed services.

1. Identify target services: Locate Python-based services using wolfssl-py ≤5.8.2 with verify_mode = CERT_REQUIRED configured for mTLS client authentication. This can be done through source code review, dependency scanning (e.g., checking pip list or requirements.txt), or network fingerprinting.
2. Initiate TLS handshake without a client certificate: Connect to the target service using any standard TLS client (e.g., openssl s_client, Python's ssl module, or curl) without providing a client certificate or key.
3. Complete the handshake: Because the WOLFSSL_VERIFY_FAIL_IF_NO_PEER_CERT flag is absent, the server running the vulnerable wolfssl-py library will not reject the connection despite the absence of a client certificate.
4. Access protected resources: With the TLS session established, interact with the service as if authenticated, accessing APIs, data, or functionality that should have been restricted to certificate-holding clients (wolfssl-py PR #62, GitHub Advisory).

• Network: TLS connections to mTLS-protected services that complete successfully without presenting a client certificate; absence of client certificate fields in TLS handshake logs where they are expected.
• Logs: Server-side TLS/application logs showing successful authenticated sessions from clients that did not supply a certificate; unexpected access to restricted endpoints from IP addresses not associated with known certificate holders.
• Application: Audit logs showing authorized actions performed by sessions lacking a client certificate distinguished name (DN) or subject; anomalous access patterns to services configured with CERT_REQUIRED in wolfssl-py.

Upgrade the wolfssl pip package to version 5.8.4.post0 or later (released as v5.8.4-stable), which correctly defines CERT_REQUIRED as SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT (wolfssl-py release). For systems that cannot be patched immediately, implement compensating controls such as network-level access restrictions (firewall rules, VPN requirements) to limit who can reach mTLS-protected services, and add application-layer authentication checks independent of the TLS layer. Audit all services using wolfssl-py with verify_mode = CERT_REQUIRED to assess exposure and review access logs for signs of unauthenticated connections.

The vulnerability was reported by Matan Radomski from Microsoft and acknowledged by the wolfSSL team, who merged the fix on December 17, 2025, and released the patched version on December 30, 2025 (wolfssl-py release). Community discussion was noted on Mastodon (infosec.exchange) and Bluesky shortly after the CVE was published in January 2026, with general awareness of the mTLS bypass risk. No major media coverage or significant vendor statements beyond the GitHub advisory and release notes have been identified.