CVE-2025-60876: BusyBox wget Parsing Flaw Lets Request Smuggle Headers

BusyBox’s wget client contains a parsing flaw that lets specially crafted URLs embed raw control characters and even space characters in the HTTP request-target (path/query), allowing the HTTP request-line to be split and attacker-controlled headers to be injected — a vulnerability tracked as CVE-2025-60876 that affects wget shipped with BusyBox through version 1.3.7 and is assigned a medium severity rating by several distributors.

Background​

HTTP/1.1 defines a rigid, three-part request-line shape: METHOD SP request-target SP HTTP/1.1. RFC rules (modernized in RFC 9112) explicitly require CRLF (0x0D 0x0A) to terminate lines; accepting lone LF, raw CR/LF inside the request-target, or raw space characters inside the path/query can break that model and create framing ambiguities. Parsers that tolerate such non‑conformant inputs can therefore be induced to deserialize a single wire payload into a different sequence of requests or headers than a stricter component in the same path — the exact condition exploited by request-smuggling, header-injection, and request-splitting techniques. This class of protocol-desynchronization bugs is well understood and has surfaced in multiple HTTP stacks in 2024–2025.
BusyBox is widely used in embedded systems, minimal container images, and many Linux distributions that prefer a compact toolset. Its wget implementation is therefore commonly present in routers, IoT devices, recovery initramfs images, containers, and small-footprint Linux variants — places where administrators may not apply frequent updates. The combination of ubiquity and constrained maintenance windows makes even a seemingly modest client-side parsing bug meaningful for defenders.

---

What CVE-2025-60876 is and why it matters​

• The vulnerability: wget in BusyBox (through 1.3.7) accepted raw control bytes (CR, LF and other C0 controls) in the request-target (the path and query portion of an HTTP request). Those characters were not correctly rejected or percent‑encoded, which allowed an attacker to craft a request-target that, once sent as part of a single HTTP request, would be interpreted by the receiving HTTP stack as including new-line boundaries and thus split the request-line. The split allowed subsequent bytes on the same TCP stream to be parsed as attacker-controlled HTTP headers.
• The immediate consequence: header injection and request-line splitting can be used to inject headers such as Authorization, Cookie, or Transfer-Encoding into downstream services, or to smuggle an additional (smaller) request that bypasses front-end validations. The net impact ranges from information disclosure to cache poisoning and authorization bypass, depending on deployment topology and what headers or back-end logic an attacker can influence.
• Attack surface: remote/network — an attacker needs a way to get a victim client to execute BusyBox wget against a crafted URL (for example, a malicious redirect, an attacker-controlled resource, or a compromised mirror). In some deployments, an attacker on-path (MITM) or controlling a DNS entry could also induce the client to fetch the crafted URL. Public advisories and vendor trackers characterize the exploit complexity as low and the base CVSS as mid-range (commonly reported as CVSS 3.x = 6.5), reflecting network-exploitability with no privileges required.
• The “raw space” caveat: to preserve the three-element request-line shape, a raw ASCII space (0x20) in the request-target must also be rejected. Clients must send %20 instead; allowing literal spaces in the request-target can similarly enable or mask request-line splitting. This is an important implementation detail for parsing correctness and for constructing detection rules.

---

Technical analysis: how the parsing mistake becomes an exploit​

How HTTP framing is supposed to work​

HTTP/1.1 message framing is simple in concept but exacting in detail: the request-line and each header line are terminated by CRLF. The path/query portion — the request-target — is not allowed to contain raw CR or LF; those bytes delimit protocol grammar. When a client constructs the request-line, it must ensure any character that could be interpreted as a delimiter is percent-encoded.

What BusyBox wget did wrong​

In affected BusyBox builds, wget’s HTTP assembly accepted unencoded C0 control bytes (CR, LF and other control characters) inserted into the request-target. That meant an attacker who can control the requested resource path (for example, by hosting a URL segment or controlling a redirect) could arrange for the wire bytes to include the sequence that a lenient parser would treat as a line terminator. On the receiving side, components with different parsing strictness may disagree about where the request ends and where injected headers begin. The mismatch is exploitable where there is a multi-hop topology (reverse proxy or CDN in front of a back-end) or where a back-end trusts the front-end’s filtering.

Practical exploit outline (high level)​

• Attacker crafts a URL whose path contains sequences like %0d%0a or raw encoded control bytes — depending on the client’s encoding behavior — or uses any method that causes BusyBox wget to send raw C0 bytes in the request-target.
• The client issues a single HTTP request containing those bytes in the request-target.
• A front-end or proxy that is stricter about CRLF vs LF interprets the bytes differently than a back-end that is lenient, or vice versa.
• The ambiguity is exploited to inject headers or a second request into the back-end’s parser context; that second request can be processed with the back-end’s trust assumptions, potentially bypassing access control or poisoning caches.

