Zephyr vulnerabilities by version: LTS, patch releases and the NVD

How many CVEs does the NVD list for my Zephyr version?

Counted are CVEs whose NVD configuration lists the version as vulnerable, queried on 23 October 2026 through the NVD API, rejected entries excluded. The NVD lists Zephyr under cpe:2.3:o:zephyrproject:zephyr; the older form with a: is superseded in the CPE dictionary and returned no hit. Two hits that concern release candidates only are excluded.

The CVSS score is the NVD's, otherwise the Zephyr CNA's. The NVD scores higher: CVE-2026-10666 (parse_ipv4) is 9.8 at the NVD and 8.1 at Zephyr.

$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:o:zephyrproject:zephyr:3.7.2&noRejected"  \
| jq .totalResults

57

$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:o:zephyrproject:zephyr:4.4.2&noRejected"  \
| jq .totalResults

26

Why does the NVD count too many CVEs for patch releases?

Zephyr fixes a vulnerability in the main branch and backports the fix into the maintained branches, in 2026 to v4.4, v4.3 and v3.7. The NVD, however, usually configures the CVE with a range up to before the next major version, for example “from 2.5.0, before 4.5.0”. Every patch release of the line is then counted, even when the fix is already in it.

Checked on CVE-2026-10634 (use-after-free in net_tcp_foreach()): the NVD lists the range up to before 4.5.0. The backport (pull request 107289, merged on 22 April 2026) is contained in 4.4.2 according to GitHub, not in 4.4.0. The NVD still counts this CVE for 4.4.2.

For 4.4.2 this holds for all 26 CVEs: for each one the project's list names a backport to v4.4, and according to GitHub each of these backports is contained in 4.4.2.

3.7.2 looks different. Of its 57 CVEs, the fix for nine is already contained in 3.7.2. For 37 it sits in the v3.7 branch but was merged only after 3.7.2; 36 of them are in the release candidate 3.7.3-rc1 of 6 August 2026. For eleven the list names no backport to 3.7.

$ gh api repos/zephyrproject-rtos/zephyr/compare/v4.4.2...168295f5a16d  \
-q .status

behind

Which four CVEs at 9.0 or higher does Zephyr 3.7.2 have?

All four concern the network stack. Two are already fixed in 3.7.2, two only in the v3.7 branch afterwards.

Which Zephyr version is in the nRF Connect SDK?

Nordic's nRF Connect SDK pulls Zephyr from its own repository sdk-zephyr, pinned in west.yml. In every version checked up to 3.3 that is a state ending in .99. According to Zephyr's release process, x.y.99 marks the main branch after work on the next minor version has started. Such a state is not a Zephyr release; the NVD count of the neighbouring version is only a starting point for it. Since nRF Connect SDK 3.4.0 a release is pinned there.

$ curl -s https://raw.githubusercontent.com/nrfconnect/sdk-nrf/v3.3.4/west.yml  \
| grep -A2 "name: zephyr$";  \
curl -s https://raw.githubusercontent.com/nrfconnect/sdk-zephyr/ncs-v3.3.4/VERSION  \
| head -3

    - name: zephyr
      repo-path: sdk-zephyr
      revision: ncs-v3.3.4
VERSION_MAJOR = 4
VERSION_MINOR = 3
PATCHLEVEL = 99

Which Zephyr CVEs does the NVD version query miss?

On 23 October 2026 the Zephyr CNA has 308 CVEs in the NVD. 124 of them have no configuration yet (status such as “Awaiting Analysis”) and count for no version. The project's own list, “Vulnerabilities” in the Zephyr documentation, names the fix and the backports per branch for each CVE.

For a Zephyr version this means: read the project's list against your line. The NVD count alone is too high for patch releases and too low for new vulnerabilities.

Which Zephyr lines get fixes?

According to the release process, LTS releases are published every 2.5 to 3 years and maintained for about five years, with general bug fixes for the first two years and then security and stability fixes only. “Support for a given LTS release (LTS N) continues until the initial release of the LTS two versions ahead (LTS N+2).” Since 2026 releases come out in April and October.

Where is the Zephyr version in my firmware?

In the source tree the version sits in the file VERSION (VERSION_MAJOR, VERSION_MINOR, PATCHLEVEL). From it the build generates include/generated/zephyr/version.h with KERNEL_VERSION_STRING and BUILD_VERSION; BUILD_VERSION is the output of git describe, so “v4.4.2” or a form with a commit hash.

In the build the version appears in the boot banner, which kernel/banner.c prints as one contiguous string: “*** Booting Zephyr OS build v4.4.2 ***”. The banner is on by default (CONFIG_BOOT_BANNER=y); a manufacturer can turn it off or change the text CONFIG_BOOT_BANNER_STRING. sys_kernel_version_get(), by contrast, returns a number that strings does not find.

$ curl -s https://raw.githubusercontent.com/zephyrproject-rtos/zephyr/v4.4.2/kernel/banner.c  \
| grep "Booting\|CONFIG_BOOT_BANNER_STRING"

	printk("*** " CONFIG_BOOT_BANNER_STRING " " BANNER_VERSION BANNER_POSTFIX " ***\n");

How do I check this by hand?

1. 1

   Read the version: strings -a zephyr.elf | grep "Booting Zephyr"; in the project from VERSION or version.h.

2. 2

   Map the line: 4.5, 4.4 and the 3.7 LTS line are maintained.

3. 3

   Query the NVD with cpe:2.3:o:zephyrproject:zephyr:<version>.

4. 4

   Read the project's “Vulnerabilities” list against your line: it names backports the NVD does not reflect and CVEs still without an NVD configuration.

5. 5

   Check the configuration: many vulnerabilities concern the network stack, Bluetooth or the HTTP server and require the subsystem to be in the build (prj.conf, .config). For the critical CVEs in 3.7.2 these are, for example, CONFIG_DNS_RESOLVER and CONFIG_HTTP_SERVER_WEBSOCKET.

6. 6

   For the nRF Connect SDK, read the Zephyr version from west.yml and from the VERSION file in sdk-zephyr.

7. 7

   Check the CISA KEV catalogue for actively exploited vulnerabilities.

Can this run automatically?

LegacyMind reads the RTOS and the linked libraries with their versions from the build and matches each against the vulnerability sources, with the place in the build where it was read. Where the binary proves no version, the field stays empty.