Aktuel situation: PHP2Shell. To kritiske PHP-sårbarheder (CVSS 9,2) tillader skadelig kode uden login. Rettelser siden 21.10.2026.Hvad der skal gøres nu →

LiteSpeed og LSAPI: sådan opdaterer I PHP

LiteSpeed bruger egne lsphp-pakker og lader PHP-processer leve længe i hukommelsen. Sådan indspiller I PHP-opdateringen og sikrer, at alle processer virkelig genstarter.

Status 4 min. læsetidServer & hosting

Kort sagt: En LiteSpeed PHP-opdatering berører de lsphp-pakker, via hvilke LiteSpeed udfører PHP med LSAPI. Efter opdateringen skal alle lsphp-processer genstarte, og netop det sker ikke altid automatisk med webserveren ved LiteSpeed. Kontrollér pakkestatus og processernes starttidspunkt, før I klassificerer serveren som patchet.

LiteSpeed, LSAPI og lsphp kort forklaret

LiteSpeed Web Server og den frie variant OpenLiteSpeed udfører ikke PHP som modul, men via en egen grænseflade ved navn LSAPI. PHP-programmerne hertil hedder lsphp og kommer som regel fra egne pakkekilder, pr. version f.eks. lsphp83 eller lsphp84. På paneler som cPanel, Plesk eller CyberPanel kan der desuden være panelets egne PHP-pakker i spil.

PHP2Shell omfatter sårbarhederne CVE-2026-109618 og CVE-2026-109619 i PHP selv, hver vurderet til CVSS v4.0 9,2. PHP-projektet nævner udtrykkeligt LiteSpeed blandt de berørte driftsformer. Rettet er versionerne 8.5.12, 8.4.27, 8.3.36 og 8.2.35.

LiteSpeed PHP-opdatering: kortlæg beholdningen

Find først ud af, hvilke lsphp-versioner der er installeret, og hvilke af dem der er i brug. Følgende kommandoer læser kun. Stier og pakkenavne er eksempler og afhænger af installation og distribution.

# Installerede lsphp-versioner (typisk sti)
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

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

# Kørende lsphp-processer med starttidspunkt
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep

Afstem listen med konfigurationen: Hvilken virtuel host bruger hvilken External App Handler? I LiteSpeed-fladen finder I det under Server Configuration og de virtuelle hosts' indstillinger. Versioner uden tildeling bør I alligevel opdatere eller fjerne.

Vær opmærksom på backports og pakkekilder

Kommer lsphp fra en ekstern kilde, afgør dennes pakkestatus. Leverer et panel eller en distribution PHP, gælder dennes oplysning. I begge tilfælde kan en rettelse leveres som backport uden at det viste versionsnummer ændres. Kontrollér derfor pakkeudbyderens ændringshenvisninger, og lad jer i tvivlstilfælde bekræfte status. Versionsnummeret alene er intet bevis.

Genstart: hvad der kommer an på ved LiteSpeed

LiteSpeed kan drive PHP i den såkaldte Detached Mode. Her kører lsphp-processer videre uafhængigt af webserveren, så websites svarer hurtigere efter en genstart af webserveren. Ved en sikkerhedsopdatering er det en faldgrube: Webserveren er genstartet, men gamle PHP-processer med den sårbare kode forbliver aktive.

# Genstart webserveren (sti som eksempel)
/usr/local/lsws/bin/lswsctrl restart

# Kontrollér bagefter: Er alle lsphp-processer yngre end opdateringen?
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep

Viser en lsphp-proces et starttidspunkt før opdateringen, så afslut den målrettet. LiteSpeed starter ved den næste forespørgsel en ny proces med den opdaterede kode. Planlæg dette trin uden for spidsbelastningstiderne, for den første forespørgsel pr. website kan bagefter tage lidt længere tid.

Vigtigt

Efter PHP-opdateringen er en server først patchet, når ingen lsphp-proces er ældre end opdateringen. Notér kontrollen med dato og klokkeslæt.

Midlertidige foranstaltninger, indtil patchen er der

