CVE-2026-104474: OpenLiteSpeed lsup.sh runs a nobody-writable tarball as root - patch 1.9.3

The Situation

On 3 October 2026 VulnCheck published CVE-2026-104474 against OpenLiteSpeed. The record is a local privilege escalation in the same updater operators already type on every LiteSpeed box: admin/misc/lsup.sh.

Vendor/CNA one-liner, verbatim:

OpenLiteSpeed before 1.9.3 contains a local privilege escalation vulnerability in admin/misc/lsup.sh that runs unverified update packages from a nobody-writable directory as root. Attackers controlling the nobody web process can replace the package in /usr/local/lsws/autoupdate/ before extraction, so its install.sh runs as root on the next update.

Facts that are on the CVE record, not our lab:

Product: litespeedtech / openlitespeed, versions 0 lessThan 1.9.3. Floor is 1.9.3.
CWE-367 TOCTOU race.
CVSS 3.1 6.7 MEDIUM - AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H (VulnCheck, Primary on NVD).
CVSS 4.0 5.4 MEDIUM - AV:L/AC:H/AT:P/PR:L/UI:P.
datePublic: 2026-09-29 (same day LiteSpeed shipped 1.9.3). CVE JSON published 2026-10-03T00:16:35.413Z.
Finder credit: FCI Cloud Security (CVE credits + the 1.9.3 release log).

Primary sources:

CVE-2026-104474 / CVE list JSON
NVD
VulnCheck advisory
OpenLiteSpeed 1.9.x release log - V1.9.3 2026-09-29
Fix commit: 468523ce ("Check in 1.9.3")
Vulnerable line cited by the CNA: lsup.sh @ v1.9.2 L538 (tar xf ols.tgz)

This is not the September LiteSpeed Enterprise tenant-to-root (the 6.3.7 / CageFS advisory). Different binary, different CVE, different floor. If you patched Enterprise last month, you still have to look at OpenLiteSpeed boxes - CyberPanel, DirectAdmin OLS, and one-click VPS images.

Version floor

Affected: OpenLiteSpeed before 1.9.3
Fixed: 1.9.3, released 2026-09-29. Release-log security lines, verbatim: "[Security] Strengthen HTTP/2/HTTP/3 header validation." and "[Security] Security hardening for update script (Credit to “FCI CLoud Security”)."

Check what the box actually runs:

cat /usr/local/lsws/VERSION
/usr/local/lsws/bin/openlitespeed -v
# many installs also answer:
/usr/local/lsws/bin/lshttpd -v

Anything that prints a version below 1.9.3 is still on the vulnerable updater. Do not trust the control panel's "LiteSpeed is up to date" badge without reading VERSION.

Why this is a shared-hosting problem anyway

The CVSS is Medium, not 9.9. Read the vector before you paste it into a customer ticket:

AV:L / PR:L - local, low privilege. The CNA names the nobody web process, not an unauthenticated internet client.
AC:H / UI:R / AT:P - high complexity, user interaction (or a scheduled update) required, attack requirements present. The window is "after the tarball lands in autoupdate/, before lsup.sh extracts it."
Impact is still High/High/High if the race hits: install.sh from that tarball runs as root.

On a typical OLS/CyberPanel VPS the web worker is nobody (or the equivalent unprivileged uid the vhost pool runs as). That uid is exactly the class of access you already assume after one popped WordPress. The CNA claim is that /usr/local/lsws/autoupdate/ is writable to that uid, so a tenant who can write there can swap ols.tgz for a package whose install.sh they control. The next lsup.sh run - auto-update or an admin -f - is the detonation.

That is not unauthenticated RCE. It is web-uid to root, gated on the updater actually running. Treat it as a patch-now on multi-tenant OLS, and as a "do it this week" on single-tenant VPS images that still ship < 1.9.3.

What the public patch actually changed

We are not publishing a PoC. The fix is a public git commit, so the delta is fair game.

lsup.sh in 1.9.2 (LSUPVERSION=v2.84-04/12/2024):

