CVE-2023-6749 is a high severity (CVSS 8.0) stack buffer overflow in the Zephyr RTOS settings shell, where input length is never checked. The advisory lists Zephyr 3.5 and earlier as affected and shows no patched version. Disable the settings shell in production builds.
What's affected
The Zephyr GitHub advisory GHSA-757h-rw37-66hw lists affected versions as 3.5 and earlier and patched versions as none at the time of reading. Only firmware that enables the settings shell is exposed, so the first question is whether your build includes it.
Because there is no patched release listed, check the advisory and the Zephyr main branch for a later fix before you assume you are covered.
How to check if you're exposed
Look at your build configuration for the settings shell. In a Zephyr project the Kconfig symbol is CONFIG_SETTINGS_SHELL.
grep -r "CONFIG_SETTINGS_SHELL" build/zephyr/.config prj.conf boards 2>/dev/null
cat $ZEPHYR_BASE/VERSION
If the symbol is set to y, the shell is compiled in. The VERSION file at the root of the Zephyr tree shows the release you build against.
What to do now
- Turn off the settings shell and any other debug shell in production images.
- If you need the shell during development, keep those builds off networks and away from untrusted users.
- Watch the advisory for a patched release, and track the upstream fix on the main branch.
- Record which products use Zephyr 3.5 or older in your inventory so the fix can be applied when available.
- 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 advisory says the write command copies a user-supplied string into a fixed-size stack buffer sized at half the shell command buffer, and the string length can exceed that. The record tags CWE-121, stack-based buffer overflow, and CWE-787, out-of-bounds write.
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. On embedded targets there is often no address randomization or hardware memory protection, which raises the stakes of a stack overflow.
Firmware and engineering software update slowly. Start with an inventory of what you run and where it connects. Network isolation buys time while you test and schedule updates, and it is usually the first measure vendors recommend. Give each exception an owner and a review date so the workaround does not become permanent.
Weakness class in the record: CWE-121 (Stack-based Buffer Overflow) CWE-787 (Out-of-bounds Write).
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is a console shell reachable from the network?
That depends on your product. A shell on a UART needs physical access. A shell exposed over a network transport is far riskier. The advisory does not say how your device exposes it, so check your own configuration.
What if we cannot patch quickly?
Reduce who and what can reach the device. Segment the network, restrict management access to a known host, and record the exception with an owner and a review date.
Sources
Last reviewed: 19 October 2026.
