PHP2Shell: vulnerabilitatea critică PHP și cum te protejezi

Pe 21 octombrie 2026, echipa PHP a publicat versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35 pentru două vulnerabilități PHP critice: CVE-2026-109618 și CVE-2026-109619, numite colectiv PHP2Shell. Ambele au scor CVSS v4.0 de 9.2 și permit, în condițiile descrise de advisory, execuție de cod la distanță (RCE) fără autentificare. Pe Apache cu mod_php, atacul a fost demonstrat înainte ca vreo linie din aplicația ta să ruleze.

Dacă ai un site WordPress, un magazin WooCommerce, o aplicație Laravel, un panou de administrare vechi sau un ERP intern scris în PHP, articolul ăsta e pentru tine. Găsești mai jos ce s-a întâmplat exact, cine e expus, cum verifici în 10 minute dacă serverul tău rulează o versiune vulnerabilă, ce faci dacă nu poți actualiza azi și cum cauți urme de compromitere după patch.

Ce s-a întâmplat pe 21 octombrie 2026

Cronologia contează, fiindcă explică de ce fereastra de reacție a fost atât de scurtă. Pe 20 octombrie, echipa de securitate PHP a anunțat în avans, pe php.net și pe lista oss-security, o lansare de securitate programată pentru miercuri, 21 octombrie, la 14:00 UTC, cu două vulnerabilități critice, ambele evaluate CVSS v4.0 9.2. Anunțul preciza că lansarea se poate grăbi dacă detaliile devin publice sau apar dovezi de exploatare activă.

Detaliile n-au rezistat până la ora anunțată. Potrivit The Hacker News, Cloudflare a activat reguli WAF implicite la 03:02 UTC și a raportat trafic de atac împotriva clienților săi încă dinainte de patch, cu atacatori care își modificau payload-urile ca să ocolească regulile. watchTowr raporta la 11:26 UTC că nu vede exploatare în mediul real, iar la 14:19 UTC raporta deja „încercări de exploatare activă” pentru ambele CVE-uri.

Cine a descoperit vulnerabilitățile

Advisory-urile de pe GitHub (GHSA-w8hw-w9fx-j79w și GHSA-6wmf-4rv5-p3rp) creditează cercetători de la Wiz Research, Calif și echipa Codex Security de la OpenAI. Numele PHP2Shell vine de la Wiz, potrivit Google Cloud. Fix-urile au fost scrise de dezvoltatori din echipa PHP core.

De ce scorul e 9.2 și nu 10

Vectorul CVSS publicat este AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H. Tradus: atacul vine prin rețea, nu cere cont și nu cere ca un utilizator să dea click, iar impactul asupra confidențialității, integrității și disponibilității e maxim. Ce coboară scorul e complexitatea ridicată (AC:H) și existența unor precondiții (AT:P): exploit-ul depinde de build-ul PHP, de extensii, de frontend și de layout-ul memoriei. Un scor de 10.0 a circulat înainte de lansare, dar nu e evaluarea oficială PHP.

Nu te liniști pe „complexitate ridicată”. În practică, înseamnă că un exploit generic nu merge din prima pe orice server. Nu înseamnă că atacatorii nu au timp să-l ajusteze pentru configurațiile cele mai comune, iar mod_php cu setări implicite e exact o configurație comună.

Cum funcționează cele două vulnerabilități

Nu ai nevoie de detaliile exploit-ului ca să te aperi. Ai nevoie de mecanism, fiindcă mecanismul explică de ce unele măsuri temporare ajută și altele nu.

CVE-2026-109618: corupere de memorie la out-of-memory

PHP folosește longjmp() ca să iasă brusc din contextul curent când rămâne fără memorie (OOM) și să abandoneze cererea. Problema apare când alocarea eșuează în timp ce datele interne ale cererii sunt doar parțial inițializate. Codul de cleanup tratează apoi datele invalide ca fiind valide, iar de acolo se ajunge la corupere de memorie și, cu efort, la execuție de cod.

Declanșatorul descris de Rapid7 e o cerere multipart construită special (formular cu upload de fișiere) care epuizează memoria chiar și când pare să respecte limitele configurate. Pe mod_php, cleanup-ul rulează chiar și când pornirea cererii eșuează, de aceea atacul funcționează înainte să ruleze codul aplicației. PHP-FPM omoară worker-ul când pornirea eșuează, ceea ce blochează secvența respectivă, dar analiza sursei sugerează că FPM poate fi vulnerabil după o pornire reușită.

