Aktuellt läge: PHP2Shell. Två kritiska PHP-sårbarheter (CVSS 9,2) tillåter skadlig kod utan inloggning. Patchar sedan den 21 oktober 2026.Vad som bör göras nu →

LiteSpeed och LSAPI: uppdatera PHP

LiteSpeed använder egna lsphp-paket och håller PHP-processer kvar länge i minnet. Så installerar ni PHP-uppdateringen och ser till att alla processer verkligen startas om.

Aktualitet 4 min läsningServer och webbhotell

Kort sagt: En LiteSpeed PHP-uppdatering gäller de lsphp-paket via vilka LiteSpeed kör PHP med LSAPI. Efter uppdateringen måste alla lsphp-processer startas om, och just det sker med LiteSpeed inte alltid automatiskt tillsammans med webbservern. Kontrollera paketstatus och processernas starttid innan ni klassar servern som patchad.

LiteSpeed, LSAPI och lsphp kort förklarat

LiteSpeed Web Server och den fria varianten OpenLiteSpeed kör PHP inte som modul utan via ett eget gränssnitt som heter LSAPI. PHP-programmen för det heter lsphp och kommer oftast från egna paketkällor, per version till exempel lsphp83 eller lsphp84. På paneler som cPanel, Plesk eller CyberPanel kan dessutom panelens egna PHP-paket vara inblandade.

PHP2Shell omfattar sårbarheterna CVE-2026-109618 och CVE-2026-109619 i PHP självt, vardera bedömd med CVSS v4.0 9,2. PHP-projektet nämner uttryckligen LiteSpeed bland de berörda driftlägena. Åtgärdade är versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35.

LiteSpeed PHP-uppdatering: kartlägg beståndet

Ta först reda på vilka lsphp-versioner som är installerade och vilka av dem som används. Följande kommandon läser bara. Sökvägar och paketnamn är exempel och beror på installation och distribution.

# Installerade lsphp-versioner (typisk sökväg)
ls -d /usr/local/lsws/lsphp*/ 2>/dev/null
for p in /usr/local/lsws/lsphp*/bin/lsphp; do echo "$p"; "$p" -v | head -1; done

# Paketstatus (exempel)
rpm -qa | grep -E '^lsphp[0-9]+' | sort
dpkg -l | grep -E 'lsphp[0-9]+'

# Körande lsphp-processer med starttid
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep

Stäm av listan mot konfigurationen: vilken virtuell värd använder vilken External App Handler? I LiteSpeeds gränssnitt hittar ni det under Server Configuration och inställningarna för de virtuella värdarna. Versioner utan koppling bör ni ändå uppdatera eller ta bort.

Beakta backports och paketkällor

Kommer lsphp från en tredjepartskälla avgör dess paketstatus. Levererar en panel eller en distribution PHP gäller dess uppgift. I båda fallen kan en rättning levereras som backport utan att det visade versionsnumret ändras. Kontrollera därför paketleverantörens ändringsanvisningar och låt er vid osäkerhet få statusen bekräftad. Versionsnumret ensamt är inget belägg.

Omstart: vad som är viktigt med LiteSpeed

LiteSpeed kan köra PHP i det som kallas Detached Mode. Då körs lsphp-processerna vidare oberoende av webbservern, så att webbplatser svarar snabbare efter en omstart av webbservern. För en säkerhetsuppdatering är det en fallgrop: webbservern är omstartad, men gamla PHP-processer med den sårbara koden förblir aktiva.

# Starta om webbservern (sökväg som exempel)
/usr/local/lsws/bin/lswsctrl restart

# Kontrollera därefter: är alla lsphp-processer yngre än uppdateringen?
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep

Visar en lsphp-process en starttid före uppdateringen avslutar ni den riktat. LiteSpeed startar vid nästa förfrågan en ny process med den uppdaterade koden. Planera det här steget utanför de tider då belastningen är högst, eftersom den första förfrågan per webbplats därefter kan ta lite längre tid.

Viktigt

Efter PHP-uppdateringen är en server först patchad när ingen lsphp-process är äldre än uppdateringen. Dokumentera kontrollen med datum och klockslag.

Tillfälliga åtgärder tills patchen finns