This technique is closely related to classic HTTP request-smuggling and request-splitting attacks, a family of desync issues that have produced high-impact incidents when combined with caching, authentication, or certain application logic.

---

Distribution and vendor status — what’s patched and what’s not​

Multiple downstream security trackers and distribution advisories list CVE-2025-60876 and provide status updates that differ across vendors:

• NVD’s record is published and undergoing enrichment; the advisory description matches the BusyBox wget parsing problem but at the time of writing is still being enriched for scoring and CPEs.
• Debian’s security tracker lists BusyBox wget through 1.3.7 as vulnerable and shows that fixes are pending or deferred in several release branches; the Debian bug tracker entry references upstream discussion and an upstream gist with reproducer material. Administrators should check the distribution’s bug entry for the latest packaged fix level.
• Ubuntu and several other distributors (SUSE, Alpaquita and others) have published advisories classifying the issue as Medium/Important and listing CVSS 3.1 = 6.5 in many public aggregations. Some vendors have backported or packaged fixes in specific releases; others are flagging fixes pending upstream. Check your distro’s security tracker for released fixed package versions before assuming you are protected.
• Public upstream discussion: the BusyBox mailing-list threads and gist references are the primary public disclosure artifacts. They contain technical notes, test cases, and suggested upstream fixes; any downstream packaging should reference those artifacts when building patches.

Important operational takeaway: because BusyBox is embedded into many custom appliances and minimal OS images, the presence of a vulnerable wget binary may be far more widespread than common package lists indicate. Vendors that embed BusyBox directly into firmware images often require a separate firmware update cycle.

---

Cross-ecosystem context and precedent​

This is not an isolated parsing error. In 2025 several popular HTTP stacks were corrected for similar LF/CRLF tolerance problems (for example, Netty and Python’s h11), and platform vendors such as Microsoft hardened HTTP.sys to reject lone LF inside certain chunked encodings to reduce desynchronization risk. The community trend is clear: parsers must enforce the RFC grammar strictly or normalize inputs at the nearest ingress point to prevent request-smuggling by construction. The Microsoft hardening — which included an explicit registry toggle to permit a staged roll-out where compatibility is a concern — demonstrates the operational trade-offs faced by administrators.

---

Detection and hunting guidance​

Detecting exploitation attempts and narrowing the risk windows requires both log-based and network-level approaches. The following are practical detection starting points:

• Search logs for percent-encoded CR/LF sequences in request-targets: %0d, %0a, %0d%0a, particularly when they appear in URLs that would normally not include unusual control bytes.
• Hunt for raw unencoded control bytes in request-target fields captured in raw packet captures or in web server logs that preserve original bytes. Suspicious tokens include \r, \n, or \r\n appearing inside a URL path.
• Correlate unusual requests with unexpected downstream effects: sudden 4xx/5xx spikes after hardening, unexpected Authorization or Cookie headers arriving at back-ends, or mismatches between proxy logs and back-end logs where a front-end rejected or normalized a request but the back-end processed a different framing.
• WAF and IDS rules: apply detection rules that flag suspicious semicolons, zero-length chunks followed by embedded HTTP methods, or request-targets containing control bytes. Build a short-term sampling policy that logs any request-target containing bytes outside the normal printable ASCII range.
• Test harnesses: use crafted requests in a lab environment that attempt to inject %0d%0a sequences into the request-target to verify whether your proxies and back-ends normalize, reject, or treat such sequences differently. For deployments with front-end proxies, test full-path handling — a discrepancy between front-end and back-end behavior is the key factor that enables exploitation.

Note: public advisories do not currently indicate widescale exploitation in the wild for CVE-2025-60876. NVD and multiple distributor pages report the vulnerability and track fixes; absence of confirmed exploitation telemetry is not proof of safety. Treat any detection alert as serious and prioritize investigation and mitigation.

---

Mitigation and remediation steps​