Fix-ul elimină longjmp() pentru OOM. În loc de asta, PHP declanșează un OOM „soft” amânat până la următorul punct sigur din mașina virtuală și un OOM „hard” cu _exit() la un prag mai sus.

CVE-2026-109619: stare globală rămasă între cereri

Un worker PHP (proces FPM sau child Apache) servește multe cereri la rând. Între ele, PHP ține stare globală: erori, sesiune, obiecte, starea extensiilor. Vulnerabilitatea apare când o parte din această stare încă indică spre memorie eliberată la finalul cererii anterioare. Cererea următoare, pe același worker, citește valoarea veche înainte ca inițializarea normală s-o reseteze. Rezultatul e un use-after-free (CWE-416) exploatabil.

Advisory-ul confirmă două căi:

• Backtrace-urile la erori fatale din PHP 8.5 (fatal_error_backtraces, activ implicit), pe mod_php.
• Session upload progress (activ implicit), pe mod_php și pe FPM. Aplicația ta nu trebuie să cheme session_start() ca să fie expusă.

De ce contează modelul de worker

Ambele bug-uri țin de ciclul de viață al unei cereri într-un proces care trăiește mai mult decât cererea. Asta e și ideea care face PHP rapid: procesul rămâne cald, extensiile rămân încărcate. Același tipar apare în orice arhitectură în care resurse partajate trec de la un client la altul. Dacă rulezi o aplicație cu mai mulți clienți pe aceeași infrastructură, merită să citești și despre izolarea datelor într-o arhitectură multi-tenant: un worker care „ține minte” ceva din cererea anterioară e exact tipul de scurgere pe care izolarea trebuie să-l prevină.

Cine e afectat de vulnerabilitatea PHP

Pe scurt: aproape oricine servește cereri web cu PHP și nu a actualizat după 21 octombrie.

Versiuni afectate și versiuni reparate

Potrivit Google Cloud, sunt vulnerabile toate versiunile de la 5.4 până la 8.5.11. Pentru 7.4, 8.0 și 8.1, proiectul PHP a publicat ramuri minimale de backport în sursă, dar nu release-uri. Dacă rulezi PHP 7.x pe un server propriu, practic depinzi de distribuția Linux sau de un vendor de suport extins.

SAPI-uri expuse și unde e riscul maxim

Anunțul oficial listează explicit: PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Riscul cel mai mare e pe mod_php, unde există un exploit demonstrat în care o cerere neautentificată declanșează atacul înainte de orice cod al aplicației. Pe FPM există de asemenea RCE demonstrat, dar pe alte căi și cu precondiții în plus (o eroare fatală provocată în aplicație, apoi o cerere ulterioară pe același worker).

PHP rulat doar din linia de comandă (cron-uri, scripturi artisan, workeri de coadă) nu servește cereri HTTP, deci nu e vectorul principal. Totuși, actualizezi binarul o singură dată pentru tot sistemul, așa că nu are sens să-l tratezi separat.

WordPress, Laravel și restul ecosistemului

Vulnerabilitatea e în runtime-ul PHP, nu în framework. WordPress.org a confirmat că nu e necesar și nu e planificat niciun update de WordPress pentru aceste probleme. La fel, composer update nu repară nimic: pachetele tale pot fi la zi și serverul tot vulnerabil. Ce trebuie actualizat e interpretorul PHP de pe server sau din imaginea de container.

Asta înseamnă că problema te privește și dacă aplicația ta principală nu e în PHP. Uită-te la tot ce rulează lângă ea: blogul WordPress de pe subdomeniu, phpMyAdmin rămas expus, un webmail, un panou de administrare moștenit, un ERP intern construit acum zece ani sau un mic script de formular pe un VPS uitat.

Cum verifici în 10 minute dacă ești vulnerabil

Ordinea corectă e inventar, apoi versiune, apoi confirmarea că procesele care rulează chiar folosesc binarul nou.

Inventarul: unde rulează PHP la tine

Fă o listă cu toate serverele, containerele și conturile de hosting pe care rulează PHP. Surse rapide:

• Hosting partajat sau managed: panoul de control (cPanel, Plesk, DirectAdmin) îți arată versiunea PHP per domeniu.
• WordPress: Tools → Site Health → Info → Server.
• Servere proprii: pachetele instalate (dpkg -l | grep php pe Debian/Ubuntu, rpm -qa | grep php pe RHEL/Alma/Rocky).
• Containere: caută FROM php: în fiecare Dockerfile din repo-uri și în pipeline-urile de CI.
• Scanare externă: header-ul X-Powered-By: PHP/... (dacă expose_php e activ) sau un inventar de rețea. runZero, de exemplu, sugerează interogarea vendor:=PHP AND product:=PHP în software inventory.

Verificarea versiunii, cu o capcană

Pe un server propriu, versiunea o vezi rapid:

1# CLI version (may differ from the web SAPI)
2php -v
3
4# FPM binary version, adjust to your installed branch
5php-fpm8.3 -v
6
7# Package version, which is what matters on distro builds
8apt-cache policy php8.3-fpm
9rpm -q php-fpm

1# CLI version (may differ from the web SAPI)
2php -v
3
4# FPM binary version, adjust to your installed branch
5php-fpm8.3 -v
6
7# Package version, which is what matters on distro builds
8apt-cache policy php8.3-fpm
9rpm -q php-fpm

Capcana: distribuțiile Linux fac backport la fix-uri fără să schimbe numărul de versiune upstream. Un pachet Debian sau Ubuntu poate afișa tot „8.3.x” mai vechi și să conțină totuși patch-ul. Verifică în advisory-ul distribuției (Debian Security Tracker, Ubuntu USN, Red Hat RHSA) numărul exact de pachet care repară CVE-2026-109618 și CVE-2026-109619 și compară-l cu ce ai instalat. Proiectul PHP a precizat că distribuțiile și vendorii LTS au primit patch-urile în avans.

Încă un detaliu din anunțul oficial: repository-ul întreținut voluntar rpms.remirepo.net nu urma să aibă update-uri în ziua lansării. Dacă depinzi de el, echipa PHP recomandă pachetele distribuției sau compilarea din sursă.

Confirmă că workerii rulează binarul nou

Un pachet actualizat pe disc nu ajută dacă procesele vechi încă rulează în memorie. Fiecare worker trebuie repornit:

1# PHP-FPM: full restart, then confirm the master process start time
2sudo systemctl restart php8.3-fpm
3ps -o pid,lstart,cmd -C php-fpm8.3 | head -5
4
5# Apache with mod_php: the module lives in the parent process,
6# so a graceful reload is not enough after a library upgrade
7sudo systemctl restart apache2   # httpd on RHEL-based systems

1# PHP-FPM: full restart, then confirm the master process start time
2sudo systemctl restart php8.3-fpm
3ps -o pid,lstart,cmd -C php-fpm8.3 | head -5
4
5# Apache with mod_php: the module lives in the parent process,
6# so a graceful reload is not enough after a library upgrade
7sudo systemctl restart apache2   # httpd on RHEL-based systems

Pe containere, reconstruiește imaginea pornind de la o imagine de bază actualizată (docker pull pe tag-ul de bază, apoi build fără cache) și redeploy. Dacă ai fixat imaginea pe un digest, actualizează digest-ul. Pe platformele cloud, comportamentul diferă: Google Cloud spune că App Engine standard cu PHP 8.2+ s-a actualizat automat, Cloud Run doar dacă ai activat actualizarea automată a imaginii de bază, iar App Engine flexible cere redeploy.

Ce faci în funcție de tipul de hosting

Răspunsul depinde de cine controlează binarul PHP. Diagrama de mai jos te duce la acțiunea corectă în trei întrebări.

Hosting managed sau partajat

Aici hostingul controlează PHP-ul, deci tu nu instalezi nimic. Ce faci: verifici pagina de status sau scrii la suport și ceri confirmare explicită că versiunea PHP a site-ului tău e patch-uită. Nu te mulțumi cu „suntem protejați la nivel de CDN”. O regulă WAF e un strat în plus, nu un fix. Dacă panoul îți permite să alegi versiunea PHP, mută site-ul pe 8.2 sau mai nou.

Unii furnizori au ales soluții radicale: potrivit unei compilări a declarațiilor publicate de Codeable, un furnizor a oprit temporar serviciile de web hosting ca să le patch-uiască, iar altul a dezactivat PHP preventiv în timpul actualizării. Dacă site-ul tău a fost indisponibil câteva ore pe 21 octombrie, probabil asta a fost cauza.

