Ripple20

Executive Summary

Ripple20 is the name given by Israeli research firm JSOF to a cluster of 19 vulnerabilities discovered in the Treck TCP/IP stack, an embedded networking library that had been quietly integrated into hundreds of millions — possibly billions — of devices over more than two decades. The disclosure on June 16, 2020 mattered not because of any single bug, but because of the supply-chain mechanics underneath: a small commercial library, sold as source code since the late 1990s, had been embedded by manufacturers across virtually every industry vertical that ships networked hardware.

The four most severe vulnerabilities — CVE-2020-11896, CVE-2020-11897, CVE-2020-11898, and CVE-2020-11901 — carried CVSS scores at or above 9.0 and enabled remote code execution. Affected industries included medical (infusion pumps, patient monitors), industrial control (PLCs, RTUs, UPS systems), enterprise (printers, IP cameras), aviation, oil and gas, transportation, and telecommunications. Some vulnerable devices had been deployed for over a decade with no plausible patch path.

Operationally, Ripple20 reframed the embedded supply-chain problem in concrete terms. The vulnerable code was rarely chosen by the device manufacturer directly; it often arrived through a chip vendor, a network module supplier, or an OEM that itself acquired the library years earlier. For defenders, this turned a technically straightforward "patch the stack" problem into a multi-month forensic exercise of tracing component lineage across opaque vendor chains.

Why This Belongs in the Archive

Ripple20 belongs in the archive because it crystallized the embedded supply-chain risk class. Earlier embedded vulnerabilities tended to be isolated to one product family. Ripple20 demonstrated that a single low-level library, written before most of its eventual users were even founded, could become a multi-vendor, multi-vertical incident that defied conventional asset inventory and patch management.

It exposed systemic infrastructure dependency on third-party embedded code that organizations did not know they were running.

It demonstrated supply-chain blast radius extending across enterprise, medical, industrial, and energy sectors simultaneously.

It required large-scale remediation that most affected organizations could not fully complete, because they could not even confirm whether they were affected.

It informed later embedded-device incident response practices, including the push toward Software Bill of Materials (SBOM) as a procurement requirement.

Key Facts

Background

The Treck TCP/IP stack was a commercial networking library originally developed in the 1990s. It was designed to run on resource-constrained embedded devices — microcontrollers, industrial modules, IoT devices — where full-featured operating system stacks were too heavy. Treck sold the code as source, allowing licensees to integrate only the protocol layers they needed and to modify the code freely for their products.

A historical complication compounded the problem: a partnership between Treck and the Japanese company Elmic Systems (now Zuken Elmic) in the 1990s resulted in two parallel branches of the stack, marketed independently in North American and Asian markets respectively. The Treck stack appeared in the wild under multiple names — Kasago, ELMIC, Net+ OS, Quadnet, GHNET v2, Kwiknet, AMX — making provenance tracking essentially impossible without source-level analysis.

By 2019, when JSOF researchers Moshe Kol and Shlomi Oberman began part-time research into the library, the code had been in the field for over twenty years. Vendors had been acquired, merged, or had ceased operations. Components had been resold, repackaged, and embedded into still-other components. The library had become invisible.

What Happened

The June 16, 2020 disclosure landed across the security community with unusual scope. JSOF published 19 CVEs (CVE-2020-11896 through CVE-2020-11914) along with technical detail on the four critical vulnerabilities and a coordinated set of vendor advisories.

Defenders immediately ran into the structural problem that defined Ripple20: there was no reliable way to identify affected devices from their own management interfaces. Traditional vulnerability scanners could detect Treck stack signatures via network behavior, but only when devices were online and reachable. Embedded medical devices, industrial sensors, and shipboard equipment frequently were not.

Affected vendors began publishing advisories on a rolling basis through the summer and fall of 2020. Some vendors confirmed affected products and issued firmware updates within weeks. Others took months to determine whether their products embedded the stack at all, because the integration decision had been made years earlier by a now-defunct subsidiary or a third-party module supplier. A non-trivial number of devices were determined to be vulnerable but unpatchable, either because the manufacturer no longer existed or because the device firmware architecture did not support updates.