Downloads with wget / curl -L -k / fetch into ${LSWSHOME}/autoupdate (fallback /usr/src).
Size-checks the tarball (testsz=1000000) and extracts it with no checksum.
cd into the extracted tree and runs ./install.sh as the user who invoked lsup.sh - root, on every normal install.
Also chmod 777 on a freshly self-updated lsup.sh.

lsup.sh in 1.9.3 (LSUPVERSION=v2.85-09/26/2026, commit 468523ce):

Staging directory is ${LSWSHOME}/admin/update, created mode 0700, refuses a symlink.
Downloads forced to HTTPS (curl --proto =https, wget --max-redirect=0).
SHA-256 of ols.tgz against ols.tgz.sha256 before extract.
Version string allow-list; extract path must be a real directory, not a symlink.
Lock file moved off /tmp.

If your box is still on 1.9.2, you are running the first script. Patching is replacing that script.

Patch

Vendor path is the updater, forced to the floor:

/usr/local/lsws/admin/misc/lsup.sh -f -v 1.9.3
cat /usr/local/lsws/VERSION
/usr/local/lsws/bin/openlitespeed -v

Confirm 1.9.3 or later. If you pin a version or disable auto-update, the -f -v is the whole point - do not wait for the next channel drop.

CyberPanel / DirectAdmin OLS: same binary path on a stock install (/usr/local/lsws/...). Run it as root on the node, then re-read VERSION. If your panel wraps the upgrade, still verify on disk.

No workaround is listed in the CVE record. Restricting writes to /usr/local/lsws/autoupdate/ is a reasonable compensating control until you patch; it is not a substitute for 1.9.3, and we did not test it as a complete mitigation.

Honesty / what we are not claiming

Vendor-reported (treat as CNA/vendor claims, not our lab):

Unverified package from a nobody-writable autoupdate/ directory, extracted and installed as root on the next lsup.sh run.
Affected < 1.9.3, fixed in 1.9.3. Credit FCI Cloud Security.
CVSS 6.7 / 5.4 and the vectors above come from VulnCheck (disclosure@vulncheck.com). NVD status at fetch time 4 Oct 2026 03:31 UTC: Received, lastModified equal to published - no NVD Primary metric yet.

Unverified / not claimed:

Not in CISA KEV. Catalog pulled 4 Oct 2026: dateReleased on the JSON we fetched, 1733 entries. Newest additions are Zammad (2026-10-02), FortiMail (2026-10-01), Cisco SD-WAN (2026-09-30). CVE-2026-104474 is not listed. Absence from KEV is not proof of non-exploitation.
GitHub advisory enrichment on GHSA-4qqw-wg6j-834r: EPSS 0.085% / percentile 0.267%. That is a probability model, not a sighting.
No in-the-wild exploitation is asserted by VulnCheck, NVD, or CISA. We did not reproduce the race.
This post has no replacement tarball, no install.sh payload, no inotify one-liner. The public commit is enough to patch; it is not a recipe.
LiteSpeed Web Server Enterprise is not in the affected block. Do not treat 1.9.3 as a substitute for the September 6.3.7 Enterprise floor, and do not treat 6.3.7 as covering OLS.
The 1.9.3 log also mentions HTTP/2/HTTP/3 header validation. That is a separate security line. This CVE is the update-script item only.
Changelog spelling is “FCI CLoud Security” (capital L). CVE credits “FCI Cloud Security”. Same finder.

After you patch

Record pre/post cat /usr/local/lsws/VERSION in the change ticket.
ls -ld /usr/local/lsws/admin/update /usr/local/lsws/autoupdate - after 1.9.3 you want the new 0700 update dir, not a world-writable staging area.
If the box was below 1.9.3 and untrusted code ran as the web user, this is a compromise-assessment question, not only a patch question. Look for unexpected root-owned files dropped around /usr/local/lsws/, extra keys in /root/.ssh/authorized_keys, and crontab/systemd units you did not write. The CNA did not publish IOCs.
Do not roll back across 1.9.3. The updater rewrite is the fix.

If you would rather not be the person who finds out install.sh ran twice, this is the class of web-server CVE we patch on managed OLS/CyberPanel before the tweet. Managed hosting · contact.