CVE-2026-4395: 
wolfSSL vulnerability analysis and mitigation

CVE-2026-4395 is a heap-based buffer overflow vulnerability in the KCAPI ECC code path of wc_ecc_import_x963_ex() in wolfSSL's wolfcrypt library. It allows a remote, unauthenticated attacker to write attacker-controlled data past the bounds of the pubkey_raw buffer (132 bytes) by sending a crafted oversized EC public key point during a TLS key exchange. All wolfSSL versions prior to 5.9.0 are affected. The vulnerability was reported by Haruto Kimura (Stella), disclosed on March 19, 2026, and patched on March 17, 2026. It carries a CVSS v3.1 base score of 9.8 (Critical) (Feedly, GitHub PR #9988).

The root cause is a missing bounds check (CWE-122: Heap-based Buffer Overflow) in the WOLFSSL_KCAPI_ECC code path within wc_ecc_import_x963_ex(). When this build configuration is active, the function copies the input EC public key directly into key->pubkey_raw (a fixed 132-byte buffer) using XMEMCPY without first validating that the input length does not exceed the buffer size. By contrast, the ATECC code path in the same function does include a length validation, making the omission in the KCAPI path a clear inconsistency. An attacker can trigger this during a TLS handshake by acting as a malicious server and sending a crafted oversized ECPoint in the ServerKeyExchange message, causing a heap overflow on the connecting client (Feedly, GitHub PR #9988).

Successful exploitation can result in high impacts to confidentiality, integrity, and availability of the affected system, as reflected in the CVSS v3.1 score. An attacker who triggers the heap overflow may achieve arbitrary code execution on the client system, potentially enabling full system compromise, sensitive data exfiltration, or denial of service. The vulnerability is exploitable without authentication or user interaction, making it particularly dangerous in environments where wolfSSL is used in embedded systems, IoT devices, or network appliances that initiate TLS connections to untrusted servers (Feedly).

1. Identify target: Locate a system running wolfSSL compiled with the WOLFSSL_KCAPI_ECC build flag (versions < 5.9.0) that initiates outbound TLS connections using ECC cipher suites.
2. Set up a malicious TLS server: Configure a rogue TLS server that supports ECC-based key exchange (e.g., ECDHE) and is capable of sending a crafted ServerKeyExchange message.
3. Craft oversized ECPoint: Construct a malformed ECPoint in the ServerKeyExchange message whose length exceeds 132 bytes (the size of key->pubkey_raw).
4. Trigger the overflow: When the target client connects and processes the ServerKeyExchange, wc_ecc_import_x963_ex() calls XMEMCPY without bounds checking, writing attacker-controlled bytes past the end of the pubkey_raw heap buffer.
5. Achieve code execution or crash: Depending on heap layout and target platform, the overflow may corrupt adjacent heap metadata or function pointers, potentially enabling arbitrary code execution or causing a denial of service (Feedly, GitHub PR #9988).

• Network: Unexpected or anomalous TLS handshake failures originating from connections to untrusted or external servers; TLS sessions using ECC cipher suites that terminate abnormally during the key exchange phase.
• Process: Crashes or unexpected termination of processes using wolfSSL (e.g., segmentation faults or heap corruption errors in application logs); core dump files generated by wolfSSL-linked applications.
• Logs: Application-level error logs showing wolfcrypt ECC import failures or memory corruption signals (SIGABRT, SIGSEGV) during TLS handshake processing.
• File System: Unexpected core dump files (core.*) in application working directories following TLS connection attempts to external hosts.

wolfSSL has addressed this vulnerability in version 5.9.0 and the fix was merged into the master branch on March 17, 2026 (targeted for release 5.9.2). The fix adds a bounds check in wolfcrypt/src/ecc.c to validate the input public key length before copying it into key->pubkey_raw for the WOLFSSL_KCAPI_ECC code path. Organizations should upgrade to wolfSSL 5.9.0 or later as the primary remediation. As a temporary workaround, deployments can recompile wolfSSL without the WOLFSSL_KCAPI_ECC build flag if KCAPI ECC support is not required (GitHub PR #9988, Feedly).

The vulnerability was credited to Haruto Kimura (Stella) for responsible disclosure to wolfSSL. The fix was reviewed and approved by wolfSSL maintainer JacobBarthelmeh and merged promptly. Tenable published a Nessus detection plugin (ID 303174) for the vulnerability, and FreeBSD's FreshPorts tracked the wolfSSL package update. Community discussion was limited, consistent with the niche deployment requirement (WOLFSSL_KCAPI_ECC) that constrains the affected population (Feedly, Tenable).