What distinguished Ripple20 from prior CVE clusters was the reach of the dependency. JSOF's verified vendor list crossed boundaries that defenders rarely had to consider simultaneously: a single advisory cycle was relevant to hospital biomedical engineering teams, electric utility OT staff, enterprise printer admins, and aviation maintenance organizations.

Technical Overview

The 19 vulnerabilities spanned multiple layers of the Treck stack. The four critical ones illustrate the surface area:

CVE-2020-11896 (CVSS 10.0): Improper handling of length parameter inconsistency in IPv4/UDP when processing a packet sent by an unauthorized network attacker. Allowed remote code execution.

CVE-2020-11897 (CVSS 10.0): Improper handling of length parameter inconsistency in IPv6 component. Allowed possible out-of-bounds write.

CVE-2020-11898 (CVSS 9.1): Improper handling of length parameter inconsistency in IPv4/ICMPv4 component. Allowed out-of-bounds read with potential information disclosure.

CVE-2020-11901 (CVSS 9.0): Improper input validation in the DNS resolver component. Allowed remote code execution via crafted DNS responses, including across NAT boundaries — the most operationally dangerous flaw because it could potentially reach devices not directly internet-exposed.

The remaining 15 CVEs covered DHCP, ARP, IPv6 tunneling, IPv4-in-IPv4 tunneling, and other protocol handlers, with severities ranging from CVSS 3.1 to 8.2 (DoS, RCE, or information disclosure).

The supply-chain property is the more important technical point. Because Treck shipped as source code and licensees were free to modify it, the same CVE could manifest differently across vendors. Some vendors had stripped down the stack to only the protocols they used, accidentally avoiding certain CVEs. Others had backported features, accidentally introducing vulnerabilities into branches that were otherwise patched. Treck issued a single fixed version (6.0.1.66, March 2020), but downstream vendors had to integrate that fix into their own firmware build trees — a process that could take months.

Affected Vendors and Devices

JSOF and CISA confirmed affected products from the following vendors. This list is not exhaustive; a complete accounting was never produced because the supply chain extended beyond what could be traced.

Confirmed Affected Vendors (selected)

Device Categories Affected

Across the confirmed and suspected vendor list, affected device categories included:

• Network printers and multifunction devices
• IP cameras and video surveillance equipment
• Uninterruptible Power Supplies (UPS) and power management cards
• Programmable Logic Controllers (PLCs) and Remote Terminal Units (RTUs)
• Building automation and HVAC controllers
• Medical infusion pumps and patient monitors
• Industrial sensors and gateways
• Network switches and access points
• Embedded modules used inside other products (the most difficult category, since the end-customer often did not know the module was present)

Vendors Reporting Not Affected

Several vendors investigated and reported their products were not affected, either because they did not embed Treck or because their integration excluded the vulnerable components. Cisco's industrial IoT solutions, Dell servers (per Dell's investigation), and a number of other major vendors fell into this category. The "not affected" determinations were as operationally important as the affected lists, because they let defenders narrow the search.

Impact

Operational Impact

The dominant operational cost of Ripple20 was inventory burden. Most affected organizations had no SBOM, no embedded-component register, and no straightforward way to enumerate which devices in their environment ran the Treck stack. Help-desk and engineering teams spent weeks on vendor outreach, advisory cross-referencing, and ad-hoc network scanning.

For environments with biomedical, industrial, or aviation devices, the burden was amplified by the regulatory overhead of changing firmware on devices that had been certified at a specific software baseline. In some sectors, applying a vendor-supplied patch required re-validation work that took longer than the original disclosure window allowed.

Security Impact

Where vulnerable devices were network-reachable, the most severe risk was remote code execution from malformed packets — typically without authentication. The DNS path (CVE-2020-11901) extended this risk to devices behind NAT or firewalls, because a single malicious DNS response could potentially traverse the perimeter.

