Hi,

Anmol Bakshi brought the below with original Subject line saying "BusyBox dpkg applet: OS command injection -> root RCE (CWE-78)" to linux-distros on July 13. We quickly determined that no privilege boundary is crossed, so the coordinated disclosure request was withdrawn. However, we cannot just withdraw something sent to linux-distros (as long as it wasn't completely off-topic) without also bringing it to oss-security. In this case, we overlooked that until I started processing the linux-distros list statistics for July.

I include the linux-distros messages quoted below, sans the originally attached PDF file (which I didn't even look at).

Alexander

On Mon, Jul 13, 2026 at 08:44:40AM +0530, Anmol Bakshi wrote: Proposed coordinated public disclosure: 2026-07-27.

Summary -------

OS command injection in BusyBox's dpkg applet gives arbitrary command execution as the user running dpkg (root in typical use). Present through current BusyBox; confirmed on 1.36.1 and 1.37.0.git HEAD.

Vulnerability -------------

archival/dpkg.c (~line 1271): scriptpath = xasprintf("/var/lib/dpkg/info/%s.%s", packagename, scripttype); result = access(scriptpath, FOK) ? EXITSUCCESS : system(scriptpath);

The Package field from the .deb control file is passed unvalidated into the path handed to system() (/bin/sh -c). Shell metacharacters in the package name execute as command separators. The forward-slash filename restriction is bypassed with a base64-encoded payload the shell decodes at runtime, making injection unrestricted.

Impact ------

Arbitrary command execution as uid=0. Demonstrated: /etc/shadow exfiltration and an outbound network callback from a crafted .deb. CVSS 4.0: 9.3 (AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H). CWE-78.

Affected scope --------------

Any build with CONFIGDPKG enabled that processes an attacker-supplied .deb. The applet is enabled in some distro builds (for example Debian's busybox deb config enables a minimal dpkg). Please assess your own configuration.

Suggested fix -------------

1. Replace system(scriptpath) with fork()/execl(scriptpath, scriptpath, (char)NULL) so no shell is invoked. 2. Validate package names against ^[a-z0-9][a-z0-9.+-]+$ to match GNU dpkg.

Coordination ------------

This is a coordinated disclosure. I am separately notifying Alpine Linux, OpenWrt, the Yocto Project, and Buildroot (none of which are on this list), all toward the same public date of 2026-07-27. BusyBox upstream has no working private security channel: the Bugzilla instance is offline and the security contact bounces. I sent a private report on 2026-04-21 with no response in ~3 months, so there is no upstream fix to coordinate. I have an open MITRE request from 2026-04-21 that has not been actioned; I would prefer a CVE ID be assigned via a CNA on this list. Full report and a self-contained reproduction script are attached. Please confirm receipt.

Regards, Anmol Bakshi https://anmolbakshi.com On Mon, Jul 13, 2026 at 08:32:59AM +0200, Solar Designer wrote: Hello Anmol,

Thank you for notifying linux-distros.

On Mon, Jul 13, 2026 at 08:44:40AM +0530, Anmol Bakshi wrote: Proposed coordinated public disclosure: 2026-07-27. I ack that this is a valid public disclosure date per this list's policy, but I note it's the latest possible - so please note that no extension beyond this date will be possible.

Please make sure you post specifically to the public oss-security list when making the issue public. Full report and a self-contained reproduction script are attached. Unfortunately, you sent these pre-encrypted to the list key, whereas the list only re-encrypts non-pre-encrypted attachments of full PGP/MIME messages as commonly produced by MUAs with PGP support. In fact, I think these attachments ended up double-encrypted when you sent the message, and only the outer layer got processed by the list software. So they arrived to list subscribers still encrypted to the list key as you prepared them, rather than re-encrypted to their keys, and thus are unreadable to them.

I suggest that you selectively send these to list members who ask, or you may resend the reproduction script as a simple attachment (don't pre-encrypt, but let the MIME message be encrypted) or in message body.

I doubt the PDF is worth resending, but I don't know what's in it. For oss-security, the message size limit (including MIME overhead) is 1 MB, so this large PDF wouldn't be suitable for posting to there anyway. Please confirm receipt. Confirmed as above. OS command injection in BusyBox's dpkg applet gives arbitrary command execution as the user running dpkg (root in typical use). I guess package installation via dpkg would invoke scripts found in the package as part of intended functionality, so there would be no additional risk from your finding - but perhaps there are query-only uses where your finding matters? You could want to elaborate on that.

I am not familiar with BusyBox's dpkg.

Replying in plaintext as I didn't bother searching for your public key, but I limited the quoting. (And this gets encrypted to list subscribers anyway.)

Alexander On Mon, Jul 13, 2026 at 12:57:10PM +0530, Anmol Bakshi wrote: Hi Alexander,

Thanks again for the detailed feedback - you're right, and I'm withdrawing this.

To close the loop on the impact question: runpackagescriptordie() is only reached during install / unpack / configure / remove, i.e. exactly the operations where a package's maintainer scripts are expected to run as root. BusyBox dpkg's only read-only operation (-l) doesn't touch that path. So the injected command runs with the same privilege a normal postinst already would; the unvalidated package name doesn't cross a boundary that an ordinary malicious maintainer script wouldn't.

I also considered the "trojan a real package, keep the same name to slip past review" angle, but it doesn't change that: dpkg -i on a local file does no signature or integrity check, so there's no verification for the name injection to bypass, and the operator has already chosen to run untrusted code as root regardless of what the scripts contain. No privilege boundary is crossed there either.

So I'm standing down the coordinated-disclosure request and won't pursue a CVE on this basis - no need for anyone on the list to hold anything for 2026-07-27. The one thing I still think is worthwhile is a hardening change to BusyBox (validate the package name as GNU dpkg does, and don't pass the path to a shell); I'll take that to BusyBox directly as a patch, outside this list.

Thanks for the time, and sorry for the noise.

Regards, सादर, Anmol Bakshi On Sat, Aug 22, 2026 at 09:46:57PM +0200, Solar Designer wrote: Hi Anmol,

I'm sorry everyone seems to have dropped the ball on this after your last message. I understand you may have thought you could simply withdraw a report, but others on linux-distros should have realized that's not the case.

On Mon, Jul 13, 2026 at 12:57:10PM +0530, Anmol Bakshi wrote: Thanks again for the detailed feedback - you're right, and I'm withdrawing this. Thanks, but currently you cannot just withdraw a report to linux-distros without bringing it to oss-security - all while acknowledging it was determined to be a non-security issue. We need this for transparency. If the ratio of non-security reports becomes much larger, we'll have to reconsider this approach - and announce that publicly - but for now that's the approach we use and the oss-security community may expect.

Are you going to bring this to oss-security ASAP? If not, I will.

Alexander

A vulnerability has been found in BusyBox up to 1.30.1. This vulnerability affects unknown code of the file networking/wget.c of the component FEATUREWGETTIMEOUT Handler. Such manipulation of the argument -T leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The name of the patch is 83a40bf7a93c8ac093d33ab452222dd5b9eb57ff. A patch should be applied to remediate this issue.

A use-after-free in the awksub() function (editors/awk.c) of Busybox v1.38.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted AWK script.

A heap overflow in the evalcommand() function (shell/ash.c) of Busybox v1.38.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted input.

A heap overflow in the ifsbreakup() function (shell/ash.c) of Busybox v1.38.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted input.

A stack overflow in the evaluate() function (editors/awk.c) of BusyBox commit 371fe9 allows attackers to cause a Denial of Service (DoS) via supplying a crafted AWK script.

BusyBox before commit 42202bf contains a heap buffer overflow vulnerability in the DHCPv6 client (udhcpc6) DNSSERVERS option handler in networking/udhcp/d6dhcpc.c that allows network-adjacent attackers to trigger memory corruption by sending a crafted DHCPv6 response with a malformed D6OPTDNSSERVERS option. Attackers can exploit incorrect heap buffer allocation calculations in the optiontoenv() function to cause denial of service or achieve arbitrary code execution on embedded systems without heap hardening.

BusyBox before commit 42202bf contains a heap buffer overflow vulnerability in the DHCPv6 client (udhcpc6) DNSSERVERS option handler in networking/udhcp/d6dhcpc.c that allows network-adjacent attackers to trigger memory corruption by sending a crafted DHCPv6 response with a malformed D6OPTDNSSERVERS option. Attackers can exploit incorrect heap buffer allocation calculations in the optiontoenv() function to cause denial of service or achieve arbitrary code execution on embedded systems without heap hardening.

A flaw was found in BusyBox. This vulnerability allows an attacker to modify files outside of the intended extraction directory by crafting a malicious tar archive containing unvalidated hardlink or symlink entries. If the tar archive is extracted with elevated privileges, this flaw can lead to privilege escalation, enabling an attacker to gain unauthorized access to critical system files.

A flaw was found in BusyBox. Incomplete path sanitization in its archive extraction utilities allows an attacker to craft malicious archives that when extracted, and under specific conditions, may write to files outside the intended directory. This can lead to arbitrary file overwrite, potentially enabling code execution through the modification of sensitive system files.

BusyBox wget thru 1.3.7 accepted raw CR (0x0D)/LF (0x0A) and other C0 control bytes in the HTTP request-target (path/query), allowing the request line to be split and attacker-controlled headers to be injected. To preserve the HTTP/1.1 request-line shape METHOD SP request-target SP HTTP/1.1, a raw space (0x20) in the request-target must also be rejected (clients should use %20).

Busybox 1.31.1 - Multiple Known Vulnerabilities.This issue affects BLU-IC2: through 1.19.5; BLU-IC4: through 1.19.5.

Busybox 1.31.1 - Multiple Known Vulnerabilities.This issue affects BLU-IC2: through 1.19.5; BLU-IC4: through 1.19.5.

On 4/24/25 7:57 PM, Solar Designer wrote: On Thu, Apr 24, 2025 at 07:09:44PM -0400, Demi Marie Obenour wrote: On 4/24/25 3:09 AM, Albert Veli wrote: On Wed, Apr 23, 2025 at 10:51 PM Salvatore Bonaccorso <carnil () debian org> wrote: FTR, this one has assigned CVE-2025-46394 ... FTR, this one has CVE-2024-58251 assigned. From what I can tell the latest release is busybox-1.37.0. Are these fixed in this release? If not, do you have any link to patches I can apply to fix these issues?

Regards, Albert This message was marked as spam by GMail. The ARC-Authentication-Results header indicates that the mailing list is not configured in a DMARC-compatible way. Specifically, the mailing list did not rewrite the From: header but did modify the message body, so the DKIM signature check failed. This was a special case - DKIM-breaking message body modification shouldn't normally happen here.

However, the list is indeed not DMARC-compatible: we insert [oss-security] into the Subject when it's not already near the beginning of that header (may break DKIM), and we relay messages from the list server's IP address (may be against the From header domain's SPF, although recipient servers may look at envelope-from instead, which we do rewrite, so SPF will match in that respect). SPF won’t be a problem so long as the message is DKIM-signed. For now, this is simply how it is. Most delivery problems occur when the sender's domain has strict DMARC policy ("p=reject"), so e.g. when someone from google.com posts, the message doesn't get through to subscribers on gmail.com. For gmail.com to gmail.com, everything is usually "fine" for now. gmail.com now has p=quarantine, so this is already starting to cause problems even there. I think it is best to either rewrite the From header unless there is a DKIM signature and it is kept intact, or bounce the message instructing the user to add [oss-security] to the Subject themselves. -- Sincerely, Demi Marie Obenour (she/her/hers)

On Thu, Apr 24, 2025 at 07:09:44PM -0400, Demi Marie Obenour wrote: On 4/24/25 3:09 AM, Albert Veli wrote: On Wed, Apr 23, 2025 at 10:51 PM Salvatore Bonaccorso <carnil () debian org> wrote: FTR, this one has assigned CVE-2025-46394 ... FTR, this one has CVE-2024-58251 assigned. From what I can tell the latest release is busybox-1.37.0. Are these fixed in this release? If not, do you have any link to patches I can apply to fix these issues?

Regards, Albert This message was marked as spam by GMail. The ARC-Authentication-Results header indicates that the mailing list is not configured in a DMARC-compatible way. Specifically, the mailing list did not rewrite the From: header but did modify the message body, so the DKIM signature check failed. This was a special case - DKIM-breaking message body modification shouldn't normally happen here.

However, the list is indeed not DMARC-compatible: we insert [oss-security] into the Subject when it's not already near the beginning of that header (may break DKIM), and we relay messages from the list server's IP address (may be against the From header domain's SPF, although recipient servers may look at envelope-from instead, which we do rewrite, so SPF will match in that respect).

For now, this is simply how it is. Most delivery problems occur when the sender's domain has strict DMARC policy ("p=reject"), so e.g. when someone from google.com posts, the message doesn't get through to subscribers on gmail.com. For gmail.com to gmail.com, everything is usually "fine" for now.

Yes, we may need to bite the bullet and add From header rewriting.

Alexander

On 4/24/25 3:09 AM, Albert Veli wrote: Hi,

On Wed, Apr 23, 2025 at 10:51 PM Salvatore Bonaccorso <carnil () debian org> wrote: FTR, this one has assigned CVE-2025-46394 ... FTR, this one has CVE-2024-58251 assigned. From what I can tell the latest release is busybox-1.37.0. Are these fixed in this release? If not, do you have any link to patches I can apply to fix these issues?

Regards, Albert This message was marked as spam by GMail. The ARC-Authentication-Results header indicates that the mailing list is not configured in a DMARC-compatible way. Specifically, the mailing list did not rewrite the From: header but did modify the message body, so the DKIM signature check failed. -- Sincerely, Demi Marie Obenour (she/her/hers)

On Thursday, 24 April 2025 at 17:16 Albert Veli <albert.veli () gmail com> wrote: On Wed, Apr 23, 2025 at 10:51 PM Salvatore Bonaccorso <carnil () debian org> wrote: FTR, this one has assigned CVE-2025-46394

From what I can tell the latest release is busybox-1.37.0. Are these fixed in this release? If not, do you have any link to patches I can apply to fix these issues? I re-posted the patch for CVE-2025-46394 to https://lists.busybox.net/pipermail/busybox/2025-April/091461.html

I was sceptical about the isatty() call but it was requested by others on the list

-- Ian

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

On Wednesday 23 April 2025 at 17:04 Jakub Wilk <jwilk () jwilk net> wrote CVE-2023-39810 But it seems busybox committed a different patch, which looks good: https:/git.busybox.net/busybox/commit/?id=9a8796436b9b0641 ("archival: disallow path traversals (CVE-2023-39810)")

The essence of the patch is:

+#if ENABLEFEATUREPATHTRAVERSALPROTECTION + / Strip leading "/" and up to last "/../" path component / + dstname = (char )stripunsafeprefix(dstname); +#endif Yes, that looks better, but it is still an opt-in. Users would need to compile Busybox with the FEATUREPATHTRAVERSALPROTECTION feature enabled.

-- Ian

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

Hi,

On Wed, Apr 23, 2025 at 10:51 PM Salvatore Bonaccorso <carnil () debian org> wrote: FTR, this one has assigned CVE-2025-46394 ... FTR, this one has CVE-2024-58251 assigned.

From what I can tell the latest release is busybox-1.37.0. Are these fixed in this release? If not, do you have any link to patches I can apply to fix these issues?

Regards, Albert

Hi,

On Wed, Apr 23, 2025 at 05:38:17PM +0200, Ricardo Branco wrote: I reported this one in busybox's netstat a year ago:

https://bugs.busybox.net/showbug.cgi?id=15922

The whole code needs a security audit for ANSI escapes like this. FTR, this one has CVE-2024-58251 assigned.

Regards, Salvatore

Hi,

On Wed, Apr 23, 2025 at 02:11:44PM +0000, Ian Norton wrote: https://bugs.busybox.net/showbug.cgi?id=16018 (awaiting CVE)

Busybox's cpio and tar tools will print un-escaped filenames when listing and unpacking cpio and tar files. Malicious files containing filenames with terminal escapes can be used to mask or modify earlier or later files in the archive from anyone running busybox tar or cpio from a terminal. FTR, this one has assigned CVE-2025-46394 .

Regards, Salvatore

Ian Norton <Ian.Norton () entrust com>, 2025-04-23 14:11: https://security-tracker.debian.org/tracker/CVE-2023-39810

see also https://lists.busybox.net/pipermail/busybox/2024-July/090851.html

But it seems busybox committed a different patch, which looks good: https://git.busybox.net/busybox/commit/?id=9a8796436b9b0641 ("archival: disallow path traversals (CVE-2023-39810)")

The essence of the patch is:

+#if ENABLEFEATUREPATHTRAVERSALPROTECTION + / Strip leading "/" and up to last "/../" path component / + dstname = (char )stripunsafeprefix(dstname); +#endif

-- Jakub Wilk

I reported this one in busybox's netstat a year ago:

https://bugs.busybox.net/showbug.cgi?id=15922

The whole code needs a security audit for ANSI escapes like this.

Best,

R

On 4/23/25 4:11 PM, Ian Norton wrote: https://bugs.busybox.net/showbug.cgi?id=16018 (awaiting CVE)

Busybox's cpio and tar tools will print un-escaped filenames when listing and unpacking cpio and tar files. Malicious files containing filenames with terminal escapes can be used to mask or modify earlier or later files in the archive from anyone running busybox tar or cpio from a terminal.

see also https://lists.busybox.net/pipermail/busybox/2024-July/090806.html

https://security-tracker.debian.org/tracker/CVE-2023-39810

A unpacking a cpio archive can escape the working directory. Due to #16018 it is possible to mask these traversals from anyone using cpio to inspect a file before unpacking.

see also https://lists.busybox.net/pipermail/busybox/2024-July/090851.html

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

https://bugs.busybox.net/showbug.cgi?id=16018 (awaiting CVE)

Busybox's cpio and tar tools will print un-escaped filenames when listing and unpacking cpio and tar files. Malicious files containing filenames with terminal escapes can be used to mask or modify earlier or later files in the archive from anyone running busybox tar or cpio from a terminal.

see also https://lists.busybox.net/pipermail/busybox/2024-July/090806.html

https://security-tracker.debian.org/tracker/CVE-2023-39810

A unpacking a cpio archive can escape the working directory. Due to #16018 it is possible to mask these traversals from anyone using cpio to inspect a file before unpacking.

see also https://lists.busybox.net/pipermail/busybox/2024-July/090851.html

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

In tar in BusyBox through 1.37.0, a TAR archive can have filenames hidden from a listing through the use of terminal escape sequences.

In netstat in BusyBox through 1.37.0, local users can launch of network application with an argv[0] containing an ANSI terminal escape sequence, leading to a denial of service (terminal locked up) when netstat is used by a victim.

A vulnerability classified as problematic was found in Netis WF-2404 1.1.124EN. Affected by this vulnerability is an unknown functionality of the component BusyBox Shell. The manipulation leads to cleartext storage of sensitive information. It is possible to launch the attack on the physical device. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A use-after-free vulnerability was discovered in xasprintf function in xfuncsprintf.c:344 in BusyBox v.1.36.1.

A use-after-free vulnerability in BusyBox v.1.36.1 allows attackers to cause a denial of service via a crafted awk pattern in the awk.c evaluate function.

A use-after-free vulnerability was discovered in BusyBox v.1.36.1 via a crafted awk pattern in the awk.c copyvar function.