Embedded TCP/IP stack vulnerabilities in RTOS firmware: identify, triage, patch

They showed the same failure three times, in different code bases. CERT/CC's VU#257161 note on Ripple20, released 2020-06-16, says the Treck IP stack "contains multiple vulnerabilities, most of which are caused by memory management bugs", that a remote, unauthenticated attacker "may be able to use specially-crafted network packets to cause a denial of service, disclose information, or execute arbitrary code", and that the historically related KASAGO middleware from Zuken Elmic was also affected by some of them. Its example detection rule targets CVE-2020-11896 and CVE-2020-11900 through fragments inside an IP-in-IP tunnel, which is typical: the bugs sit in rarely used corners of IP, not in application code.

Six months later, CERT/CC's VU#815128 note on AMNESIA:33, released 2020-12-08, listed 33 memory-related vulnerabilities across uIP, Contiki-OS and Contiki-NG, picoTCP, FNET and Nut/OS, and named the inheritance problem directly: projects such as Apache NuttX and open-iscsi "have adopted common libraries and software modules, thus inheriting some of these vulnerabilities". Forescout's AMNESIA:33 research page counts four critical vulnerabilities and more than 150 affected vendors.

In 2021 Forescout and JSOF published NAME:WRECK, nine DNS-related vulnerabilities in four stacks: FreeBSD, Nucleus NET, NetX and IPnet. DNS is the common thread across all three sets, because a device's DNS client parses attacker-influenced responses with hand-written code. That is the same class of bug our dnsmasq vulnerabilities guide covers on embedded Linux, where the parser sits in a separate daemon rather than inside the RTOS image.

A fourth set, INFRA:HALT, followed the same pattern in HCC Embedded's NicheStack. CERT/CC's VU#608209 note says 5 of its 14 vulnerabilities involve TCP and ICMP processing and the rest involve HTTP and DNS, and adds that "a lack of Software Bill of Materials (SBOM) has complicated this outreach and the much-needed identification of impacted devices".

Start from the build tree, because it is the only place the answer is exact. A device maker usually has the MCU vendor SDK, the RTOS configuration and the linker map, and those name the stack and its version: lwIP's version macros sit in lwip/init.h, a Zephyr tree has a VERSION file and a west manifest, and a FreeRTOS project pulls FreeRTOS+TCP in as a named library. Write that component and version into the firmware SBOM at build time, because recovering it later from a stripped binary is slow and uncertain.

When only the image is available, look for stack-specific strings and symbols, accepting that each clue is weaker on its own:

The commercial rows are the hard case. CERT/CC's Ripple20 note says Treck code was licensed "compiled from source, licensed for modification and reuse and finally as a dynamic or static linked library", so the stack name may never appear in the image. Ask the module or SDK supplier for a written statement of which stack and version they ship. Forescout released an open-source detector alongside AMNESIA:33, which CERT/CC mentions in VU#815128, and it is a reasonable first pass on network captures, but a negative result is not proof of absence.

Each stack has its own channel, and none of them push a fix into a shipped device for you.

• lwIP. The lwIP Savannah project describes lwIP as "a small independent implementation of the TCP/IP protocol suite that has been initially developed by Adam Dunkels", aimed at systems "with tens of kilobytes of free RAM and room for around 40 kilobytes of code ROM", under a Modified BSD licence. Its bug tracker, patch tracker, Git repository and release downloads all live there. Many MCU SDKs vendor a copy of lwIP, so check whether your SDK supplier has pulled in an upstream fix before you assume your build has it.
• FreeRTOS+TCP. The repository's GitHub Security Advisories list each fixed issue; recent ones cover the DNS resolver (GHSA-h4fw-pv82-p7h5, published 2026-10-16), IPv6 Router Advertisement parsing, DHCPv6 sub-options and ICMP echo replies. The security policy asks reporters to contact AWS Security and not to open public issues.
• Zephyr. Zephyr's Vulnerabilities page lists every CVE with the pull requests that fixed it on main and on supported branches, and notes that the page "can be updated after the embargo is lifted", unlike version-locked release notes. One 2026 entry, CVE-2026-1678, is a memory-safety bug in the DNS name parser dns_unpack_name(), where a malicious DNS response can cause an out-of-bounds write when CONFIG_DNS_RESOLVER is enabled. The Zephyr Security Overview says vulnerabilities are "managed within Github security advisories".
• uIP, Contiki, picoTCP, FNET, Nut/OS. CERT/CC's VU#815128 links each upstream project and carries per-vendor statements. Some are final: one vendor statement in that note says patches "won't be provided since the affected product is end-of-life" for a product built on uIP 1.0.
• Treck. CERT/CC's VU#257161 says to update "to the latest stable version of Treck IP stack software (6.0.1.67 or later)" and to contact Treck; downstream users should contact their embedded system vendor.

SoftWSP's scan works from the firmware's software bill of materials. When the SBOM lists a network stack component and version, the scan matches that version against CVE records, CISA's KEV catalog and FIRST's EPSS scores. That matching is deterministic code: the code scores, and AI narrates.

AI then writes the plain-language summary of which stack CVEs matched, which are KEV-listed or have high EPSS, and what version evidence each match rests on, citing the component, version and record behind every sentence. An engineer reviews every finding before the report is delivered. The steps this guide describes as manual stay with that engineer: identifying a stack compiled into a monolithic RTOS image that has no package record, getting a supplier statement for a rebranded commercial stack, and deciding whether a feature-gated CVE applies. Because matching is version-based, a build with the DNS resolver compiled out is still flagged for a DNS advisory until that review closes it.

For where this fits in a full assessment, see the OWASP Firmware Security Testing Methodology guide, or device & firmware security services to have a specific image reviewed.

This guide draws on CERT/CC vulnerability notes VU#257161, VU#815128 and VU#608209, Forescout's AMNESIA:33 and NAME:WRECK research pages, the lwIP Savannah project page, the FreeRTOS-Plus-TCP security advisories and policy, and Zephyr's Vulnerabilities and Security Overview pages, all read directly on 2026-11-12.