Many of the affected device classes — medical equipment, industrial controllers, UPS management cards — sat on operational networks where lateral movement consequences were severe. A compromised infusion pump or PLC was not just a compromised endpoint; it was a foothold inside a network segment that often had limited monitoring and weak segmentation.

Business / Continuity Impact

For larger organizations with diverse device fleets, the response cost ran into hundreds of hours of engineering time. Replacement was frequently the only viable remediation for devices the original vendor would not or could not patch, creating capital expenditure exposure that had not been budgeted.

Procurement and vendor-risk processes were forced to address the question that Ripple20 made unavoidable: "What third-party libraries are inside the products you sold us?" Many vendors could not answer.

What This Was Not

Ripple20 was not an active attack campaign. There was no known in-the-wild exploitation tied to a specific actor at the time of disclosure.

It was not a single-vendor compromise. The root cause was an upstream library that many vendors had embedded independently.

It was not a Windows, Linux, or macOS vulnerability. The Treck stack ran inside firmware on embedded devices, not on general-purpose operating systems.

It was not fully remediable in many environments. Some affected devices had no vendor support, no firmware update path, and no functional replacement available within reasonable time.

It was not unprecedented. Earlier disclosures, notably Urgent/11 (2019, affecting the Wind River VxWorks IPnet stack — itself originally derived from Interpeak), had foreshadowed the pattern. Ripple20 was the largest example of the class to date, not the first.

Evidence and Source Notes

Evidence is organized by proximity to the event. Primary disclosure and government advisories are treated as highest-confidence sources for vulnerability detail and scope. Vendor-specific advisories are treated as authoritative for affected-product determinations. Industry analyst reporting is used to support operational context and detection-difficulty framing.

Remediation

Immediate Actions: 0–24 Hours

• Identify any devices known to embed the Treck TCP/IP stack from published vendor advisories.
• Apply available vendor firmware updates where the device supports them and operational risk allows.
• Isolate or restrict network access for high-risk devices that cannot be quickly validated, prioritizing internet-reachable devices first.
• Pull JSOF's vendor list and CISA's ICSA-20-168-01 advisory and cross-reference against the asset inventory.

Short-Term Actions: 1–7 Days

• Build an embedded asset inventory covering printers, IP cameras, UPS management cards, PLCs, RTUs, medical devices, and any networked appliances with vendor firmware.
• Contact each vendor in the inventory whose status is unclear and obtain a written affected/not-affected determination.
• Document any unsupported or unpatchable devices and assign compensating controls (segmentation, ACLs, monitoring).
• Where firmware updates are available but cannot be immediately deployed, deploy network-level mitigations: deep packet inspection, malformed packet drops, DHCP/DNS scrutiny, and IP fragment blocking on perimeter devices.

Medium-Term Actions: 1–4 Weeks

• Add component-provenance tracking — at minimum, request a Software Bill of Materials (SBOM) from any vendor supplying networked equipment going forward.
• Improve procurement language to require vendor disclosure of embedded third-party libraries and a commitment to firmware updates for known component CVEs.
• Create a repeatable firmware validation workflow that can be reused for the next embedded supply-chain disclosure.
• Update vendor-risk reviews to include embedded-component risk explicitly.

Long-Term Actions: 1–6 Months

• Reduce reliance on opaque third-party embedded stacks where alternatives exist; prefer vendors with transparent component disclosure.
• Establish lifecycle management for embedded libraries and device firmware, including end-of-support tracking.
• Expand supply-chain risk reviews for critical infrastructure procurement, particularly for medical, ICS, and energy sectors.
• Build replacement budgets for devices that cannot be patched but are still in production.
• Add embedded supply-chain disclosure scenarios to incident-response tabletop exercises.

Timeline

Indicators, Artifacts, or Detection Notes

Indicators

Detection Logic

Detection has two layers. First, identify devices that embed the Treck stack — this is the harder problem. Behavioral fingerprinting tools that observe TCP/IP stack quirks (response timing, header construction, error handling) can identify Treck-derived stacks even when no banner advertises it. Vulnerability scanners (Qualys QID 48106 was published for this purpose; Tenable Nessus released equivalent plugins) detect the stack but may produce false positives across the alternate-named branches.

