PHP2Shell: ce este și cum remediezi vulnerabilitățile

Informații verificate la 22 octombrie 2026. PHP2Shell desemnează două vulnerabilități critice din motorul PHP, pentru care au fost publicate actualizări de securitate pe 21 octombrie. În anumite condiții, un atacator fără cont pe site poate executa cod cu drepturile procesului PHP. Riscul privește infrastructura pe care rulează aplicația, inclusiv site-uri WordPress sau aplicații dezvoltate la comandă.

Remedierea principală: instalează pachetul PHP care include corecțiile și repornește procesele afectate. Actualizarea WordPress, a pluginurilor sau a dependențelor Composer rămâne utilă, dar nu înlocuiește actualizarea motorului PHP. Vezi anunțul oficial PHP.

Ce este PHP2Shell și unde apare problema

• CVE-2026-109618: gestionarea epuizării memoriei poate lăsa date interne într-o stare incomplet inițializată; procesarea lor ulterioară poate permite executarea de cod. Detalii în avizul PHP pentru coruperea memoriei la OOM.

• CVE-2026-109619: un proces PHP reutilizat poate păstra referințe către memorie eliberată după o cerere. O cerere ulterioară poate ajunge să folosească acea stare invalidă. Detalii în avizul privind starea globală rămasă între cereri.

Pentru Apache cu mod_php a fost demonstrat un atac înainte de executarea codului aplicației. PHP-FPM și alte moduri de rulare trebuie evaluate separat; prezența unui formular de autentificare sau folosirea unui framework nu confirmă protecția. Condițiile și variantele diferă între configurații.

Ce versiuni PHP includ corecțiile

Primele versiuni corectate publicate de proiectul PHP pentru ramurile susținute sunt:

• PHP 8.2: 8.2.35

• PHP 8.3: 8.3.36

• PHP 8.4: 8.4.27

• PHP 8.5: 8.5.12

Folosește aceste versiuni sau o versiune ulterioară corectată din ramura aleasă. Pentru PHP 8.1 și mai vechi, verifică existența unui backport oferit de furnizor și planifică migrarea la o ramură susținută. Un backport punctual nu reactivează suportul oficial al proiectului PHP pentru o versiune veche.

Contează și revizia pachetului. Distribuțiile pot aplica patch-ul păstrând numărul versiunii de bază. De exemplu, Ubuntu 24.04 listează pachetul corectat 8.3.6-0ubuntu0.24.04.13. Verifică pachetul complet în USN-8948-1, nu doar numărul afișat de PHP.

Cum verifici ce rulează efectiv pe site

php -v
php --ini

Aceste comenzi identifică PHP din terminal și configurația sa. Site-ul poate folosi alt binar, altă versiune sau alt fișier ini. Confirmă și runtime-ul care servește domeniul: configurația pool-ului PHP-FPM, modulul Apache sau serviciul din container. Nu publica un fișier phpinfo() pentru această verificare.

Inventariază și subdomeniile, mediile de test și celelalte instanțe. Notează pentru fiecare runtime versiunea completă a pachetului, sursa actualizării și serviciul repornit.

Cum remediezi, în funcție de găzduire

Hosting administrat sau cPanel

Cere furnizorului confirmarea aplicării corecțiilor pentru ambele CVE-uri și a repornirii proceselor. Simplul fapt că ai selectat „PHP 8.4” în panou nu dovedește instalarea patch-ului. cPanel publică separat actualizările pentru PHP intern și EasyApache; consultă buletinul oficial cPanel.

Server administrat de tine

Verifică backup-ul și compatibilitatea aplicației, apoi instalează actualizările din sursa de pachete corespunzătoare sistemului. Pentru Ubuntu administrat prin APT, Canonical recomandă:

sudo apt update
sudo apt upgrade

Repornește apoi serviciul care folosește PHP: de exemplu, php8.3-fpm pentru acel pool sau apache2 când folosești mod_php. Numele depinde de instalare. Urmează instrucțiunile Canonical; comenzile APT nu sunt o procedură universală pentru serverele cPanel.

Containere Docker

Actualizează imaginea PHP la un build corectat, reconstruiește imaginile proprii și redeployează serviciile. O simplă repornire a vechiului container păstrează imaginea vulnerabilă. Compose pull descarcă imaginile, iar Compose up poate recrea serviciile folosind imaginea schimbată. Verifică fiecare replică.

Ce poți face temporar și cum confirmi remedierea

Regulile WAF și restricțiile cererilor pot reduce anumite căi de atac. Nu confirmă remedierea motorului PHP. Recomandarea temporară memory_limit = -1 are un compromis real: elimină limita PHP, dar poate afecta disponibilitatea serverului dacă resursele nu sunt controlate separat. Nu o aplica automat; urmează recomandările echipei de cercetare și prioritizează patch-ul.

După actualizare, confirmă pachetul folosit de site și repornirea proceselor, apoi testează autentificarea, încărcarea fișierelor și fluxurile esențiale. Examinează logurile și modificările neobișnuite. Un patch nu elimină fișierele malițioase sau conturile create de un atacator înainte de actualizare.

Dacă suspectezi o compromitere, păstrează dovezile, limitează expunerea și cere investigarea incidentului. Recuperarea poate necesita refacerea mediului dintr-o sursă verificată și înlocuirea credențialelor expuse, după controlarea incidentului.

Ai nevoie de ajutor cu inventarierea runtime-urilor, actualizarea sau verificările după intervenție? Vezi serviciile Nikba de suport, securitate și infrastructură. Pentru întreținerea aplicației, citește și ghidul nostru despre optimizarea WordPress.