Om det för en lsphp-version ännu inte finns något åtgärdat paket rekommenderar php.net tillfälliga åtgärder. De ger inget fullständigt skydd. Sätt värdena i php.ini för respektive lsphp-version eller i serverkonfigurationen, inte i .user.ini och inte via ini_set().

; php.ini för den berörda lsphp-versionen (sökväg beroende på installation)
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

Med uppladdningsfunktion anger php.net post_max_size = 32M, med upload_max_filesize under det värdet. På PHP 8.5 tillkommer fatal_error_backtraces=0. Minnesgränser sätter ni via cgroups, på CloudLinux till exempel via de gränser som finns där, inte via RLIMIT_AS eller RLIMIT_DATA. Därefter följer åter en omstart av alla lsphp-processer. Fler detaljer: Omedelbara åtgärder utan patch. BSI (den tyska förbundsmyndigheten för informationssäkerhet) rekommenderar att en webbserver tillfälligt tas offline om uppdateringen inte kan göras direkt.

Efter uppdateringen

En patch stänger sårbarheten men tar inte bort skadlig programvara som redan har förts in och bevisar inte att ingenting hände tidigare. Spara åtkomstloggarna från och med den 20 oktober 2026 och kontrollera webbplatserna med avseende på nya PHP-filer i uppladdningskataloger, främmande administratörskonton och ovanliga utgående anslutningar. Anvisningar om löpande övervakning ger vår säkerhetsövervakning. På cPanel-servrar med LiteSpeed lönar det sig dessutom att titta på cPanel och WHM.

Många LiteSpeed-servrar körs under en hostingpanel som cPanel, Plesk, DirectAdmin eller CyberPanel. Panelen avgör då varifrån lsphp kommer och hur uppdateringar installeras. Gör uppdateringarna i så fall via panelen eller dess paketkällor och installera inte parallellt från en andra källa, annars blir det svårt att följa upp vilken version som faktiskt körs. Anteckna dessutom vilken webbplats som drivs med vilken lsphp-version. På servrar med många kundkonton är den listan grunden för att kunna informera kontoinnehavare riktat och efter uppdateringen stickprovsvis kontrollera att webbplatserna fungerar felfritt. Webbplatser som kräver en PHP-version som inte längre stöds hör hemma på en egen lista, eftersom ingen officiell uppdatering kommer för dem.

Hur hjälper PHP SOS konkret?

  • Vi kartlägger alla lsphp-versioner, paketkällor och handlertilldelningar på er server.
  • Via PHP-patchtjänsten uppdaterar vi, avslutar alla gamla lsphp-processer och dokumenterar beläggen.
  • Där ännu inget paket finns tillgängligt sätter vi de tillfälliga värdena serveromfattande och begränsar minnet via cgroup.
  • Vi kontrollerar webbplatserna med avseende på spår av ett angrepp och säkrar loggarna.

Vanliga frågor

Berörs LiteSpeed av PHP2Shell?

Ja. Enligt PHP-projektet hör LiteSpeed till de berörda driftlägena. Sårbarheterna finns i PHP självt, som LiteSpeed kör via LSAPI. Avgörande är därför statusen på lsphp-paketen.

Varför körs gamla lsphp-processer kvar efter uppdateringen?

LiteSpeed kan låta PHP-processer fortsätta köra oberoende av webbservern för att spara laddningstid. En omstart av webbservern avslutar dem beroende på driftläge inte omedelbart. Kontrollera därför starttiden för alla lsphp-processer.

Gäller det även OpenLiteSpeed?

I princip ja. OpenLiteSpeed använder också lsphp via LSAPI. Sökvägar, paketkällor och administrationsgränssnitt skiljer sig, men principen med uppdatering, omstart och kontroll är densamma.

Hjälper LiteSpeed-cachen mot sårbarheten?

Nej. En sidcache levererar visserligen vissa sidor utan PHP, men förfrågningar som når PHP förblir angripbara. En cache ersätter inte PHP-uppdateringen.

Källor

Direktkontakt

Varje timme räknas. Skriv till oss nu.

Beskriv kort system, PHP-version och observation. Vi hör av oss, klarlägger läget och arbetar på distans tills incidenten är avslutad och dokumenterad.

Direkthjälp