CVE-2025-15346 Overview
A critical authentication bypass vulnerability has been identified in the wolfSSL Python package (wolfssl-py) that undermines mutual TLS (mTLS) client certificate enforcement. The vulnerability stems from improper handling of the verify_mode = CERT_REQUIRED configuration setting, which fails to properly enforce client certificate requirements during TLS handshakes.
The flaw occurs because the WOLFSSL_VERIFY_FAIL_IF_NO_PEER_CERT flag was not included when CERT_REQUIRED was specified, causing the behavior to effectively match CERT_OPTIONAL. This means that while a peer certificate would be verified if presented, connections were incorrectly authenticated even when no client certificate was provided at all.
Critical Impact
Attackers can bypass mutual TLS (mTLS) client authentication entirely by simply omitting a client certificate during the TLS handshake, gaining unauthorized access to systems that rely on client certificate verification for authentication.
Affected Products
- wolfssl-py (wolfSSL Python package) versions up to and including 5.8.2
- Python applications implementing mTLS using wolfssl-py with CERT_REQUIRED verification mode
- Server-side TLS implementations using wolfssl-py for client certificate authentication
Discovery Timeline
- 2026-01-08 - CVE CVE-2025-15346 published to NVD
- 2026-01-08 - Last updated in NVD database
Technical Details for CVE-2025-15346
Vulnerability Analysis
This authentication bypass vulnerability (CWE-287) affects the core TLS verification mechanism in the wolfSSL Python binding. The vulnerability is network-exploitable without requiring any authentication or user interaction, making it particularly dangerous for applications relying on mTLS for access control.
The impact of this vulnerability is severe for organizations using mTLS as their primary authentication mechanism. Mutual TLS is commonly deployed in zero-trust architectures, microservice communication, API authentication, and IoT device management scenarios. When CERT_REQUIRED doesn't function as expected, the entire security model collapses—any client can establish a "secure" connection without proving their identity.
The fix in version 5.8.4 correctly implements the verification mode by combining the _SSL_VERIFY_PEER and _SSL_VERIFY_FAIL_IF_NO_PEER_CERT flags, ensuring connections are properly rejected when no client certificate is provided.
Root Cause
The root cause lies in the constant definition for CERT_REQUIRED in the wolfssl/__init__.py file. The original implementation defined CERT_REQUIRED = 1, which corresponds only to SSL_VERIFY_PEER. For proper enforcement of mandatory client certificates, the implementation must also include the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag (value 2). Without this flag, the TLS stack verifies certificates when present but doesn't require their presence—a subtle but critical distinction that effectively downgrades security from "required" to "optional."
Attack Vector
An attacker can exploit this vulnerability through the following network-based attack:
- Identify a target server using wolfssl-py with CERT_REQUIRED verification mode for mTLS authentication
- Initiate a TLS handshake without presenting a client certificate
- The server, due to the missing WOLFSSL_VERIFY_FAIL_IF_NO_PEER_CERT flag, accepts the connection
- The attacker gains authenticated access without possessing valid client credentials
The following patch shows the security fix implemented in version 5.8.4:
PROTOCOL_DTLSv1_3, WolfSSLMethod as _WolfSSLMethod
)
-CERT_NONE = 0
-CERT_REQUIRED = 1
+_SSL_VERIFY_NONE = 0
+_SSL_VERIFY_PEER = 1
+_SSL_VERIFY_FAIL_IF_NO_PEER_CERT = 2
-_VERIFY_MODE_LIST = [CERT_NONE, CERT_REQUIRED]
+CERT_NONE = _SSL_VERIFY_NONE
+CERT_OPTIONAL = _SSL_VERIFY_PEER
+CERT_REQUIRED = (_SSL_VERIFY_PEER | _SSL_VERIFY_FAIL_IF_NO_PEER_CERT)
+
+_VERIFY_MODE_LIST = [CERT_NONE, CERT_OPTIONAL, CERT_REQUIRED]
_SSL_SUCCESS = 1
_SSL_FILETYPE_PEM = 1
Source: GitHub Commit b4517dece79f682a8f453abce5cfc0b81bae769d
The fix properly combines _SSL_VERIFY_PEER (1) with _SSL_VERIFY_FAIL_IF_NO_PEER_CERT (2) using a bitwise OR operation, resulting in CERT_REQUIRED = 3, which enforces that client certificates must be both verified and present.
Detection Methods for CVE-2025-15346
Indicators of Compromise
- TLS connections successfully authenticated without client certificates to services configured for mTLS
- Authentication logs showing access from clients that should not have valid credentials
- Unexpected connections to mTLS-protected endpoints from unknown sources
- Network traffic analysis showing TLS handshakes completing without client certificate exchange
Detection Strategies
- Audit wolfssl-py package versions in all Python applications; versions ≤5.8.2 are vulnerable
- Review TLS handshake logs for connections where verify_mode = CERT_REQUIRED was configured but no client certificate was presented
- Implement network monitoring to detect TLS connections to mTLS endpoints that lack client certificate negotiation
- Deploy SentinelOne Singularity platform to identify vulnerable package versions and monitor for authentication anomalies
Monitoring Recommendations
- Enable verbose TLS logging to capture certificate verification details during handshakes
- Monitor authentication patterns for services using wolfssl-py, flagging connections without client certificates
- Set up alerts for successful authentications to mTLS-protected services from sources without corresponding client certificate issuance records
How to Mitigate CVE-2025-15346
Immediate Actions Required
- Upgrade wolfssl-py to version 5.8.4 or later immediately
- Audit all production systems using wolfssl-py to identify affected deployments
- Review access logs for evidence of unauthorized connections to mTLS-protected services
- Consider temporarily adding additional authentication layers until patching is complete
Patch Information
The vulnerability has been addressed in wolfssl-py version 5.8.4-stable. The fix properly implements the CERT_REQUIRED constant by combining _SSL_VERIFY_PEER and _SSL_VERIFY_FAIL_IF_NO_PEER_CERT flags.
Patch Resources:
Workarounds
- If immediate patching is not possible, implement additional authentication mechanisms (API keys, session tokens) as defense-in-depth
- Deploy network-level access controls to restrict connectivity to mTLS-protected services
- Consider using alternative TLS libraries (such as Python's built-in ssl module) until patching can be completed
- Implement application-layer certificate validation as an additional check beyond the TLS library's verification
# Upgrade wolfssl-py to patched version
pip install --upgrade wolfssl>=5.8.4
# Verify installed version
pip show wolfssl | grep Version
# For projects using requirements.txt, update the version constraint
# wolfssl>=5.8.4
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