VPS sau server propriu

Aici e responsabilitatea ta și e urgent. Pașii:

1. Instalează pachetele PHP actualizate din distribuție (sau compilează 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 din sursă).
2. Repornește complet PHP-FPM, Apache și orice alt proces care încarcă PHP (FrankenPHP, LiteSpeed, supervisord cu workeri).
3. Confirmă versiunea pachetului și ora de pornire a proceselor.
4. Treci la verificarea de compromitere (secțiunea de mai jos), fiindcă exploatarea a început înainte de patch.

PHP 8.1 sau mai vechi pe server propriu

Asta e situația grea. Proiectul PHP nu mai lansează versiuni pentru 8.1 și mai vechi. Ai trei variante: un pachet patch-uit de la distribuție sau de la un vendor de suport extins, un build din ramurile de backport publicate de proiectul PHP, sau upgrade la 8.2+. Dacă niciuna nu e posibilă imediat, WordPress.org citează recomandarea NCSC din Marea Britanie: „Where immediate remediation is not feasible, organisations should consider taking the system offline.” Adică, ia în calcul să oprești serverul până faci upgrade.

Upgrade-ul de la 7.4 sau 8.0 la 8.2+ poate strica teme, plugin-uri sau cod vechi. Fă-l întâi pe o copie de staging, cu backup complet înainte. Și reține că PHP 8.2 iese din suport pe 31 decembrie 2026, deci dacă tot faci migrarea, țintește 8.4 sau 8.5.

În spatele unui WAF (Cloudflare, Cloud Armor și alții)

Cloudflare a activat reguli pe toate planurile. Pe planurile cu managed rules, verifică că regulile relevante sunt în modul de blocare, nu doar de logare. Google recomandă în Cloud Armor categoriile File Upload și RFI din managed rules, plus o regulă care tratează corpurile de cerere mai mari decât limita de inspecție, ca să nu ajungă la backend conținut neinspectat. Logica e simplă: CVE-2026-109618 se bazează pe payload-uri mari care forțează un OOM.

Cloudflare a raportat însă atacatori care își schimbau payload-urile ca să ocolească regulile. WAF-ul îți cumpără timp, nu înlocuiește patch-ul.

Măsuri temporare dacă nu poți actualiza azi

Advisory-urile sunt clare: actualizarea e singura remediere completă. Măsurile de mai jos reduc expunerea pe căi de atac specifice, dar nu fac instalarea sigură. Aplică-le doar ca punte de câteva ore sau zile până la patch.

Pentru CVE-2026-109618 (OOM)

• memory_limit=-1 setat administrativ, astfel încât aplicația să nu-l poată suprascrie: php_admin_value[memory_limit] = -1 în pool-ul FPM sau php_admin_value memory_limit -1 în configurația Apache. Verifică apoi că niciun pool, director sau setare de aplicație nu repune o limită finită. Asta elimină eșecul controlabil al limitei PHP, dar un eșec de alocare real poate ajunge tot pe calea vulnerabilă.
• post_max_size mic: 8M dacă aplicația nu primește upload-uri, 32M dacă are nevoie de ele, cu upload_max_filesize sub post_max_size.
• Limite la frontend (Nginx, proxy, load balancer): mărimea decodată a cererii, numărul de câmpuri, numărul de părți multipart, numărul de header-e și adâncimea de imbricare. Limitele trebuie să acopere și cererile fără Content-Length utilizabil. Dacă aplicația nu folosește deloc multipart, blochează-l la frontend.
• Limite de container sau cgroup ca graniță de disponibilitate, de preferat cu o politică ce omoară doar worker-ul afectat.

Atenție la o capcană explicită din advisory: nu folosi RLIMIT_AS sau RLIMIT_DATA ca substitut. Ele fac ca mmap() să eșueze la atingerea limitei, adică declanșează exact eșecul de alocare care duce pe calea vulnerabilă.

Pentru CVE-2026-109619 (stare globală)

