# PHP2Shell: ce trebuie să știi despre CVE-2026-109618 și CVE-2026-109619

> PHP a publicat remedieri pentru PHP2Shell. Vezi versiunile corectate, ce verifici la hosting și de ce actualizarea WordPress sau Laravel nu este suficientă.

- **Autor:** GabrielDev
- **Publicat:** 2026-10-22
- **Categorie:** Cybersecurity
- **URL:** https://inonline.ro/cybersecurity/php2shell-cve-2026-109618-109619-actualizare-php

---

**Proiectul PHP a publicat pe 21 octombrie 2026 actualizări de securitate pentru CVE-2026-109618 și CVE-2026-109619, cunoscute împreună sub numele PHP2Shell.** Vulnerabilitățile pot permite executarea de cod de la distanță fără autentificare. Pentru administratorii de site-uri, prioritatea este identificarea runtime-ului PHP folosit efectiv de aplicație și instalarea remedierii corespunzătoare.

Versiunile upstream care includ corecțiile sunt **PHP 8.2.35, 8.3.36, 8.4.27 și 8.5.12**, potrivit [anunțului oficial PHP](https://www.php.net/archive/2026.php#2026-10-21-5). Pachetele distribuțiilor Linux pot avea alte numere de versiune deoarece integrează remedieri prin backport. O versiune aparent mai veche nu dovedește singură că un server este vulnerabil.

*Informații verificate la 22 octombrie 2026. Acesta este un articol de actualitate și un ghid defensiv de verificare, nu un raport de audit asupra unui anumit server. Starea pachetelor și informațiile despre exploatare trebuie reverificate în anunțurile furnizorilor.*

## Ce trebuie să știi imediat

- Problemele sunt în PHP, nu exclusiv într-un plugin WordPress sau într-un pachet Laravel.
- Instalațiile care procesează cereri web trebuie evaluate; utilizarea PHP-FPM nu justifică ignorarea actualizării.
- Actualizarea aplicației nu înlocuiește actualizarea runtime-ului vulnerabil.
- Verifică versiunea completă a pachetului și confirmă că procesele active folosesc componentele actualizate.
- Aplicarea patch-ului și investigarea unei posibile compromiteri sunt activități distincte.

Pentru cine folosește găzduire administrată, primul pas practic este o solicitare către furnizor. Pentru un VPS administrat intern, responsabilitatea revine echipei care gestionează sistemul, serviciile PHP și containerele. Nu începe cu un script de exploatare găsit online: inventarul, buletinul furnizorului și verificarea instalării oferă un traseu mai sigur pentru remediere.

## Ce sunt CVE-2026-109618 și CVE-2026-109619

**CVE-2026-109618** privește coruperea memoriei în tratarea situațiilor out-of-memory, prescurtate OOM. Pe scurt, o întrerupere produsă în timp ce anumite date interne sunt doar parțial inițializate poate lăsa o stare invalidă, utilizată ulterior în curățarea cererii. Descrierea tehnică este publicată în [avizul de securitate al proiectului PHP pentru CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w).

**CVE-2026-109619** privește o stare internă rămasă activă după eliberarea memoriei de care depindea. În anumite condiții, reutilizarea unui worker poate face ca o cerere ulterioară să întâlnească acea stare înainte de resetarea normală. Vezi [avizul oficial pentru CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp).

Distincția contează: nu discutăm despre două denumiri pentru aceeași eroare de configurare. Sunt două probleme care trebuie acoperite de remediere. „Am schimbat o setare PHP” nu este echivalent cu „am instalat corecțiile pentru ambele CVE-uri”.

RCE înseamnă *remote code execution*, adică posibilitatea executării de cod de la distanță. „Fără autentificare” înseamnă că atacatorul nu trebuie să dețină un cont în aplicație pentru scenariile descrise. Nu înseamnă că orice instalare este exploatată identic sau că simpla existență a PHP dovedește o compromitere deja produsă.

## Cât de grave sunt și cine trebuie să verifice

[Canonical indică un scor CVSS 4.0 de 9,2](https://ubuntu.com/blog/php2shell-vulnerability-fixes-available) pentru ambele vulnerabilități. Scorul exprimă severitatea tehnică, nu probabilitatea exactă ca un anumit site să fi fost atacat. Nu îl transforma într-un procent de risc pentru afacerea ta.

Proiectul PHP include în avertizare instalații web precum PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Configurația mod_php este considerată cu risc deosebit, deoarece există o demonstrație de atac înainte de execuția codului aplicației. Această precizare nu oferă o excepție generală celorlalte moduri de rulare.

Analiza trebuie să includă site-uri publice, panouri de administrare, aplicații interne expuse accidental, containere și produse care încorporează PHP. Un inventar limitat la pagina principală poate rata un subdomeniu vechi sau un serviciu secundar. Pentru organizarea infrastructurii, vezi și [diferențele dintre shared hosting, VPS și cloud](https://inonline.ro/hosting-vps/shared-hosting-vs-vps-vs-cloud-ce-ai-nevoie-de-fapt).

Red Hat descrie diferențe de exploatabilitate între mod_php și anumite scenarii PHP-FPM în [evaluarea CVE-2026-109618](https://access.redhat.com/security/cve/cve-2026-109618). De aceea, informațiile furnizorului și configurația efectivă contează. Nu combina scoruri din versiuni CVSS diferite și nu folosi o evaluare specifică unui produs pentru a declara toate celelalte instalații sigure.

## Ce versiuni PHP conțin remedierea

Ramură upstreamVersiune cu remedierea anunțatăVerificare necesarăPHP 8.28.2.35Buildul instalat și runtime-ul folosit de sitePHP 8.38.3.36Buildul instalat și runtime-ul folosit de sitePHP 8.48.4.27Buildul instalat și runtime-ul folosit de sitePHP 8.58.5.12Buildul instalat și runtime-ul folosit de sitePHP 8.1 și mai vechiVerificare separată la furnizor sau migrareSuportul upstream normal a încetat; nu presupune că există un pachet oficial nou pentru fiecare ramură
Tabelul indică versiunile publicate pentru incident, nu recomandă revenirea de la o versiune ulterioară remediată. Dacă folosești un pachet întreținut de distribuție, urmează buletinul acelei distribuții și identifică revizia completă. Nu instala o versiune arbitrară dintr-un depozit necunoscut doar pentru ca numărul să semene cu cel din tabel.

Un exemplu concret: [Ubuntu USN-8948-1](https://ubuntu.com/security/notices/USN-8948-1) listează pentru Ubuntu 24.04 LTS pachete PHP 8.3 remediate la versiunea `8.3.6-0ubuntu0.24.04.13`. Numărul de bază 8.3.6 nu este 8.3.36, dar revizia Ubuntu include corecția. Acest exemplu se aplică pachetelor și distribuției indicate în buletin, nu oricărui executabil care afișează 8.3.6.

Pentru ramurile vechi, existența unui backport punctual nu echivalează cu reluarea suportului complet. Separă intervenția de urgență de planul de migrare către o ramură întreținută. Nu amâna remedierea imediată până la o rescriere integrală a aplicației.

## Există exploatare observată sau doar demonstrații?

În [analiza publicată pe 21 octombrie](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/), Amazon Threat Intelligence raportează o tentativă de exploatare observată în telemetria MadPot din 17 octombrie 2026 și alte tentative înainte de dezvăluirea publică. Autorii precizează că analiza continuă și că nu este clar dacă acele tentative ar fi reușit pe sisteme reale.

Diferența dintre **tentativă observată**, **exploatare reușită** și **compromiterea site-ului tău** trebuie păstrată. Raportul justifică verificarea istoricului înainte de ziua anunțului, dar nu dovedește că toate site-urile PHP au fost compromise. Nu publicăm un număr de victime fără o sursă verificabilă și nu deducem absența atacurilor din lipsa alertelor unui singur server.

Pentru echipa care investighează, data primei activități observate public este un reper de căutare, nu o limită sigură a incidentului. Păstrează logurile disponibile și documentează cât istoric ai efectiv. Un jurnal incomplet trebuie marcat ca limitare, nu prezentat drept dovadă că nu s-a întâmplat nimic.

## WordPress și Laravel: de ce actualizarea aplicației nu este suficientă

WordPress și Laravel rulează peste PHP. O actualizare de plugin, temă sau dependențe poate fi importantă pentru alte probleme, dar nu înlocuiește corecția runtime-ului. Pentru acest incident, întrebarea este ce build PHP procesează cererile și dacă acel build include remedierea.

În Laravel, versiunea executată de `php artisan` poate diferi de versiunea poolului PHP-FPM la care trimite Nginx. La fel, un panou de hosting poate permite selectarea unor versiuni diferite pentru domenii diferite. Verificarea unui singur binar CLI nu inventariază automat toate site-urile găzduite pe server.

Recomandare operațională: notează pentru fiecare aplicație domeniul, serviciul web, poolul sau containerul, sursa pachetului și persoana responsabilă. Pentru procesele de lungă durată, include și modul în care sunt repornite după actualizare. Nu modifica secretele Laravel sau schema bazei de date doar pentru că incidentul implică PHP. Pentru context despre administrarea aplicației, vezi [ghidul Laravel](https://inonline.ro/web-programare/laravel-pentru-incepatori-de-la-zero-la-primul-proiect-live).

## Checklist pentru verificarea și remedierea serverului

- **Identifică toate instalațiile relevante.** Include domenii, subdomenii, pooluri PHP, containere și servicii furnizate de terți.
- **Stabilește proveniența runtime-ului.** Distribuție Linux, depozit extern, imagine de container sau compilare proprie.
- **Compară cu buletinul furnizorului.** Folosește versiunea completă a pachetului și confirmarea pentru ambele CVE-uri.
- **Pregătește intervenția.** Verifică backupul, accesul administrativ și funcțiile critice care trebuie testate după actualizare.
- **Instalează remedierea prin procedura platformei.** Nu amesteca instrucțiuni pentru distribuții sau panouri diferite.
- **Activează componentele actualizate.** Repornește ori înlocuiește serviciile și instanțele relevante conform procedurii furnizorului.
- **Testează aplicația.** Pagini, autentificare, formulare, încărcări de fișiere și fluxuri comerciale, după funcționalitățile reale.
- **Înregistrează dovada finală.** Pachetul, instanțele verificate, momentul intervenției și rezultatele testelor.

Comenzile de mai jos sunt exemple de inventariere, nu exploatează vulnerabilitatea și nu instalează actualizări. Primele două descriu numai PHP CLI; ultima comandă este specifică sistemelor care folosesc dpkg.

```
php -v
php --ini
dpkg-query -W 'php*'

```

Nu publica ieșirea completă a inventarului sau un fișier `phpinfo()` accesibil pe internet pentru a cere ajutor. Partajează informațiile necesare prin canalul de suport autorizat. Pentru runtime-ul web, administratorul trebuie să urmărească configurația serverului către serviciul care procesează efectiv cererile.

Într-un mediu cu containere, reconstruirea imaginii nu înlocuiește singură instanțele deja pornite. Verifică imaginea distribuită și replica activă. Dacă ai mai multe noduri, confirmă fiecare grup, nu doar primul server pe care s-a încheiat actualizarea.

## Ce îi ceri firmei de hosting

Dacă nu administrezi sistemul de operare, nu trebuie să inventezi comenzi de actualizare. Trimite furnizorului o solicitare precisă, adaptată domeniului tău:

> Vă rog să confirmați dacă runtime-ul PHP folosit de domeniul meu include remedierile pentru CVE-2026-109618 și CVE-2026-109619. Care este versiunea completă a pachetului sau buildului și buletinul de securitate aferent? Au fost repornite ori înlocuite procesele relevante? Există alte pooluri sau versiuni PHP active pentru subdomeniile contului?

Un răspuns de tipul „folosiți PHP 8” nu este suficient de precis. Cere confirmarea buildului remediat, nu parole sau detalii interne inutile. Păstrează răspunsul și data lui în evidența tehnică a site-ului. Dacă furnizorul nu poate confirma remedierea, discută măsurile temporare și termenul intervenției.

## Dacă patch-ul nu poate fi instalat imediat

[CERT-EU recomandă actualizarea urgentă](https://cert.europa.eu/publications/security-advisories/2026-018/) și, unde aceasta nu este posibilă, luarea în considerare a izolării aplicațiilor expuse public până la aplicarea și verificarea remedierii. Decizia trebuie coordonată cu responsabilul serviciului și cu impactul operațional.

Un WAF sau o regulă temporară poate face parte din apărarea pe mai multe niveluri, dar nu reprezintă dovada că runtime-ul a fost corectat. Nu prezentăm în acest articol o modificare de configurare drept soluție completă pentru ambele vulnerabilități. Evită schimbările copiate fără evaluare, mai ales asupra limitelor de resurse: pot introduce probleme de disponibilitate.

Recomandare pentru echipă: consemnează ce măsură temporară ai aplicat, ce funcții afectează, cine o verifică și când revii la remedierea definitivă. O excepție fără termen și fără responsabil poate rămâne activă mult după incident. Pentru regulile generale de protejare a unui site, poți consulta și [ghidul de securitate WordPress](https://inonline.ro/cybersecurity/cum-iti-protejezi-site-ul-wordpress-de-atacuri-comune).

## După actualizare: verifică și eventualele semne de incident

Patch-ul închide problema tehnică remediată, dar nu dovedește că sistemul era curat înaintea intervenției. Dacă există indicii de compromitere, tratează separat răspunsul la incident. Nu șterge imediat fișierele suspecte și logurile de care ai putea avea nevoie pentru investigație.

Ca verificări operaționale, examinează modificările neașteptate de fișiere, procesele neobișnuite, conturile administrative nou apărute și conexiunile externe care nu corespund funcționării aplicației. Corelează semnalele cu istoricul de deployment și cu activitățile administratorilor. Un fișier modificat nu dovedește singur PHP2Shell; poate avea o explicație legitimă sau poate indica alt incident.

Dacă dovezile justifică izolarea și recuperarea, implică echipa de securitate sau furnizorul de răspuns la incidente. Restaurarea dintr-un backup trebuie să țină cont de momentul în care copia a fost creată și de remedierea runtime-ului înainte de reexpunere. Rotirea credențialelor se planifică în funcție de expunerea constatată, fără a afișa secrete în tichete sau rapoarte publice.

## Întrebări frecvente despre PHP2Shell

### Dacă site-ul funcționează normal, înseamnă că nu este afectat?
Nu. Funcționarea aparent normală nu confirmă existența patch-ului și nici absența unui incident. Verifică buildul PHP, informațiile furnizorului și procesele active.

### Este suficient să actualizez WordPress sau Laravel?
Nu pentru remedierea acestor probleme din runtime. Actualizează componenta PHP relevantă prin procedura furnizorului, apoi verifică funcționarea aplicației.

### PHP-FPM este automat în siguranță?
Nu. Avertizarea PHP include și PHP-FPM. Scenariile de exploatare diferă după configurație, dar această diferență nu este un motiv pentru a omite verificarea și actualizarea.

### De ce Ubuntu poate afișa o versiune mai veche, dar remediată?
Distribuțiile pot integra corecția într-un pachet cu aceeași versiune de bază și o revizie nouă. Compară identificatorul complet cu buletinul distribuției, nu doar primele cifre din php -v.

### Un WAF înlocuiește actualizarea PHP?
Nu. Poate contribui la reducerea expunerii, în funcție de protecția disponibilă, dar nu înlocuiește remedierea runtime-ului și verificarea activării ei.

### Trebuie să rulez un exploit ca să verific serverul?
Nu pentru inventariere și confirmarea patch-ului. Folosește evidența pachetelor și confirmarea furnizorului. Testele de exploatare pot afecta disponibilitatea și nu trebuie executate pe sisteme fără autorizare.

## Prioritatea este confirmarea remedierii, nu doar bifarea unei actualizări

Pentru proprietarul unui site, rezultatul util este o confirmare verificabilă: runtime-ul care servește aplicația conține patch-urile pentru ambele CVE-uri, procesele relevante au fost actualizate și funcțiile esențiale au trecut verificarea. Pentru echipa tehnică, intervenția se încheie cu documentarea instanțelor verificate și cu evaluarea separată a semnelor de incident. Nu folosi acest articol pentru a declara un server sigur fără verificarea lui efectivă.