OpenLiteSpeed CVE-2026-104474

Requires three concrete preconditions: (1) the attacker must already control the 'nobody' web-server process (prior code execution as that low-privileged user); (2) OpenLiteSpeed's lsup.sh auto-update feature must be exercised by an administrator, since the malicious payload only runs when root performs an update; and (3) the attacker must win a TOCTOU race to replace the package in the nobody-writable /usr/local/lsws/autoupdate/ directory before root extracts and runs its install.sh. Limiting factors: affected only in versions before 1.9.3, local access only (AV:L), no SHA-256 verification in the pre-fix script, and dependence on an operator-triggered update plus race timing (AC:H/AT:P) - all of which substantially narrow realistic exploitation despite the root-level impact.

This is a genuine but conditional local privilege-escalation (CWE-367 TOCTOU) issue, not a remotely weaponizable critical. The input CVSS 4.0 vector (AV:L/AC:H/AT:P/PR:L/UI:P, score 5.4 Medium) is internally consistent with the description: exploitation is local, requires an existing low-privileged foothold (the nobody web process), depends on an administrator-initiated update actually occurring (UI/attack requirement), and hinges on winning a race condition (AC:H) - so this is a second-stage escalation primitive rather than an initial-access bug. The technical impact is severe once conditions are met (VC:H/VI:H/VA:H = full root code execution), which is why it matters for defense-in-depth. However, the signals temper urgency: NO EPSS score was provided (exploitation-probability unknown), the CVE is NOT in CISA KEV, and no public proof-of-concept is referenced - only a vendor/VulnCheck advisory, the fixing commit, and source lines. SSVC-style reading: exploitation=none observed, automatable=no (requires a race against an operator-triggered update), technical impact=total. Net: real but lower-priority than its root-code-execution impact might suggest; prioritize on hosts where OpenLiteSpeed auto-update is used and where web code already runs as nobody. No signals conflict here - all point to a high-impact, hard-to-reach local escalation.

An attacker who has already achieved code execution as the unprivileged 'nobody' web user (e.g., via a separate web-application flaw) plants a malicious update package in the world/nobody-writable /usr/local/lsws/autoupdate/ directory. When an administrator next triggers the auto-update, lsup.sh running as root extracts and executes the attacker's install.sh without verifying it, yielding root. No public exploit code is identified at time of analysis, and success requires winning a TOCTOU race against the root update process.