• session.upload_progress.enabled=0 în php.ini, în pool-ul FPM sau în configurația serverului, adică într-un loc care se aplică înainte de parsarea cererii. Apoi repornește toți workerii. ini_set() și .user.ini vin prea târziu și nu ajută. Advisory-ul spune că ar fi prudent să lași setarea dezactivată și după patch, dacă nu folosești funcția. WordPress, de exemplu, nu o folosește.
• Pe PHP 8.5: fatal_error_backtraces=0, setat administrativ, cu restart la toți workerii. Blochează doar calea confirmată prin backtrace.
• Elimină setările invalide sau depreciate aplicate per cerere care emit diagnostice înainte de inițializare.
• Repară erorile fatale și timeout-urile pe care un atacator le poate provoca, inclusiv în callback-uri, procesare de upload-uri, importuri și cleanup.
• Advisory-ul menționează și pm.max_requests=1 ca opțiune de luat în calcul. Un worker nou la fiecare cerere elimină reutilizarea stării, dar costul de performanță e mare, deci testează înainte.

Încă o capcană: ascunderea diagnosticelor cu error_reporting, display_errors, log_errors sau operatorul @ nu previne accesul la starea veche. Problema nu e că eroarea se vede, ci că există.

Ce măsuri temporare acoperă ce

După patch: verifică dacă ai fost compromis

Exploatarea a început înainte de lansarea oficială, iar Rapid7 notează că nu există indicatori de compromitere (IOC) sau semnături de log publicate. Mai important: absența intrărilor relevante în log-uri nu dovedește că instalarea e curată. Deci patch-ul închide ușa, dar nu-ți spune dacă a intrat cineva între timp.

Ce cauți pe server

Un RCE pe un server PHP se termină de obicei cu un webshell, adică un fișier PHP mic, lăsat într-un director în care serverul web poate scrie. Pornește de aici:

1# PHP files created or modified since the advance notice
2sudo find /var/www -type f -name '*.php' -newermt '2026-10-20' -ls
3
4# PHP files in upload directories, where they should never exist
5sudo find /var/www -path '*uploads*' -type f -name '*.php' -ls
6
7# Processes running as the web user that are not PHP workers
8ps -u www-data -o pid,lstart,cmd | grep -v php-fpm
9
10# Network connections opened by the web user
11sudo lsof -u www-data -i -nP

1# PHP files created or modified since the advance notice
2sudo find /var/www -type f -name '*.php' -newermt '2026-10-20' -ls
3
4# PHP files in upload directories, where they should never exist
5sudo find /var/www -path '*uploads*' -type f -name '*.php' -ls
6
7# Processes running as the web user that are not PHP workers
8ps -u www-data -o pid,lstart,cmd | grep -v php-fpm
9
10# Network connections opened by the web user
11sudo lsof -u www-data -i -nP

Pe lângă fișiere, verifică: conturi noi de administrator în CMS, cron-uri noi pentru utilizatorul web, chei SSH adăugate, modificări în .htaccess și în fișierele de configurare ale aplicației. Pe WordPress, compară fișierele core cu checksum-urile oficiale (wp core verify-checksums în WP-CLI). Dacă ai backup-uri de dinainte de 20 octombrie, un diff pe directorul web e cea mai rapidă metodă de a găsi ce a apărut nou.

Dacă găsești ceva

Tratează serverul ca fiind compromis: izolează-l, păstrează o copie pentru analiză, reconstruiește din surse curate, rotește toate secretele la care avea acces (parole de bază de date, chei API, token-uri). Un worker PHP compromis rulează cu drepturile utilizatorului web, deci are acces la tot ce poate citi aplicația: baza de date, fișierele încărcate, variabilele de mediu.

Dacă pe server existau date personale (conturi de clienți, comenzi, formulare de contact), intră în joc și GDPR. Articolul 33 din Regulamentul (UE) 2016/679 cere notificarea autorității de supraveghere (în România, ANSPDCP) în cel mult 72 de ore de la momentul în care ai aflat de încălcare, cu excepția cazului în care e puțin probabil să genereze un risc pentru persoane. Dacă nu ai un proces pentru asta, checklist-ul legal pentru site-uri din România și ghidul despre formularele de contact conforme GDPR îți arată ce date colectezi de fapt și unde stau, adică exact ce trebuie să știi în primele ore ale unui incident.

Ce înveți din PHP2Shell pentru infrastructura ta

Un incident ca ăsta testează nu doar serverul, ci procesul din jurul lui. Câteva lecții care rămân valabile și la următoarea vulnerabilitate critică, indiferent de limbaj.

