CVE-2025-11933: WolfSSL TLS 1.3 CKS Extension DoS Vulnerability

CVE-2025-11933 Overview

CVE-2025-11933 is an improper input validation vulnerability [CWE-20] in the TLS 1.3 Certificate Key Selection (CKS) extension parsing logic of wolfSSL 5.8.2 and earlier. A remote unauthenticated attacker can send a crafted ClientHello message containing duplicate CKS extensions to trigger a denial-of-service condition. The flaw affects wolfSSL deployments across multiple platforms, including Linux and macOS. The vendor addressed the issue in wolfSSL pull request #9132.

Critical Impact
A remote unauthenticated attacker can cause a denial-of-service against services using wolfSSL 5.8.2 or earlier by sending a malformed TLS 1.3 ClientHello with duplicate CKS extensions.

Affected Products

wolfSSL 5.8.2 and earlier
Linux distributions bundling vulnerable wolfSSL versions
Apple macOS deployments bundling vulnerable wolfSSL versions

Discovery Timeline

2025-11-21 - CVE-2025-11933 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-11933

Vulnerability Analysis

The vulnerability resides in the TLS 1.3 handshake parsing path in wolfSSL. The CKS (Certificate Key Selection) extension is a TLS 1.3 extension used to negotiate certificate key selection during the handshake. The parser does not correctly validate the case where a ClientHello message includes the CKS extension more than once. When this malformed input is processed, the resulting state leads to a denial-of-service condition against the wolfSSL peer.

Because the flaw is triggered during initial TLS handshake processing, exploitation does not require authentication or a completed session. Any network-reachable service that terminates TLS 1.3 with wolfSSL is a candidate target. The impact is limited to availability; confidentiality and integrity are not affected according to the CVSS vector.

Root Cause

The root cause is missing duplicate-extension validation in the CKS extension handler. TLS specifications forbid duplicate extensions in a ClientHello, but the wolfSSL parser did not enforce this constraint for CKS. This is a classic Improper Input Validation [CWE-20] issue in protocol parsing code.

Attack Vector

An attacker connects to a TLS 1.3 endpoint using wolfSSL and issues a ClientHello that includes two or more CKS extension entries. No credentials, prior session state, or user interaction are required beyond the ability to initiate a TLS handshake with the target. The fix is provided in wolfSSL Pull Request #9132, which adds validation to reject duplicate CKS extension entries during ClientHello processing.

No public proof-of-concept exploit has been released, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

Detection Methods for CVE-2025-11933

Indicators of Compromise

Unexpected termination or crash of processes linking libwolfssl following inbound TLS 1.3 connections.
Repeated ClientHello messages from the same source that immediately precede TLS service outages.
TLS 1.3 handshake records containing multiple CKS extension entries in a single ClientHello.

Detection Strategies

Inspect packet captures for TLS 1.3 ClientHello messages that contain duplicate extension type identifiers, focusing on the CKS extension.
Correlate service restarts or crash dumps of wolfSSL-based daemons with concurrent inbound TLS handshake traffic.
Inventory hosts and embedded devices linking wolfSSL 5.8.2 or earlier using software composition analysis.

Monitoring Recommendations

Enable and forward TLS termination service logs to a centralized logging platform for correlation of crash events with source IPs.
Monitor availability of TLS-terminating services with synthetic handshake probes to detect denial-of-service conditions early.
Track wolfSSL version metadata across the fleet and alert on hosts still running 5.8.2 or earlier after patch release.

How to Mitigate CVE-2025-11933

Immediate Actions Required

Identify all applications, appliances, and embedded devices that statically or dynamically link wolfSSL 5.8.2 or earlier.
Upgrade wolfSSL to a version that incorporates the fix from wolfSSL Pull Request #9132.
Restart services after upgrading to ensure the patched library is loaded into memory.

Patch Information

The vendor fix is available in the wolfSSL project via Pull Request #9132 in the wolfSSL GitHub repository. Rebuild dependent applications against the patched library and redeploy. Vendors of downstream products bundling wolfSSL should ship updated firmware or packages incorporating the fix.

Workarounds

Restrict inbound access to TLS 1.3 endpoints using network access controls where feasible until the patch is applied.
Place vulnerable services behind a TLS-terminating proxy that uses a non-wolfSSL stack and rejects malformed ClientHello messages.
Rate-limit new TLS handshakes from untrusted sources to reduce the impact of repeated denial-of-service attempts.

bash

# Example: verify the wolfSSL version linked by a binary on Linux
ldd /path/to/service | grep wolfssl
strings /usr/lib/libwolfssl.so | grep -i "wolfssl "

# Example: rebuild wolfSSL from the patched source
git clone https://github.com/wolfSSL/wolfssl.git
cd wolfssl
./autogen.sh
./configure --enable-tls13
make && sudo make install