CVE-2026-88839

What it actually does

BusyBox’s passwd/group tokenize() path retains an endpoint pointer into a line buffer that is later trimmed. After the trim, that pointer is stale, so subsequent tokenization performs an out-of-bounds write of heap pointers. The result is heap memory corruption in the BusyBox process: adjacent heap metadata or objects can be overwritten, which can crash the process or, in the worst case, be turned into arbitrary code execution with the privileges of that process. The issue is local-only and requires high privileges (CVSS AV:L, PR:H) with high confidentiality, integrity, and availability impact in the BusyBox process (C:H/I:H/A:H).

Why it matters to the business

Operational risk is concentrated on hosts and images that ship Red Hat busybox-main in privileged or setuid-adjacent roles (container base images, appliances, rescue/initramfs, and embedded Linux). A successful exploit can take down or fully compromise the BusyBox process, disrupting login, account, and group administration applets and, if BusyBox is the system’s core userland, broader host integrity. Real-world urgency is currently low: EPSS is ~0.00123 and flat over 30 days, the CVE is not in CISA KEV, ransomware use is not reported, and no public exploit maturity is listed. The advisory is 19 days old; organizations that rebuild or redistribute BusyBox images still have a patching and image-refresh obligation because the impact, if reached, is complete process compromise.

How an attack unfolds

An attacker who already has local, high-privilege access on a host running a vulnerable BusyBox build causes a passwd or group parsing path to process a line that is trimmed in a way that invalidates tokenize()’s saved endpoint. tokenize() then writes heap pointers past the valid buffer. That out-of-bounds write corrupts the heap of the BusyBox process. Depending on allocator layout and how the applet continues, the process may abort, or the attacker may further manipulate heap state to redirect control flow and run code as the BusyBox process. No named threat actors, KEV campaigns, or public exploit kits are associated with this CVE; exploitation is therefore expected to be opportunistic, local, and post-compromise rather than a remote initial-access vector.

How to fix it

Upgrade Red Hat busybox-main to the fixed build 1.37.0-9.1.hum1 as published in RHSA-2026:72111, then rebuild and redeploy any container images, appliance firmware, initramfs, or embedded rootfs that vendor BusyBox rather than only patching live packages. Where immediate upgrade is not possible, reduce exposure by limiting who can invoke privileged BusyBox passwd/group applets, removing unnecessary setuid BusyBox bits, and avoiding untrusted or attacker-writable passwd/group content being parsed by a privileged BusyBox process. Treat image rebuilds as first-class remediation because BusyBox is commonly baked into immutable artifacts.

How to confirm the fix worked

Confirm the installed busybox-main RPM (or image layer) is at or beyond 1.37.0-9.1.hum1 and that RHSA-2026:72111 is applied. Inventory running containers and golden images for older busybox-main, and re-scan after rebuild. Functionally, exercise passwd and group applets against normal account files and confirm they complete without crash. Absence of a BusyBox segfault or abort during passwd/group tokenization after the upgrade indicates the stale-pointer write is no longer present; do not use crafted crash PoCs to validate.

Typical attack path

1. Obtain local access on a host or container that runs vulnerable Red Hat busybox-main with high privileges already available to the attacker.
2. Cause a BusyBox passwd or group applet (or any code path that tokenizes passwd/group records) to parse attacker-influenced input that is trimmed before tokenize() finishes using its saved endpoint pointer.
3. Trigger the stale-pointer out-of-bounds write of heap pointers and corrupt adjacent heap state.
4. Use the resulting memory corruption to crash BusyBox or to hijack the process for further local integrity/confidentiality impact.
5. Optionally persist or move laterally using the compromised privileged process; this step is post-exploitation and not unique to this bug.

How to detect it

This is a local heap-corruption bug with no network protocol, so detection of prior exploitation is host-forensic rather than traffic-based. Look for unexpected BusyBox crashes or core dumps around passwd/group applets (passwd, adduser, addgroup, deluser, delgroup, getent, and related applets) after processing account files; kernel logs showing busybox segfaults, aborts, or heap allocator fatal errors (for example glibc malloc/free assertions if BusyBox is dynamically linked); sudden BusyBox process restarts in containers; and unauthorized changes to /etc/passwd, /etc/group, or shadow files immediately before a crash. There are no associated APT groups or ransomware campaigns to hunt by name. Correlate local privileged logins or sudo/su sessions with subsequent BusyBox crashes. A crash alone is not proof of exploitation, but a crash plus evidence of crafted or unexpected passwd/group content and follow-on process impersonation is the realistic investigation path.

• process_name:busybox AND (segfault OR SIGSEGV OR SIGABRT OR "malloc():" OR "free():" OR "corrupted double-linked list")
• cmdline containing busybox plus applet names: passwd, adduser, addgroup, deluser, delgroup, getent
• core dump / corefile of busybox after passwd or group parsing
• auditd EXECVE of busybox with passwd|group applets from a high-privilege session shortly before a crash
• unexpected modification of /etc/passwd or /etc/group immediately preceding a busybox crash

What your security team should do

• Patch and rebuild first: apply RHSA-2026:72111 / busybox-main 1.37.0-9.1.hum1 everywhere Red Hat BusyBox is shipped, including container and appliance images.
• Prioritize hosts where BusyBox runs privileged passwd/group paths (login images, appliance userland, rescue environments) over general-purpose servers that do not invoke those applets.
• Do not treat this as an internet-facing emergency: EPSS is negligible, KEV is false, and exploit maturity is none—schedule within normal privileged-local memory-corruption SLAs unless BusyBox is your primary userland.
• Hunt for leftover vulnerable layers in registries and golden images after package patching, because image drift is the most likely residual exposure.
• Restrict local high-privilege accounts and setuid BusyBox usage so that even an unpatched instance cannot be reached by untrusted operators.