Situația actuală: PHP2Shell. Două vulnerabilități critice PHP (CVSS 9.2) permit cod malițios fără autentificare. Patchuri din 21.10.2026.Ce este de făcut acum →

LiteSpeed și LSAPI: actualizarea PHP

LiteSpeed folosește pachete lsphp proprii și ține procesele PHP mult timp în memorie. Iată cum instalați actualizarea PHP și vă asigurați că toate procesele repornesc cu adevărat.

Stadiu 5 min de cititServer & hosting

Pe scurt: O actualizare PHP LiteSpeed privește pachetele lsphp prin care LiteSpeed execută PHP prin LSAPI. După actualizare trebuie să repornească toate procesele lsphp, iar la LiteSpeed acest lucru nu se întâmplă întotdeauna automat odată cu serverul web. Verificați starea pachetelor și ora de pornire a proceselor înainte de a considera serverul actualizat.

LiteSpeed, LSAPI și lsphp pe scurt

LiteSpeed Web Server și varianta liberă OpenLiteSpeed nu execută PHP ca modul, ci printr-o interfață proprie numită LSAPI. Programele PHP pentru aceasta se numesc lsphp și provin de obicei din surse proprii de pachete, pentru fiecare versiune, de exemplu lsphp83 sau lsphp84. În panouri precum cPanel, Plesk sau CyberPanel pot interveni suplimentar pachete PHP proprii ale panoului.

PHP2Shell cuprinde vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 din PHP însuși, fiecare evaluată cu CVSS v4.0 9.2. Proiectul PHP include explicit LiteSpeed printre modurile de operare afectate. Sunt remediate versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35.

Actualizare PHP LiteSpeed: faceți inventarul

Aflați mai întâi ce versiuni lsphp sunt instalate și care dintre ele sunt folosite. Comenzile următoare doar citesc. Căile și numele pachetelor sunt exemple și depind de instalare și distribuție.

# Versiunile lsphp instalate (cale tipică)
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

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

# Procesele lsphp în execuție, cu ora de pornire
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep

Comparați lista cu configurația: ce virtual host folosește ce External App Handler? În interfața LiteSpeed găsiți acest lucru la Server Configuration și în setările virtual host-urilor. Versiunile fără atribuire ar trebui totuși actualizate sau eliminate.

Țineți cont de backporturi și de sursele de pachete

Dacă lsphp provine dintr-o sursă terță, starea pachetelor acesteia este decisivă. Dacă un panou sau o distribuție livrează PHP, se aplică indicațiile acestora. În ambele cazuri, o corecție poate fi livrată ca backport fără ca numărul de versiune afișat să se schimbe. Verificați de aceea notele de modificări ale furnizorului de pachete și, în caz de îndoială, cereți confirmarea stării. Numărul de versiune singur nu este o dovadă.

Repornirea: ce contează la LiteSpeed

LiteSpeed poate opera PHP în așa-numitul Detached Mode. În acest mod, procesele lsphp rulează mai departe independent de serverul web, pentru ca site-urile să răspundă mai repede după o repornire a serverului web. Pentru o actualizare de securitate aceasta este o capcană: serverul web a fost repornit, dar procesele PHP vechi, cu codul vulnerabil, rămân active.

# Reporniți serverul web (calea ca exemplu)
/usr/local/lsws/bin/lswsctrl restart

# Apoi controlați: sunt toate procesele lsphp mai noi decât actualizarea?
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep

Dacă un proces lsphp arată o oră de pornire anterioară actualizării, opriți-l țintit. LiteSpeed pornește la următoarea cerere un proces nou, cu codul actualizat. Planificați acest pas în afara orelor de vârf, deoarece prima cerere pentru fiecare site poate dura puțin mai mult după aceea.

Important

După actualizarea PHP, un server este actualizat abia când niciun proces lsphp nu este mai vechi decât actualizarea. Consemnați controlul cu data și ora.

Măsuri provizorii până apare patchul

Dacă pentru o versiune lsphp nu este încă disponibil un pachet corectat, php.net recomandă măsuri provizorii. Ele nu oferă o protecție completă. Setați valorile în php.ini al versiunii lsphp respective sau în configurația serverului, nu în .user.ini și nu prin ini_set().