• Patch first, where possible
• Upgrade BusyBox in your environment to a version that includes the upstream fix or apply your vendor’s fixed package. Some downstream Linux vendors have already produced patched BusyBox packages for specific releases; others have flagged fixes as pending. Validate the package version in your distribution’s security tracker before assuming protection.
• Workarounds and short-term compensations
• If you cannot update BusyBox immediately, avoid using the vulnerable wget binary in contexts that fetch untrusted URLs. Replace calls to BusyBox wget with curl or other clients that are known to correctly percent-encode or strictly validate the request-target, or vendor a patched BusyBox build.
• In scripted automation, ensure URL inputs are normalized and strictly validated; percent-encode spaces (%20) and reject input that contains control characters.
• Where possible, implement egress filtering that blocks outbound HTTP calls to untrusted hosts from constrained devices or embedded systems.
• Network-level hardening and normalization
• Deploy a canonicalization proxy that rewrites or rejects requests containing non‑printable control characters before they reach back-end services.
• Strengthen WAF rules to drop requests containing raw control characters in the path or query, or to normalize percent-encoded sequences to a strict canonical form.
• Rotate and monitor sensitive credentials
• Because header injection could be used to exfiltrate credentials (for example, an Authorization header), prioritize token rotation and credential review for services that may have been accessed by vulnerable clients.
• Test and roll out in stages
• For large fleets — especially appliance fleets with constrained firmware cycles — adopt a staged testing and rollout plan. Use pilot groups and monitoring to detect compatibility regressions. Where interaction with intermediate proxies exists, coordinate with proxy/vendor teams to validate end-to-end behavior.

---

Practical checklist for administrators (quick actions)​

• Inventory: identify all systems where BusyBox wget may be present — embedded appliances, containers, initramfs images, IoT devices, and lightweight distros.
• Patch: apply vendor-supplied BusyBox updates or rebuild and redeploy BusyBox that contains the upstream fix.
• Replace: where patching is not feasible, replace calls to BusyBox wget with safer clients or a statically linked patched binary.
• Harden ingress/egress: add WAF and egress filtering rules to block suspicious request-targets and limit which external hosts appliances can contact.
• Hunt: search logs and packet captures for %0d, %0a, %0d%0a occurrences within URLs, and investigate any anomalies.
• Rotate secrets where exposure risk exists and validate downstream logs for unexpected Authorization or Cookie headers arriving at back-end services.

---

Risk assessment and operational trade-offs​

• Severity and likelihood: most public trackers classify CVE-2025-60876 as medium (CVSS ~6.5) because exploitation yields low confidentiality/integrity impact in many contexts and typically requires the attacker to control a URL or be on-path. That said, in specific topologies — appliance-based reverse proxies, or back-ends that implicitly trust front-end sanitization — the impact can be elevated. Distributors’ scoring variations reflect different threat models and downstream exposure assumptions.
• Compatibility vs security: the broader industry trend toward strict RFC compliance sometimes breaks legacy or misconfigured intermediaries that historically tolerated non‑standard inputs. Vendors such as Microsoft have offered registry toggles to allow staged rollouts of strict parsing to protect availability while fixing a correctness bug; a similar operational trade-off exists for BusyBox users: immediate strictness reduces attack surface but can cause integration issues with systems that tolerated malformed inputs for years. Administrators must plan staged validation to avoid surprise outages.
• Evidence of in-the-wild exploitation: there are no publicly confirmed mass-exploitation reports linked to CVE-2025-60876 at the time of publication. Public trackers show disclosure, public patch timelines, and technical mailing‑list threads, but no confirmed exploit telemetry. This absence should not be treated as safety — it is an operational vulnerability that should be remediated where vulnerable assets exist.

---

Developer and vendor guidance (for teams building or shipping BusyBox)​

• Apply strict validation at the HTTP client assembly stage: do not accept or forward raw control characters in the request-target — enforce percent-encoding for reserved or dangerous bytes.
• Add unit and integration tests that simulate malicious request-target inputs, including raw CR/LF, lone LF, and raw spaces, and verify the client either rejects or encodes them correctly.
• Consider adding an allowlist for URL path characters in constrained environments and refuse to fetch resources with non‑printable characters.
• For vendors shipping embedded images, produce a compatibility and update plan for appliances in the field, including a safe rollback strategy and a mechanism to update BusyBox in firmware where feasible.

---

Conclusion​

CVE-2025-60876 is a concrete demonstration of a long-standing category of vulnerabilities: protocol-framing bugs that arise when different components in a request path tolerate different interpretations of delimiters. On the wire, CR, LF, and even a plain space have semantic meaning in HTTP framing — they are not benign characters that can be allowed inside the request-target. BusyBox’s wget implementation prior to 1.3.8 failed to enforce that constraint, opening a channel for request-line splitting and header injection.
Administrators should treat this as a practical operational risk: inventory BusyBox instances, apply vendor-supplied fixes or replace vulnerable clients, and deploy network-level normalization and detection where updates are delayed. Because the vulnerability is easy to test for and reasonably straightforward to mitigate in code and at the network edge, remediation should be prioritized for high‑exposure appliances and any systems that perform automated outbound fetches in response to untrusted inputs. Public trackers and distribution advisories provide patch status and scoring guidance; consult your distribution’s security tracker for the authoritative fixed package versions for your environment.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center