CVE-2026-4395: wolfSSL Buffer Overflow Vulnerability

CVE-2026-4395 Overview

A heap-based buffer overflow vulnerability exists in the KCAPI ECC code path of wc_ecc_import_x963_ex() in wolfSSL wolfcrypt. This vulnerability allows a remote attacker to write attacker-controlled data past the bounds of the pubkey_raw buffer by sending a crafted oversized EC public key point. The flaw occurs because the WOLFSSL_KCAPI_ECC code path copies input data to key->pubkey_raw (a 132-byte buffer) using XMEMCPY without performing proper bounds checking, unlike the ATECC code path which includes length validation.

Critical Impact

Remote attackers can trigger this vulnerability during TLS key exchange by sending a malicious ECPoint in ServerKeyExchange, potentially leading to memory corruption.

Affected Products

• wolfSSL wolfcrypt (versions with WOLFSSL_KCAPI_ECC enabled)
• Systems using KCAPI (Kernel Crypto API) ECC implementation in wolfSSL
• TLS servers and clients using vulnerable wolfSSL library builds

Discovery Timeline

• 2026-03-19 - CVE CVE-2026-4395 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-4395

Vulnerability Analysis

This vulnerability is classified as CWE-122 (Heap-based Buffer Overflow). The root issue lies in the inconsistent handling of input validation between different code paths within the wc_ecc_import_x963_ex() function. When the WOLFSSL_KCAPI_ECC preprocessor macro is defined, the code path that handles ECC key imports fails to validate the length of the incoming public key data before copying it into a fixed-size heap buffer.

The vulnerability can be exploited remotely over the network, requiring some user interaction. An attacker must send a crafted TLS handshake containing an oversized ECPoint structure during the key exchange phase to trigger the overflow condition.

Root Cause

The vulnerability stems from a missing bounds check in the KCAPI ECC code path. When importing an X9.63 formatted ECC public key, the WOLFSSL_KCAPI_ECC implementation directly copies the input data to key->pubkey_raw using XMEMCPY without first validating that the input length does not exceed the 132-byte buffer size. This contrasts with the ATECC code path, which properly validates the input length before performing the copy operation. The inconsistency between these two code paths represents a classic case of incomplete security hardening across parallel implementations.

Attack Vector

The attack can be conducted remotely over the network during a TLS handshake. A malicious peer (either server or client depending on the scenario) can craft a TLS ServerKeyExchange or ClientKeyExchange message containing an oversized EC public key point. When the victim processes this malformed message using wc_ecc_import_x963_ex() with the KCAPI ECC code path enabled, the oversized key data overflows the pubkey_raw heap buffer.

The attack mechanism involves crafting an ECPoint structure larger than 132 bytes. When this malformed point is processed, the XMEMCPY operation writes past the allocated buffer boundary, potentially corrupting adjacent heap metadata or application data. Depending on the heap layout and the attacker's control over the overflow data, this could lead to information disclosure, denial of service, or potentially code execution.

For technical details on the vulnerable code path and the fix, see the GitHub Pull Request.

Detection Methods for CVE-2026-4395

Indicators of Compromise

• Abnormal TLS handshake failures with wolfSSL-based applications
• Crash logs indicating heap corruption in wc_ecc_import_x963_ex() or related ECC functions
• Unexpected memory allocation patterns in processes using wolfSSL with KCAPI ECC enabled

Detection Strategies

• Monitor for TLS connections containing unusually large ECPoint values in key exchange messages
• Deploy memory corruption detection tools (AddressSanitizer, Valgrind) in development and testing environments
• Implement network-level inspection for malformed TLS handshake messages with oversized ECC parameters
• Review application crash dumps for stack traces involving wolfSSL ECC import functions

Monitoring Recommendations

• Enable heap integrity checking in production environments where feasible
• Configure intrusion detection systems to alert on anomalous TLS handshake patterns
• Monitor system logs for repeated TLS negotiation failures that could indicate exploitation attempts
• Implement application-level logging for ECC key import operations to track unusual key sizes

How to Mitigate CVE-2026-4395

Immediate Actions Required

• Update wolfSSL to the latest patched version that includes the bounds check fix
• If immediate patching is not possible, consider disabling the KCAPI ECC code path by removing the WOLFSSL_KCAPI_ECC compile-time option
• Review and audit any custom TLS implementations using wolfSSL for proper input validation
• Implement network-level filtering to block malformed TLS handshakes if possible

Patch Information

The fix for this vulnerability adds proper bounds checking to the KCAPI ECC code path before copying input data to the pubkey_raw buffer. The patch ensures that the input length is validated against the buffer size (132 bytes) before the XMEMCPY operation is performed, bringing the KCAPI implementation in line with the security measures already present in the ATECC code path. For the official fix, refer to the wolfSSL GitHub Pull Request #9988.

Workarounds

• Rebuild wolfSSL without the WOLFSSL_KCAPI_ECC preprocessor macro defined to use alternative ECC implementations
• Implement application-layer validation of incoming ECC public key sizes before passing them to wolfSSL
• Use TLS termination proxies that can filter out malformed key exchange messages
• Consider using hardware security modules (HSMs) for ECC operations as an alternative to the vulnerable code path

If you must use the KCAPI ECC code path, ensure strict network segmentation to limit exposure to untrusted peers until a patch can be applied.