BusyBox vulnerabilities in embedded Linux firmware: identify, prioritise and fix

Because one executable contains many programs, and a CVE filed against any of them is a CVE against the whole binary. The BusyBox project's own description is that it "combines tiny versions of many common UNIX utilities into a single small executable," and that it is "extremely modular so you can easily include or exclude commands (or features) at compile time." On a typical router, camera, PLC gateway or industrial switch, /bin/sh, /bin/ls, /usr/bin/awk, /usr/bin/wget and /sbin/udhcpc are all symlinks to the same file. BusyBox reads the name it was called by (argv[0]) and runs the matching applet.

That design keeps firmware small, but it has a side effect for vulnerability management. A software bill of materials lists one component, busybox, with one version. Every CVE recorded against that version, whether it is in the shell parser, the awk interpreter, the DHCP client or a decompressor, then attaches to that one line. The five CVEs in the title show the pattern:

These are not lab curiosities that stay in the bug tracker. Siemens ProductCERT's SSA-089022, published 2026-01-28, lists all five among the third-party component vulnerabilities fixed in SINEC OS V3.3 for products such as the RUGGEDCOM RST2428P. Its SSA-585531, published 2026-07-14, lists CVE-2022-48174 for the SIDIS Secured SmartPlug before V7.26.0310. Industrial vendors ship BusyBox in exactly this way, and their own advisories show the CVEs travelling with it.

The same multi-call design means the CVE count says little about real exposure on its own. An image built without the awk applet does not contain the code behind CVE-2023-42363 to CVE-2023-42366, whatever the version string says. An image whose web interface passes request parameters to sh -c hands untrusted input straight to ash. That is why the next two steps, version and applets, have to be done together.

List the applets that are compiled in, then trace which of them untrusted input can actually reach on the running device. Compiled-in and reachable are two different questions:

For the five CVEs above, this check usually splits them into two groups. ash is the system shell on nearly every BusyBox image, so CVE-2022-48174 is almost always compiled in. Whether it is reachable depends on whether attacker-controlled strings reach the shell, the same pattern our command injection in embedded firmware guide describes for web and CLI handlers that shell out. The awk CVEs need a crafted awk program, the "crafted awk pattern" in NVD's descriptions. They matter where a script builds awk programs from received data, and much less where awk only runs fixed one-liners written by the firmware author. Memory-safety bugs like these follow the patterns in our memory corruption in embedded firmware guide.

Rank by reachability first and exploitation data second, then use the CVSS base score to break ties. The base score describes the flaw in general, not your device. Public data as of 2026-11-09 gives a clear order for the five CVEs:

KEV listing would override all of this: a BusyBox CVE added to CISA's catalog is being exploited in the wild and moves to the top of the list regardless of score. Our KEV and EPSS prioritisation guide explains how the two signals combine, and the CVSS v4 vs v3.1 guide covers why a 9.8 base score for a shell bug still needs environmental context on an embedded device.

Move to a BusyBox version that contains the fixes, or backport the specific fix commits, then trim unneeded applets, rebuild, and re-scan to prove the result. Each step has a trap worth knowing.

Choose between upgrade and backport. The BusyBox release page lists 1.36.1 (19 May 2023) as the last release labelled stable; 1.37.0 (27 September 2024) and 1.38.0 (13 May 2026) are labelled unstable. The 1.37.0 change log includes "awk: fix use after free (CVE-2023-42363)" and "awk: fix use-after-realloc (CVE-2021-42380)". A team that requires a "stable" label therefore backports onto 1.36.1. A team that tracks the newest line takes 1.37.0 or 1.38.0 and tests its scripts against the shell changes those releases contain.

Patch what upstream releases leave open. Debian's tracker for CVE-2023-42366 lists bookworm (1.35.0) and trixie (1.37.0-6) as vulnerable, with the fix only in its unstable 1:1.37.0-8 package. Moving to 1.37.0 alone does not close that heap overflow, so carry the distribution patch or remove awk if nothing needs it.

Trim the applet set. BusyBox's compile-time configuration is the cheapest mitigation available. Disabling awk, telnetd, httpd, ftpd or nc where the product does not use them removes their code, and their future CVEs, from the attack surface. Document the configuration in the SBOM or a VEX statement so that "awk not compiled in" is recorded evidence, not just a claim. Our CSAF and VEX for device makers guide shows the format, and the VEX generator drafts one.

Rebuild, re-scan, release. Rebuild the image, regenerate its firmware SBOM, and compare it with the previous release to confirm the new BusyBox version or patch level is what actually shipped. The SBOM diff tool does this for two SBOM files, and our firmware diffing and patch analysis guide covers the binary-level view. Then publish the fix in your advisory. Siemens' notices above show the expected form: affected versions, fixed version and the CVE list.

SoftWSP's automated scan unpacks a firmware image, catalogs the software components in the extracted file system, and identifies BusyBox by name and version. On OpenWrt-style images this includes the opkg package record, with the package revision stripped so the upstream version can be matched. It then matches that component version against CVE records, CISA's KEV catalog and FIRST's EPSS scores. This is deterministic code: the code scores, and AI narrates.

AI's part is the written explanation on top of that matching. It summarises which BusyBox CVEs matched, which are KEV-listed or have a high EPSS score, and what the version evidence was, and every sentence cites the component, version and record it relies on. An engineer reviews every finding before the report is delivered. The judgements this guide describes as manual stay with that engineer: which applets are compiled in, which ones untrusted input reaches, and whether a vendor backport already closes a version-matched CVE. Version-based matching flags a backported 1.35.0 build as affected. The review step is where backport evidence becomes a documented "not affected" decision, instead of SoftWSP presenting a guess as a result.

For where BusyBox review 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 the BusyBox project's release news and about page, the Debian Security Tracker, Debian LTS advisory DLA-4019-1, Siemens ProductCERT advisories SSA-089022 and SSA-585531, NVD, CISA's KEV catalog (version 2026.11.09) and FIRST EPSS data dated 2026-11-09, all read directly on 2026-11-10.