Er der for en lsphp-version endnu ingen rettet pakke tilgængelig, anbefaler php.net midlertidige foranstaltninger. De giver ikke fuldstændig beskyttelse. Sæt værdierne i php.ini for den pågældende lsphp-version eller i serverkonfigurationen, ikke i .user.ini og ikke via ini_set().

; php.ini for den berørte lsphp-version (sti afhænger af installationen)
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

Med upload-funktion angiver php.net post_max_size = 32M, og upload_max_filesize skal ligge under. På PHP 8.5 kommer fatal_error_backtraces=0 til. Hukommelsesgrænser sætter I via cgroups, på CloudLinux f.eks. via de dér foreskrevne limits, ikke via RLIMIT_AS eller RLIMIT_DATA. Bagefter følger igen genstarten af alle lsphp-processer. Yderligere detaljer: Akutforanstaltninger uden patch. BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler at tage en webserver midlertidigt af nettet, hvis opdateringen ikke kan gennemføres med det samme.

Efter opdateringen

En patch lukker sårbarheden, men fjerner ikke skadelig software, der allerede er smuglet ind, og beviser ikke, at intet skete før. Gem adgangsprotokollerne fra og med 20.10.2026, og undersøg websites for nye PHP-filer i upload-mapper, fremmede administratorkonti og usædvanlige udgående forbindelser. Henvisninger til den løbende overvågning giver vores sikkerhedsovervågning. På cPanel-servere med LiteSpeed er det desuden værd at se på cPanel og WHM.

Mange LiteSpeed-servere kører under et hostingpanel som cPanel, Plesk, DirectAdmin eller CyberPanel. Panelet bestemmer så, fra hvilken kilde lsphp kommer, og hvordan opdateringer indspilles. Foretag i så fald opdateringer via panelet eller dets pakkekilder, og installér ikke parallelt fra en anden kilde, ellers bliver det svært at gennemskue, hvilken udgave der faktisk kører. Notér desuden, hvilket website der drives med hvilken lsphp-version. På servere med mange kundekonti er denne liste grundlaget for målrettet at informere kontoindehavere og efter opdateringen stikprøvevis kontrollere, at websites kører fejlfrit. Websites, der kræver en ikke længere understøttet PHP-version, hører på en egen liste, fordi der ikke kommer en officiel opdatering til dem.

Hvordan hjælper PHP SOS konkret?

  • Vi opgør alle lsphp-versioner, pakkekilder og handler-tildelinger på jeres server.
  • Via PHP-patch-servicen opdaterer vi, afslutter alle gamle lsphp-processer og dokumenterer beviset.
  • Hvor der endnu ikke findes en pakke, sætter vi de midlertidige værdier serverdækkende og begrænser hukommelsen via cgroup.
  • Vi undersøger websites for spor af et angreb og sikrer logs.

Ofte stillede spørgsmål

Er LiteSpeed berørt af PHP2Shell?

Ja. Ifølge PHP-projektet hører LiteSpeed til de berørte driftsformer. Sårbarhederne ligger i PHP selv, som LiteSpeed udfører via LSAPI. Afgørende er derfor lsphp-pakkernes status.

Hvorfor kører der stadig gamle lsphp-processer efter opdateringen?

LiteSpeed kan lade PHP-processer køre videre uafhængigt af webserveren for at spare indlæsningstid. En genstart af webserveren afslutter dem afhængigt af driftsformen ikke med det samme. Kontrollér derfor starttidspunktet for alle lsphp-processer.

Gælder det også for OpenLiteSpeed?

Grundlæggende ja. OpenLiteSpeed bruger også lsphp via LSAPI. Stier, pakkekilder og administrationsflade er forskellige, princippet med opdatering, genstart og kontrol er det samme.

Hjælper LiteSpeed-cachen mod sårbarheden?

Nej. En sidecache leverer nok nogle sider uden PHP, men forespørgsler, der når PHP, kan stadig angribes. En cache er ingen erstatning for PHP-opdateringen.

Kilder

Akut kontakt

Hver time tæller. Skriv til os nu.

Beskriv kort system, PHP-version og observation. Vi vender tilbage, afklarer situationen og arbejder på afstand, indtil hændelsen er afsluttet og dokumenteret.

Akut hjælp