Ai nevoie de un inventar înainte de criză

Majoritatea echipelor au pierdut primele ore pe 21 octombrie întrebând „unde mai rulăm PHP?”. Un inventar actualizat, cu fiecare server, container și cont de hosting, plus versiunea runtime-ului, transformă o zi de panică într-o oră de lucru. Dacă inventarul tău e un tabel de Excel pe care nu-l mai actualizează nimeni, ai deja unul dintre semnele că ai depășit Excel-ul.

Ciclul de viață al runtime-ului e o decizie de business

PHP 8.2 iese din suport pe 31 decembrie 2026. Fiecare server pe 8.1 sau mai vechi a transformat un patch de cinci minute într-un proiect de migrare cu termen de ore. Planifică upgrade-urile de runtime ca pe orice alt cost recurent, nu ca pe ceva care se face „când avem timp”.

Imaginile de container trebuie reconstruite regulat

Un Dockerfile cu FROM php:8.3-fpm construit acum șase luni conține PHP-ul de acum șase luni. Fără un build programat și un scanner de imagini în CI, containerele îmbătrânesc în tăcere. Reconstruirea săptămânală și alertele pe CVE-uri critice în imaginile de bază sunt măsuri ieftine.

Apărarea în straturi chiar a contat

Echipele care aveau deja limite stricte de mărime a cererii la proxy, upload-uri dezactivate unde nu erau necesare și un WAF în modul de blocare au avut mai mult timp de reacție. Niciuna dintre aceste măsuri nu a reparat vulnerabilitatea, dar fiecare a redus suprafața până la patch. Același tipar s-a repetat în aceeași lună și în ecosistemul JavaScript, cu vulnerabilitățile critice din Next.js reparate pe 14 octombrie. Pentru mai multe articole pe tema protecției datelor, vezi eticheta Securitatea datelor, iar pentru tot ce ține de platforme web și SaaS, hub-ul SaaS.

Întrebări frecvente

Ce este PHP2Shell?

PHP2Shell e numele colectiv, dat de Wiz Research, pentru CVE-2026-109618 și CVE-2026-109619, două vulnerabilități critice din nucleul PHP reparate pe 21 octombrie 2026. Ambele au scor CVSS v4.0 de 9.2 și pot permite execuție de cod la distanță fără autentificare.

Trebuie să actualizez WordPress sau Laravel?

Nu pentru vulnerabilitățile astea. Problema e în interpretorul PHP, nu în CMS sau framework. WordPress.org a confirmat că nu e necesar niciun update de WordPress. Trebuie actualizat PHP-ul de pe server sau din imaginea de container, apoi repornite procesele.

Ce versiuni PHP repară vulnerabilitatea?

PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35, sau orice versiune ulterioară. Pentru 8.1 și mai vechi nu există release oficial, doar backport-uri în sursă pentru 7.4, 8.0 și 8.1 și pachete patch-uite de la unele distribuții sau vendori de suport extins.

Sunt protejat dacă folosesc Cloudflare sau alt WAF?

Parțial. Regulile WAF blochează payload-urile cunoscute, dar Cloudflare a raportat atacatori care își modificau payload-urile ca să le ocolească. WAF-ul îți câștigă timp până la patch, nu îl înlocuiește.

Am PHP-FPM, nu mod_php. Sunt mai în siguranță?

Puțin, dar nu suficient. Riscul cel mai mare e pe mod_php, unde atacul merge înainte de codul aplicației. Pe FPM, cercetătorii au obținut tot RCE, pe alte căi, cu precondiții suplimentare. Actualizarea rămâne obligatorie.

Cum aflu dacă hostingul meu a aplicat patch-ul?

Verifică pagina de status a furnizorului sau scrie la suport și cere confirmare explicită pentru versiunea PHP a site-ului tău. Pe distribuțiile Linux, numărul versiunii poate rămâne același după backport, deci confirmarea furnizorului e mai sigură decât numărul afișat.

Următorul pas

Actualizează PHP azi, repornește toți workerii și verifică fișierele modificate după 20 octombrie. Dacă rulezi o aplicație internă sau o platformă pe un PHP pe care nimeni nu mai îndrăznește să-l actualizeze, acum e momentul să planifici migrarea, iar ghidul despre arhitectura multi-tenant e un punct bun de pornire pentru cum arată o platformă construită să fie actualizată fără frică.