Pe scurt: Cine administrează singur un server root sau un vServer trebuie să-l securizeze singur după PHP2Shell: să aducă pachetele PHP la o stare corectată, să repornească toate procesele PHP și să verifice rezultatul. Operatorul centrului de date se ocupă de regulă doar de hardware, virtualizare și rețea. Apoi merită să întăriți serverul pe termen lung.
Responsabilitatea dumneavoastră la propriul server
La un server root sau vServer neadministrat închiriați putere de calcul, nu servicii de îngrijire. Sistemul de operare, serverul web, PHP, baza de date, firewallul, copiile de siguranță și monitorizarea sunt în mâna dumneavoastră. Pentru conducere și proprietari asta înseamnă: dacă nimeni din firmă sau de la un prestator nu a preluat în mod explicit aceste sarcini, nu le face nimeni.
PHP2Shell face acest lucru vizibil. Cele două vulnerabilități CVE-2026-109618 și CVE-2026-109619 se află în PHP însuși și permit executarea de cod fără autentificare. Proiectul PHP a publicat pe 21.10.2026 versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35. BSI (Oficiul Federal German pentru Securitatea Informațiilor) recomandă actualizarea imediată și, dacă nu este posibilă, scoaterea temporară a serverului web din rețea.
Securizare server VPS: verificați inventarul și starea pachetelor
Mai întâi faceți-vă o imagine despre ce versiuni PHP sunt instalate și din ce sursă provin. Multe servere folosesc, pe lângă pachetele distribuției, surse suplimentare de pachete. Comenzile următoare doar citesc. Numele pachetelor sunt exemple.
# Debian/Ubuntu: pachetele PHP instalate și proveniența lor
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Ce binare PHP există, de fapt?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
Numărul de versiune singur nu este suficient. Distribuțiile livrează adesea corecțiile de securitate ca backport, iar numărul afișat rămâne atunci mai vechi. Decisiv este jurnalul de modificări al pachetului.
# Debian/Ubuntu (numele pachetului ca exemplu)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# Familia RHEL (numele pachetului ca exemplu)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
Un ghid detaliat găsiți la Verificarea versiunii PHP și a stării patchului.
Instalați actualizarea și reînnoiți toate procesele
Instalați actualizările prin gestionarul de pachete și reporniți apoi fiecare serviciu care încarcă PHP. În funcție de construcție, acestea sunt PHP-FPM, Apache cu mod_php, LiteSpeed sau un server de aplicații. Fișierele noi de pe disc nu sunt suficiente cât timp procese vechi rulează în memorie.
# Găsiți serviciile cu PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Afișați procesele cu ora de pornire
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: recunoașteți programele cu biblioteci depășite (dacă este instalat)
needrestart -r l
Fiecare proces relevant ar trebui să fi pornit după actualizare. Util este instrumentul needrestart pe sistemele Debian, care arată serviciile cu biblioteci depășite. Detalii despre repornire descrie articolul Repornirea PHP-FPM și a tuturor workerilor.
Un patch nu elimină programele malițioase introduse înainte de actualizare. Păstrați jurnalele serverului web începând cu 20.10.2026 și verificați serverul pentru urme înainte de a-l considera curat.
Pentru o primă căutare de urme se potrivesc câteva verificări care nu modifică nimic. Căutați fișiere PHP create sau modificate în directoarele web începând cu 17.10.2026, intrări necunoscute în crontab-urile tuturor utilizatorilor, utilizatori de sistem și chei SSH noi, precum și procese ale utilizatorului serverului web care mențin conexiuni de ieșire.
# Fișiere PHP modificate din 17.10.2026 (calea ca exemplu)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Conexiuni de rețea cu procesul aferent
ss -tupn
Niciuna dintre aceste verificări nu dovedește de una singură o intruziune, iar un rezultat gol nu dovedește contrariul. Ele arată însă dacă este necesară o investigație mai profundă. Lucrați pe copii ale jurnalelor și nu modificați fișierele suspecte până când starea sistemului nu este salvată. Dacă găsiți ceva, calea sigură este o investigație ordonată. În acest caz, nu opriți pur și simplu serverul și nu-l reinstalați imediat, deoarece se pierd urme importante pentru evaluarea obligațiilor de notificare și pentru o eventuală plângere penală.
Întăriți serverul pe termen lung
După patchul acut urmează securizarea de bază. Ea nu previne orice vulnerabilitate, dar limitează paguba și scurtează timpul de reacție data viitoare. S-au dovedit utile aceste puncte:
- Accese: SSH doar cu cheie, fără autentificare directă ca root, interfețe de administrare accesibile doar din rețele cunoscute.
- Firewall: deschideți doar porturile de care este cu adevărat nevoie, restrângeți conexiunile de ieșire ale serverului web.
- Configurația PHP: dezactivați funcțiile periculoase,
open_basedirpentru fiecare site, pool-uri și utilizatori proprii pentru fiecare aplicație. - Drepturi de fișiere: serverul web nu are voie să scrie codul programului, directoarele de încărcare nu execută PHP.
- Actualizări: instalați automat actualizările de securitate, planificați ferm repornirea și controlul.
- Copii de siguranță: copii după regula 3-2-1, cel puțin o copie în afara serverului și protejată împotriva modificării.
- Jurnale: colectați jurnalele central și păstrați-le suficient de mult.
Cum arată o copie de siguranță fiabilă descrie articolul Copii de siguranță după regula 3-2-1. Ca cadru pentru companii se potrivește IT-Grundschutz de la BSI.
Când un server administrat este alegerea mai bună
Un server propriu merită dacă cineva preia îngrijirea în mod fiabil: urmărește actualizările, evaluează situații precum PHP2Shell, poate reacționa și noaptea. Dacă această capacitate lipsește, are sens fie un server administrat (managed), fie un contract fix de mentenanță. În ambele cazuri este important să consemnați în scris responsabilitățile. Mai multe găsiți la Server administrat: clarificați responsabilitatea.
Cum ajută PHP SOS concret?
- Inventariem toate instalările PHP, sursele de pachete și serviciile serverului dumneavoastră și evaluăm starea reală a patchurilor.
- Instalăm actualizările, repornim toate procesele și documentăm rezultatul.
- Verificăm serverul pentru urme de compromitere și salvăm jurnalele pentru o analiză ulterioară.
- În cadrul securizării serverelor configurăm corect accesele, firewallul, pool-urile PHP și drepturile.
- La cerere preluăm îngrijirea continuă printr-un contract de mentenanță de securitate.
Întrebări frecvente
Actualizează centrul meu de date automat vServer-ul?
La serverele root și vServer neadministrate, de regulă nu. Furnizorul pune la dispoziție hardware sau virtualizare și rețea, iar sistemul de operare și toate serviciile de pe el le administrați dumneavoastră. În caz de îndoială, verificați contractul.
Sunt suficiente actualizările automate de securitate?
Ajută, dar nu înlocuiesc controlul. Actualizările automate nu repornesc întotdeauna procesele PHP în execuție și adesea nu acoperă pachetele din surse terțe. După fiecare actualizare de securitate, verificați starea pachetelor și orele de pornire ale proceselor.
Cum aflu dacă pachetul meu conține un backport?
În jurnalul de modificări al pachetului și în anunțurile de securitate ale distribuției dumneavoastră. Dacă acolo apare numărul CVE, corecția este inclusă, chiar dacă numărul versiunii pare mai vechi. Dacă intrarea lipsește, clarificați situația înainte de a considera serverul actualizat.
Ce fac dacă pentru versiunea mea PHP nu apare niciun patch?
PHP 8.1 și mai vechi nu mai primesc actualizări oficiale. Aplicați măsurile provizorii conform php.net, planificați rapid trecerea la o versiune acceptată și, dacă este necesar, scoateți temporar serverul din rețea, conform recomandării BSI.