CVE-2023-6936 is a medium severity (CVSS 5.3) heap buffer over-read of 5 bytes in wolfSSL before 5.6.6, reachable only when the debug flag WOLFSSL_CALLBACKS is enabled. Upgrade to wolfSSL 5.6.6 or later, and avoid shipping builds with that flag. Release builds should not carry that flag.
What's affected
The record says wolfSSL prior to 5.6.6 is affected when callback functions are enabled through the WOLFSSL_CALLBACKS flag. The record notes that this flag is only intended for debugging. A malicious TLS client or a network attacker can trigger a read of 5 bytes past a heap buffer.
Most production builds do not define the flag, which is why the severity is medium. The fix is in a pull request on the wolfSSL repository (#6949). The wolfSSL vulnerabilities page is the place to confirm the fixed release for your branch.
How to check if you're exposed
Search your build configuration and sources for the flag, and check the library version.
grep -rn "WOLFSSL_CALLBACKS" user_settings.h options.h configure.ac CMakeLists.txt 2>/dev/null
strings libwolfssl.so | grep -i "wolfssl [0-9]"
If the flag is never defined, the affected code is not compiled in. Embedded builds often bundle wolfSSL source in the project tree, so look there as well as at system packages.
What to do now
- Upgrade wolfSSL to 5.6.6 or later.
- Remove WOLFSSL_CALLBACKS from release builds and keep it for debugging only.
- Rebuild and redeploy any firmware or binaries that statically link wolfSSL.
- Add wolfSSL to your software inventory, since it is often vendored rather than installed.
- Run your dependency manifests and images through the free in-browser scan at gold.safeguard.sh/scan, and use reachability analysis to see whether the affected code is actually used in your build.
Why it matters
The description says the callback debugging code reads 5 bytes beyond a heap buffer. The record tags CWE-125 and CWE-126, out-of-bounds read and buffer over-read. Over-reads do not usually give code execution, but they can leak adjacent memory or crash the process.
Memory safety bugs like this one come from code that trusts a length it never verified. In C and C++ the compiler will not stop a write past the end of a buffer, so the check has to be written by hand and has to be right on every path. The bigger lesson is about build flags. A debug option left in a release build quietly widens the attack surface, and vulnerability scores rarely tell you whether your build has it on.
Base libraries reach your estate by many routes: operating system packages, container base images and statically linked builds. Update the source of each route, not only the host you checked first. Rebuild images, restart long-running processes, and verify afterward with a fresh scan.
Weakness class in the record: CWE-125 (Out-of-bounds Read) CWE-126 (Buffer Over-read).
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does reachability matter for this one?
Yes. The flaw is only present in builds with a specific flag. Knowing whether the vulnerable code is compiled in or reachable is what separates a real finding from noise.
How do I know all my images and hosts are covered?
Scan every image and host for the affected package and version. Images built before the fix keep the old library until they are rebuilt, and running processes keep it until they restart.
Sources
Last reviewed: 19 October 2026.
