CVE-2024-0901 is a high severity flaw (CVSS 7.5) in wolfSSL. The fix is in pull request 7099, which adds a bounds check. This guide covers who is affected, how to check your exposure, and what to do now.
What's affected
The record lists wolfSSL without a version range. The GitHub issue reports it against wolfSSL 5.6.3, and the issue does not say whether other versions are affected.
The record gives a CVSS base score of 7.5 (High), vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:H. NVD scores this 7.5 High based on a network, no authentication, availability impact vector. The GitHub issue itself gives no score. The weakness class is CWE-129.
Per the maintainer discussion, a malformed TLS 1.3 record whose sizes were not checked during MAC verification caused an index to wrap, which led to an out-of-bounds read in the record processing code. The reporter noted the server side was reachable through the TLS 1.3 accept path.
The fix is in pull request 7099, which adds a bounds check. The issue page does not name the release that contains it, so confirm against the wolfSSL release notes.
How to check if you're exposed
Find wolfSSL in your builds. For system packages use dpkg -l | grep -i wolfssl or rpm -qa | grep -i wolfssl. For embedded builds, read the version macro in wolfssl/version.h from the source you compiled. Static linking hides it from package managers, so scan your SBOM or firmware too.
A free in-browser dependency scan at gold.safeguard.sh/scan can show whether a software package in your own projects matches this CVE, and the Gold directory entry for CVE-2024-0901 keeps the record details in one place. Reachability analysis helps you separate installations where the vulnerable code can actually be hit from those where it sits unused.
For hardware and appliances, no scanner will find them unless they are in an inventory, so start with a list of every device and application of this kind on your network.
What to do now
- Identify every instance of wolfSSL in your environment, including test and forgotten systems.
- Compare the version you found with the affected range above.
- Look for a fixed release from the vendor or project. The fix is in pull request 7099, which adds a bounds check.
- Apply mitigations while you wait: update to a wolfSSL release that includes the pull request, and rebuild anything that links wolfSSL statically.
- Review logs around the affected component for unusual requests.
- Record the decision and a re-check date in your vulnerability tracker.
Why it matters
The weakness is improper validation of an array index, CWE-129. A size or position taken from network input is used without a range check, so a malformed message makes the code read memory outside the intended buffer. The result here is a crash of the process, and in some cases a read of data that should stay private.
A TLS library sits in the path of every connection, so a bug that a remote sender can trigger without logging in is worth fixing quickly. Because wolfSSL is often compiled into firmware and other products, the real question is where it hides in your estate.
The record shows this CVE is not in the CISA Known Exploited Vulnerabilities catalog, and none of the pages used for this article report exploitation in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect every wolfSSL user?
Only builds that include the vulnerable code and expose the affected path. Confirm versions against the release notes.
Where can I confirm the fixed version?
Check the vendor or project advisory first. The fix is in pull request 7099, which adds a bounds check. This article is based on the NVD record and the pages listed under Sources.
Sources
- https://github.com/wolfSSL/wolfssl/issues/7089
- https://github.com/wolfSSL/wolfssl/pull/7099
- Safeguard Gold record for CVE-2024-0901
Last reviewed: 19 October 2026.