Second, monitor for exploitation indicators on confirmed-affected devices: malformed packet activity from external sources, especially toward management interfaces; anomalous DNS response sizes targeting the affected DNS resolver path; and outbound connections from embedded devices that should not initiate outbound traffic.

Tooling

• Qualys QID 48106 (information-gathering plugin for Treck detection)
• Qualys QID 38789 (HP printers)
• Nessus / Tenable Treck plugins
• Forescout, CyberMDX, ORDR, Palo Alto Networks IoT Security: behavioral identification
• JSOF-provided detection scripts (available on request from JSOF at the time of disclosure)

Any scripts or tools referenced here are preserved for historical context unless explicitly marked as current.

Infrastructure Defense Lessons

1. What defenders should remember

Shared embedded code can become a multi-vendor incident even when the affected organization did not write, choose, or know about the vulnerable software. The library was selected by a vendor's vendor's vendor, decades ago, and outlived the original integration decision.

2. What organizations underestimated

Most teams underestimated how hard it is to identify embedded dependencies inside production devices. Asset management systems tracked the device, not the components inside the device. The exercise of answering "are we affected?" for Ripple20 turned out to be the dominant cost of the response — far more than the patching itself.

3. What held up well

Network segmentation held up well. Organizations that had already isolated their OT and medical device networks behind firewalls, with strict ACLs governing inbound traffic, were able to defer remediation on many devices without elevated exposure. Behavioral-based IoT security platforms (Forescout, CyberMDX, ORDR, Palo Alto IoT Security) handled detection better than signature-based tools.

4. What failed or became fragile

Asset visibility, firmware ownership, and patch coordination were the consistent weak points. Many organizations discovered that the vendor support contract on a device included support for the device but not for embedded third-party components — a contractual gap that left the customer holding the remediation cost.

For acquired or merged business units, the situation was often worse: the original procurement records, vendor relationships, and firmware management knowledge had been lost in organizational transitions.

5. What this changed in practice

Ripple20 accelerated three industry shifts: SBOM as a procurement requirement, embedded-component CVE feeds (the "Component-CVE" tracking model), and vendor-risk frameworks that explicitly addressed embedded-library disclosure obligations. The 2021 Executive Order 14028 (Improving the Nation's Cybersecurity) codified some of these expectations for federal procurement, which then propagated into private-sector contracts.

It also entrenched the principle that embedded devices on critical networks should be treated with the same lifecycle discipline as servers — including planned replacement when patch support ends.

Key Takeaways

• Embedded supply-chain flaws can create large-scale exposure across industries that share no apparent technology in common.
• Firmware visibility matters as much as endpoint visibility; you cannot patch what you cannot find.
• Patch ownership may be distributed across many vendors, with no single coordinating party.
• Network appliances, medical devices, and industrial controllers deserve the same security attention as servers and workstations.
• The hardest part of an embedded supply-chain incident is often identification, not remediation.
• Long-lived embedded components routinely outlast their original security assumptions, the original vendor, and sometimes the original technology era.
• Software Bill of Materials (SBOM) is not a paperwork exercise; it is the artifact that makes incidents like Ripple20 tractable.

References

1. JSOF — Ripple20 disclosure and technical whitepapers (2020).
2. CISA Advisory ICSA-20-168-01 — Treck TCP/IP Stack (2020).
3. Vendor advisories: HP, Schneider Electric (APC), Intel, Rockwell Automation, Baxter, B. Braun, Digi International, ABB, CareStream, Aruba Networks, Cisco, Caterpillar, Green Hills Software, Maxlinear (2020–2021).
4. Forescout Research Labs — Ripple20 vulnerability analysis.
5. Palo Alto Networks — Ripple20 IoT identification and remediation guidance.
6. Tenable / Qualys — Detection plugin documentation (QID 48106, QID 38789, equivalent Nessus plugins).
7. CyberMDX, ORDR — Behavioral detection of Treck stack on medical and IoT devices.
8. Cisco Talos / Cisco IoT Security blog — Ripple20 framing for industrial environments.