Yesterday we wrote about the urgent LiteSpeed Web Server Enterprise advisory, the one where a low-privilege website user on a shared server could walk through CageFS account isolation and end up with root. This morning, September 16, LiteSpeed sent a second advisory: the first fix did not close every door. There is a new build, 6.3.7 build 1, and it addresses another corner case in the same area of the code. Every GillyTech server was on the new build within the hour. Then we wrote this.
What Changed Since Yesterday
The original 6.3.7 release hardened three things: how lscgid (the helper that runs scripts as the right user account) authenticates requests, how the server validates internal redirect URLs, and whether .htaccess files can set internal environment variables. The new build goes back to the second item. LiteSpeed’s own words are that it addresses “another corner case in internal redirect URL validation.”
An internal redirect is when the web server quietly hands a request from one location to another without the browser ever seeing it. It is the mechanism behind things like pretty permalinks and custom error pages. If the server trusts a redirect target it should not, a request can end up running in a context it was never supposed to reach. Yesterday’s patch tightened that validation. Today’s patch tightens it again, which tells you the first pass missed an input that still slipped through.
LiteSpeed is explicit about one point, so we will be too: if you updated yesterday, you are not done. The advisory says to apply the new build even if you already moved to 6.3.7 following the first notice.
Affected and Fixed Versions
- Affected: Any LiteSpeed Web Server Enterprise install not on the latest available release. That includes servers that upgraded to the original 6.3.7 build yesterday.
- Fixed: 6.3.7 build 1, released September 16, 2026.
- Not this advisory: OpenLiteSpeed and the LiteSpeed Cache WordPress plugin are separate products and are not what this notice is about.
- Still no CVE number. No tracking identifier has been assigned to either advisory as of this morning, and there is still no published list of indicators of compromise.
How to Apply the New Build
If you run your own LiteSpeed Enterprise server, force the upgrade again as root. The same command from yesterday pulls the newest build of 6.3.7:
/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7Then check the version string, and this time look at the build number, not just the version:
/usr/local/lsws/bin/lshttpd -vYou want to see 6.3.7 with build 1. A plain 6.3.7 from yesterday is the version this advisory is telling you to leave. If someone else administers your server, the question to send them is the same one as yesterday with one word added: “Are we on LiteSpeed 6.3.7 build 1?”
The Same Post-Upgrade Check, Again
LiteSpeed repeats its request from yesterday: after upgrading, look for unusual CGI activity, check piped logging (where the server hands log lines to another program instead of writing them to a file), and confirm that server-level logs are still being written. Do it again after this build too. A patch that changes how requests are validated can change what your logging pipeline sees, and the one thing worse than being exposed for a day is not being able to prove afterward that nobody used it.
Two Advisories in Two Days Is the Normal Part
It is tempting to read a second patch as a sign that something went wrong at LiteSpeed. We read it the other way. A vendor that finds a remaining gap in its own fix and ships again the next morning, with a plain notice saying “update again,” is doing exactly what you want a vendor to do. Security fixes for input validation bugs are often iterative, because the first patch closes the case that was reported and a closer look finds a sibling.
What that means for you is that patching is not a one-time event you can check off on Monday. It is a process that has to run every time the vendor says so, including the second time in two days, including when it is inconvenient. That is the entire job of a managed host.
What Happened on Our Side
Advisory in, every server moved to 6.3.7 build 1, versions verified by hand, logging confirmed, then this article. Same order as yesterday, same order as the ConfigServer Firewall flaw two weeks ago and the cPanel flaw last month. We will keep doing it in that order for as long as the advisories keep coming, and they will keep coming.
If you are a HyperPress client, there is nothing you need to do. Your server is on the current build and has been since this morning. If you are hosted somewhere else and you are not sure whether your host applied yesterday’s update, let alone today’s, that uncertainty is itself the answer. GillyTech runs managed WordPress hosting where security updates go out within the hour, every time. Schedule a call and we will walk you through what moving over looks like.
