CVE-2026-88837

What it actually does

BusyBox httpd Basic Authentication does not treat stored yescrypt hashes (the $y$ prefix) as a password-hash algorithm. It compares them as plaintext and inverts the authentication result, so requests that should be rejected can be accepted and legitimate yescrypt credentials may fail. A network client with no prior privileges can therefore gain access to HTTP resources the realm was meant to protect, with high impact on confidentiality of those resources and a lesser integrity impact on whatever actions the httpd instance exposes.

Why it matters to the business

Embedded devices, appliances, containers, rescue images, and other systems that use BusyBox as a small web server can expose password-protected pages, files, or admin functions to unauthenticated callers if httpd password stores contain yescrypt hashes. That can mean disclosure of internal content and limited unauthorized changes. The issue is not in CISA KEV, has no public exploit maturity, and EPSS is low and unchanged (~0.0027 over 30 days), so mass exploitation is not indicated; still treat internet-facing BusyBox httpd with Basic Auth as an authentication-bypass risk and apply RHSA-2026:72111 promptly.

How an attack unfolds

An unauthenticated network attacker finds a BusyBox httpd listener that challenges clients with HTTP Basic Authentication and whose password file uses yescrypt ($y$) hashes—commonly after hashes were taken from a modern Linux password store or generated with a yescrypt-default crypt. Because the daemon treats those hashes as plaintext and inverts the pass/fail decision, the attacker can obtain a successful authentication outcome without knowing the account’s real password. CVSS rates complexity as high: the attacker must identify an affected BusyBox build, a protected realm, and yescrypt-formatted stored credentials. No named threat actors or ransomware campaigns are associated with this CVE, and no in-the-wild exploitation is reported.

How to fix it

Upgrade Red Hat busybox-main to 1.37.0-9.1.hum1 or later (RHSA-2026:72111). Until patched, do not store yescrypt ($y$) hashes in BusyBox httpd password files; use only a hash type BusyBox httpd actually verifies, or terminate TLS/Basic Auth in a front-end that performs correct verification. Compensating controls: disable BusyBox httpd if it is not required, bind it to trusted interfaces only, and restrict who can reach protected realms with network policy. Rebuild and redeploy container and appliance images that vendor BusyBox so downstream artifacts are not left on the vulnerable package.

How to confirm the fix worked

Confirm busybox-main is 1.37.0-9.1.hum1 or newer and that RHSA-2026:72111 applies and is installed. Search BusyBox httpd password files for $y$ hashes and rotate those credentials after upgrade. After patching, verify that valid credentials are accepted and invalid credentials are rejected for every Basic Auth realm, and that protected URLs return 401/403 without a correct password. Inventory hosts and images listening with BusyBox httpd to ensure none remain on unpatched busybox-main.

Typical attack path

1. Find a network-reachable BusyBox httpd service that uses HTTP Basic Authentication
2. Determine that the realm’s stored credentials use yescrypt ($y$) hashes
3. Submit Basic Authentication requests to a protected resource on that service
4. Gain access because the inverted plaintext comparison accepts the request
5. Read protected content or use limited functions the httpd realm exposes

How to detect it

No public exploit, named actor, or unique payload is associated with this issue, so hunt outcomes rather than a signature. Review HTTP access logs and syslog from BusyBox httpd on and after 2026-09-23 for successful responses (for example HTTP 200) to URLs that normally send a Basic authentication challenge, especially from unusual source addresses or without corresponding legitimate user activity. Treat password files containing $y$ as evidence of exposure, not proof of compromise. Correlate busybox httpd process start with unexpected retrieval of previously locked-down paths following an Authorization: Basic header. A successful bypass looks like a normal authenticated session, so prioritize first-seen, after-hours, or off-network access to protected content.

What your security team should do

• Patch busybox-main to 1.37.0-9.1.hum1 via RHSA-2026:72111 as the primary fix
• Inventory BusyBox httpd with Basic Authentication, prioritizing internet-exposed listeners and embedded/container images
• Find and replace $y$ hashes in httpd password files and rotate those credentials after upgrade
• Disable or network-restrict BusyBox httpd where it is not a required service
• Hunt access logs after 2026-09-23 for successful access to previously protected BusyBox httpd resources from unexpected sources
• Rebuild vendor images that bundle BusyBox so the fixed package is what actually ships