; php.ini al versiunii lsphp afectate (calea depinde de instalare)
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

Cu funcție de încărcare, php.net indică post_max_size = 32M, cu upload_max_filesize sub această valoare. Pe PHP 8.5 se adaugă fatal_error_backtraces=0. Limitele de memorie le setați prin cgroups, pe CloudLinux de exemplu prin limitele prevăzute acolo, nu prin RLIMIT_AS sau RLIMIT_DATA. Apoi urmează din nou repornirea tuturor proceselor lsphp. Alte detalii: Măsuri imediate fără patch. BSI (Oficiul Federal German pentru Securitatea Informațiilor) recomandă scoaterea temporară din rețea a unui server web dacă actualizarea nu este posibilă imediat.

După actualizare

Un patch închide vulnerabilitatea, dar nu elimină programele malițioase deja introduse și nu dovedește că înainte nu s-a întâmplat nimic. Păstrați jurnalele de acces începând cu 20.10.2026 și verificați site-urile pentru fișiere PHP noi în directoarele de încărcare, conturi de administrator străine și conexiuni de ieșire neobișnuite. Indicații despre monitorizarea continuă oferă monitorizarea noastră de securitate. Pe serverele cPanel cu LiteSpeed merită în plus o privire asupra cPanel și WHM.

Multe servere LiteSpeed rulează sub un panou de hosting precum cPanel, Plesk, DirectAdmin sau CyberPanel. Panoul stabilește atunci din ce sursă provine lsphp și cum se instalează actualizările. În acest caz, efectuați actualizările prin panou sau prin sursele sale de pachete și nu instalați în paralel dintr-o a doua sursă, altfel devine greu de reconstituit ce variantă rulează de fapt. Consemnați în plus ce site funcționează cu ce versiune lsphp. Pe serverele cu multe conturi de clienți, această listă este baza pentru a informa țintit titularii de conturi și pentru a verifica prin sondaj, după actualizare, dacă site-urile funcționează fără erori. Site-urile care cer o versiune PHP care nu mai este acceptată aparțin unei liste separate, deoarece pentru ele nu apare nicio actualizare oficială.

Cum ajută PHP SOS concret?

  • Inventariem toate versiunile lsphp, sursele de pachete și atribuirile de handler ale serverului dumneavoastră.
  • Prin serviciul de patch PHP actualizăm, oprim toate procesele lsphp vechi și documentăm dovada.
  • Acolo unde încă nu este disponibil un pachet, setăm valorile provizorii la nivel de server și limităm memoria prin cgroup.
  • Verificăm site-urile pentru urme ale unui atac și salvăm jurnalele.

Întrebări frecvente

Este LiteSpeed afectat de PHP2Shell?

Da. Potrivit proiectului PHP, LiteSpeed se numără printre modurile de operare afectate. Vulnerabilitățile se află în PHP însuși, pe care LiteSpeed îl execută prin LSAPI. Contează de aceea starea pachetelor lsphp.

De ce mai rulează procese lsphp vechi după actualizare?

LiteSpeed poate lăsa procesele PHP să ruleze independent de serverul web, pentru a economisi timp de încărcare. O repornire a serverului web nu le oprește imediat, în funcție de modul de operare. Verificați de aceea ora de pornire a tuturor proceselor lsphp.

Se aplică și la OpenLiteSpeed?

În principiu da. OpenLiteSpeed folosește de asemenea lsphp prin LSAPI. Căile, sursele de pachete și interfața de administrare diferă, dar principiul actualizare, repornire și control rămâne același.

Ajută cache-ul LiteSpeed împotriva vulnerabilității?

Nu. Un cache de pagini livrează unele pagini fără PHP, dar cererile care ajung la PHP rămân vulnerabile. Un cache nu înlocuiește actualizarea PHP.

Surse

Contact imediat

Fiecare oră contează. Scrieți-ne acum.

Descrieți pe scurt sistemul, versiunea PHP și ce ați observat. Ne vom face auziți, clarificăm situația și lucrăm la distanță până când incidentul este încheiat și documentat.

Ajutor imediat