Surse verificate începând cu 22 octombrie 2026. Audience: PHP operatori de aplicații, respondenți de securitate și ingineri care mențin versiuni personalizate PHP.

Acest articol rezumă cauza, amploarea impactului, procesul oficial de reparare, măsurile temporare de atenuare și implementarea oficială a corecțiilor vulnerabilității PHP2Shell. Textul principal este citat folosind numere precum S1; toate legăturile sursă sunt enumerate în anexa de la sfârșitul textului. Fragmentul de configurare este un șablon de implementare, care trebuie ajustat în funcție de versiunea reală, capacitatea de afaceri și relația de moștenire a configurației.

TL;DR: pași de reparare și sugestii

  1. Upgrade-ul PHP timpul de rulare : upgrade la ramura relevantă cel puțin 8.2.35 , 8.3.36 , 8.4.27 sau 8.5.12 . Pentru pachetele de distribuție, utilizați versiunea completă a pachetului pe care furnizorul confirmă că remediază ambele CVE. S1 S10
  2. Înlocuiți toate procesele vechi: reporniți sau treceți peste fiecare PHP worker, serviciu de găzduire și container după actualizare și confirmați că instanțele vechi au ieșit.
  3. Verificați prin calea actuală a cererii Web: verificați Web SAPI, versiunea completă a pachetului și instanța care rulează. Verificarea php -v singură nu stabilește că serviciul live este fix.
  4. Executați verificări de regresie a afacerii și restabiliți bugetele normale de resurse: testați autentificarea, gestionarea sesiunilor, încărcările, importurile și gestionarea erorilor. Dacă limita de memorie PHP a fost eliminată temporar, restaurați un buget finit corespunzător după corecție.
  5. Dacă o actualizare imediată este imposibilă: restricționați traficul neîncrezat înainte de a ajunge la PHP. Evaluați dezactivarea progresului de încărcare și PHP 8.5 backtraces fatale, așa cum este descris în Secțiunea 5. Atenuările de configurare și regulile WAF au acoperire limitată și nu pot înlocui o actualizare. S1S2S3

1. Privire de ansamblu asupra vulnerabilității și evaluarea riscurilor

PHP2Shell în acest articol se referă la două vulnerabilități de nivel Critical dezvăluite oficial de PHP pe 21 octombrie 2026. Ambele sunt legate de memorie și solicită managementul ciclului de viață al motorului PHP, prezentând riscul executării codului de la distanță neautentic. S1S2S3

ProiectCVE-2026-109618CVE-2026-109619
nume oficialRCE via OOM corruptionRCE via stale global state
probleme de bazăMemoria insuficientă provoacă un salt anormal, lăsând o stare care nu a finalizat încă inițializarea.Starea globală rămasă în worker indică către memoria de solicitare eliberată.
Timp de apariție tipicProcesul de inițializare, execuție sau curățare a cererii curenteCererea anterioară părăsește starea, iar cererile ulterioare o consumă în avans.
Este OOM o condiție necesară?Aparține mecanismului de declanșare de bază al vulnerabilitățiiNu; pot fi implicate și alte erori fatale și curățare post-diagnostic
Direcția de reparație fundamentalăGestionați în siguranță eșecurile de alocare și rezilierile solicitărilorRemediați proprietatea statului, timpul de curățare și inițializarea timpurie
Cerințe de eliminaretrebuie reparattrebuie reparat în același timp

Baza: Două buletine oficiale de securitate și trimiteri de remedieri. S2S3S4

1.1 Înțelegerea implementărilor afectate

PHP consideră oficial toate PHP manipularea desfășurărilor Web cereri la risc, inclusiv PHP-FPM , Apache mod_php , php-cgi , FrankenPHP , și LiteSpeed . Demonstrat mod_php atacul poate avea loc înainte de rularea codului aplicației, așa că verificările de conectare, middleware-ul cadru și validarea încărcării aplicației nu pot acoperi acea cale. S1

Este necesar să se facă distincția între „desfășurarea trebuie remediată” și „un anumit lanț de atac a fost complet dovedit”. Anunțul CVE-2026-109618: FPM va ieși din procesul copil după ce pornirea cererii eșuează, blocând calea de curățare corespunzătoare a mod_php după eșecul de pornire; cu toate acestea, calea OOM după pornirea cu succes este încă în pericol. Anunțul notează, de asemenea, că exploitul complet FPM pentru acest CVE nu a fost încă demonstrat. Această restricție nu poate fi folosită pentru a deduce că FPM este sigur, în special CVE-2026-109619 nu poate fi ignorat. S2S3

Limitele imediate ale permisiunii pentru exploatarea cu succes depind de identitatea procesului care găzduiește PHP și de resursele la care are acces. În general, trebuie acordată atenție codului site-ului web, directorului de încărcare, acreditărilor bazei de date, jetoanelor de serviciu și capacităților de acces la rețea internă; „execuția codului de la distanță” nu înseamnă obținerea în mod natural a permisiunilor root. Judecata de consecință aici se bazează pe modelul de permisiuni de proces, iar impactul real trebuie evaluat împreună cu permisiunile de implementare.

Scripturile obișnuite unice CLI nu au aceeași intrare HTTP; dar procesele care se ocupă de sarcini externe pentru o lungă perioadă de timp în CLI sau în modul încorporat ar trebui să fie în continuare incluse în inventarul de rulare și ciclu de viață. Numai dependențele CMS, framework sau Composer sunt actualizate, iar motorul PHP de bază nu este înlocuit automat.

2. Analiza cauzei

2.1 Mai întâi înțelegeți cele două cicluri de viață

PHP worker gestionează adesea mai multe solicitări succesive. Memoria alocată în timpul solicitării poate fi eliberată uniform la sfârșitul solicitării, în timp ce lucrătorul însuși și unele dintre câmpurile sale globale continuă să existe.

Prin urmare, motorul trebuie să mențină două constrângeri:

  • IConstrângere de inițializare: Datele vizibile pentru alte coduri trebuie să fie într-o stare care să poată fi citite, traversate și distruse în siguranță.
  • Lifecycle constraint: odată ce memoria de solicitare a fost eliberată, câmpurile cu durată mai lungă de viață nu trebuie să continue să trateze adresele din acea memorie ca stare validă.

Aceste două constrângeri corespund principalelor moduri de eșec ale celor două grupuri de vulnerabilități. Următorul proces este o descriere a mecanismului care combină anunțuri și compilarea de corecții. Nu înseamnă că fiecare implementare are exact aceeași cale accesibilă. S2S3S5

2.2 CVE-2026-109618: OOM a întrerupt o actualizare de stare neterminată

Vechea implementare folosește un salt non-local de tip longjmp() pentru a gestiona OOM, iar calea asociată iese din contextul de execuție curent prin zend_bailout(). Pericolul este ca o bucată de cod C să fi publicat un nou obiect, matrice sau stare de solicitare la alt cod, dar nu a finalizat încă toate inițializarea câmpului; în acest moment, orice eșec de alocare la momentul relevant poate duce la omiterea pașilor normali de închidere. S2

Procesul de eșec poate fi împărțit în patru etape:

  1. Creați sau actualizați structura internă a cererii și faceți-o accesibilă.
  2. Alocarea ulterioară a memoriei eșuează și OOM este declanșat.
  3. Fluxul de execuție se îndepărtează de funcția curentă, iar codul folosit inițial pentru a finaliza inițializarea sau restabilirea stării nu este executat.
  4. Solicitarea de curățare continuă procesarea acestor structuri și tratează conținutul nevalid ca fiind câmpuri sau adrese valide.

Problema nu este că lipsa memoriei cauzează întotdeauna RCE. Mai degrabă, epuizarea memoriei modifică fluxul de control și încalcă ipotezele motorului despre structurile valide. Alocarea eșuată nu trebuie să implice în mod direct structura care este în cele din urmă citită incorect. S2

De ce cererile mai mici pot rămâne fără memorie

Numărul de octeți din corpul cererii și utilizarea heap-ului după parsare nu sunt același lucru. Câmpul A poate corespunde mai multor șiruri de caractere, elemente de matrice și obiecte de metadate din interiorul PHP; complexitatea structurală de intrare va afecta gradul de amplificare a memoriei.

Problemele cu mai multe părți enumerate în anunțul oficial includ: decalajul de verificare a dimensiunii inițiale atunci când lipsește lungimea disponibilă a declarației, numărul de anteturi pentru o singură parte nu este suficient de limitat și controalele de fișiere goale produc în continuare metadate, cu numele imbricate care cresc și mai mult volumul de lucru al matricei. Derularea, decodificarea sau realocarea intrării proprii ale aplicației pot fi, de asemenea, o sursă de OOM. S2

Din aceasta se pot trage două concluzii de protecție:

  • Restricțiile pentru corpul cererii trebuie implementate cât mai mult posibil înainte de a introduce PHP, iar lungimea reală de citire și complexitatea structurală trebuie luate în considerare.
  • Limitarea individuală a dimensiunii fișierului, a numărului de fișiere sau închiderea unui singur portal de încărcare nu poate acoperi toate sursele OOM.

De ce autentificarea aplicației poate fi prea târziu

În mod_php, corpul cererii poate fi analizat automat în timpul fazei de inițializare a cererii; chiar dacă pornirea eșuează, curățarea cererii aferente va fi în continuare efectuată. Prin urmare, căile de atac confirmate pot apărea înaintea codului aplicației. Pentru a reduce expunerea în această etapă, trebuie plasate restricții la proxy-ul invers, serverul Web sau altă limită care precede procesarea cererii PHP. S1S2

2.3 CVE-2026-109619: Memoria de solicitare a fost eliberată, referința globală este încă în viață

Această problemă implică starea de eroare, sesiune, obiect sau extensie: câmpul este stocat într-o locație de acces pe termen lung a lucrătorului, dar datele la care face referire câmpul aparțin unei singure solicitări. Atâta timp cât referința nu este curățată în mod corespunzător înainte ca heap-ul de solicitări să fie eliberat, solicitările ulterioare pot întâlni o stare de suspendare, formând utilizare-after-free. S3

Analiza oficială împarte condițiile de exploatare în „producători” și „consumatori”:

rol sau condițiesensulImplicații pentru protecție
producator de statPuneți statul deținut de această solicitare într-o locație care poate fi încă accesată ulteriorPentru a verifica dacă curățarea corespunzătoare este finalizată după o ieșire anormală
Starea rămâneNu a fost curățat sau a fost curățat și apoi reumplut printr-o operație târzie.Doar ștergerea o dată la etapa anterioară de oprire poate să nu fie suficientă
reutilizarea muncitorilorAcelași lucrător continuă să proceseze cererile ulterioareLucrătorii multipli sunt doar o diferență de programare, nu o garanție de siguranță a memoriei
consumator anticipatCitiți, eliberați sau determinați valoarea reziduală înainte ca starea corespunzătoare să fie inițializată normal.Trebuie să verificați INI, sesiune și alte căi înainte de inițializare

Aceste condiții trebuie îndeplinite în combinație; orice jurnal de erori în sine nu dovedește că vulnerabilitatea a fost exploatată cu succes. S3

Nu necesită OOM ca o condiție prealabilă necesară

Erorile fatale pot întrerupe publicarea și restaurarea stării asociate. Eșecurile de compilare sau de analiză, erorile neprinse, eșecurile require și expirarea timpului de execuție pot lăsa anumite stări în urmă. Diagnosticele non-fatale la sfârșitul curățării pot, de asemenea, să repopuleze informațiile de eroare care au fost deja șterse. S3

Prin urmare, schimbarea memory_limit la nelimitat nu acoperă acest set de vulnerabilități.

„Înainte de inițializare” trebuie tratat separat

Momentul celor două tipuri de consumatori confirmați este diferit:

  • EDiagnoză INI inițială: Unele configurații aplicate la cerere emit avertismente, notificări sau depreciere înainte de inițializarea normală a executorului și procesarea diagnosticului poate accesa vechea stare de eroare.
  • progres de încărcare a sesiunii: sesiunea poate fi procesată în avans în timpul procesului de analizare a corpului cererii, dar modulul obișnuit RINIT nu a fost încă finalizat; nu se poate deduce că calea nu există deoarece aplicația nu apelează în mod explicit session_start(). S3

Nu toate INI configurațiile au același timp de risc. Configurația la nivel de director a mod_php iar cel PHP_VALUE / PHP_ADMIN_VALUE trecut de către FPM front-end-ul trebuie să fie distins de cel obișnuit php.ini , FPM pool configurarea pornirii și FPM .user.ini . Acestea din urmă au un timp de configurare diferit și nu pot fi numiți în mod colectiv aceiași consumatori timpurii. S3

Oprirea display_errors, log_errors, reducerea error_reporting sau utilizarea @ afectează doar vizibilitatea diagnosticului; este posibil ca starea internă relevantă să fi fost accesată înainte de a decide dacă să scoată jurnalul. S3

3. Reparați versiunea și selectarea patch-urilor

3.1 Linia de bază oficială a remedierii în amonte

Sucursala actuală PHPPrima versiune care include această remediere oficialăSugestii
8.28.2.35Faceți upgrade la această versiune sau la o versiune ulterioară care conține aceleași remedieri
8.38.3.36La fel ca mai sus
8.48.4.27La fel ca mai sus
8.58.5.12La fel ca mai sus
8.1 și versiuni anterioareSprijinul general în amonte s-a încheiatPrioritizează migrarea către sucursalele acceptate; eliberarea de verificare pe termen scurt sau backportul producătorului LTS

Versiunea și starea de asistență se bazează pe anunțul oficial al PHP, iar momentul de referință este 22 octombrie 2026. S1

Acestea sunt praguri de remediere specifice fiecărei ramuri. Ele nu pot fi înlocuite cu o declarație că fiecare versiune de sub 8.5.12 este vulnerabilă: versiuni precum 8.2.35 și 8.4.27 din alte ramuri conțin deja remedieri.

3.2 Verificați versiunea completă a pachetului de distribuție

Distribuțiile adaugă adesea remedieri de securitate bazate pe versiuni mai vechi din amonte. Acceptarea ar trebui să verifice, de asemenea, versiunea de lansare, sursa depozitului, versiunea pachetului complet și buletinul de securitate.

De exemplu, versiunea pachetului de corecții Ubuntu 24.04 LTS listată pentru Ubuntu USN-8948-1 este:

8.3.6-0ubuntu0.24.04.13

Partea sa din amonte este încă 8.3.6, dar versiunea completă a pachetului respectiv a distribuției este inclusă în acest anunț de remediere. Această concluzie se aplică numai distribuției corespunzătoare și sursei pachetului și nu poate fi generalizată la nicio versiune care afișează și 8.3.6. S10

3.3 Alegerea patch-ului potrivit

scenaPlan prioritarPuncte cheie pentru acceptare
Folosind pachetul de distribuție PHPInstalați actualizări de securitate lansate de producătorAnunțul acoperă atât CVE; versiunea completă a pachetului este corectă
Utilizați containerul oficial PHP sau imaginea auto-construităActualizați durata de bază, reconstruiți și implementațiInstanța care rulează folosește noua imagine; toate copiile vechi sunt eliminate
Ramuri suportate autocompilateUtilizați versiunea oficială de securitate a acestei ramuri sau setul complet de corecții oficialePotrivirea ramurilor, completarea dependenței, compatibilitatea extensiilor și trecerea regresiei
Sub rezerva 7.4, 8.0, 8.1Prioritizează backport-ul furnizorului; evaluați filiala oficială a codului sursă de urgență, dacă este necesarIdentificați schimbările comportamentale și programați migrarea către versiunile acceptate

Patch-urile oficiale au fost lansate, iar corecțiile reale ar trebui să înceapă de la aceste patch-uri. Fragmentele de cod din Secțiunea 6 sunt menite să ilustreze aspectele evidențiate ale designului și revizuirii și nu constituie un patch complet care poate fi aplicat independent. S1S4S6

4. Procesul formal de reparare

4.1 Inventarul timpului de execuție care gestionează efectiv cererile

Se recomandă formarea unui registru scurt pentru a înregistra cel puțin:

  • Nume de domeniu sau serviciu de intrare, backend proxy invers, PHP SAPI.
  • Ramura PHP, versiunea pachetului complet sau rezumatul imaginii, sursa de compilare.
  • FPM pool, unitate de service reală, container sau Pod, număr de replici.
  • Au fost încărcate extensiile, configurația principală și fișierele de configurare suplimentare.
  • Există și alte versiuni PHP, copii vechi de implementare sau portaluri de origine care pot fi accesate direct?

Acestea sunt sugestii de implementare, astfel încât „actualizat” să corespundă fiecărei intrări de trafic efective. Verificați în special dacă liniile de comandă PHP și Web PHP folosesc versiuni diferite, imaginea este construită, dar vechiul container încă rulează, o parte din pool sau copia nu este înlocuită etc.

4.2 Selectați și implementați actualizarea corectă

Confirmați versiunea corectă conform secțiunii 3, de preferință folosind o sursă de pachet de încredere existentă sau un lanț de compilare controlat. Sfera de actualizare ar trebui să includă componenta care găzduiește de fapt cererea, cum ar fi pachetul FPM, modulul Apache PHP, binarul CGI sau versiunea de serviciu în care este încorporat PHP.

Înainte de a face upgrade, păstrați configurația și lista de pachete și verificați pornirea și serviciile cheie într-un mediu similar cu cel de producție. Pentru extensiile auto-întreținute, verificați compatibilitatea de compilare și rulare corespunzătoare versiunii PHP. Doar alegerea unui commit aparent relevant dintr-o altă ramură nu garantează că întregul set de corecții a fost implementat.

4.3 Reporniți sau treceți peste instanțele care rulează

Instalarea unui fișier și încărcarea unui cod nou într-un proces sunt două lucruri diferite. Serviciul corespunzător ar trebui repornit sau înlocuirea de rulare ar trebui să fie finalizată, iar vechiul lucrător și vechiul container ar trebui să fie confirmat că au părăsit.

Pentru mod_php, reporniți procesul Apache care găzduiește modulul. Serviciile care încorporează PHP necesită înlocuirea procesului de găzduire. Pentru FPM, ștergerea OPcache nu înlocuiește actualizarea timpului de execuție și retragerea lucrătorilor vechi.

Când utilizați comutarea grațioasă, trebuie să verificați dacă procesul de generație veche mai gestionează conexiuni lungi sau solicitări restante. Înregistrarea de acceptare ar trebui să includă serviciul real, versiunea de implementare, timpul de finalizare a modificării și rezultatele de ieșire ale instanței vechi.

4.4 Verificați prin cereri reale Web

Este recomandat să combinați următoarele dovezi în loc să vă bazați doar pe o singură comandă de versiune:

doveziCe se poate dovediNu pot dovedi nimic singur
Manager de pachete sau metadate de imagineSurse de instalare și versiuni completeTraficul a fost schimbat la această instanță
Starea procesului și a implementăriilucrătorul sau containerul completează înlocuireaIntrarea exterioară trebuie direcționată către acesta
Rezultate de diagnosticare restricționate accesate prin portal realWeb SAPI reală și configurație de rulareDacă backportul de eliberare acoperă două CVE
Anunțul furnizorului sau înregistrarea completă a patch-urilorAceastă remediere a erorilor este inclusă în această versiuneToate replicile sunt implementate

PHP_VERSION, PHP_SAPI, fișierele de configurare încărcate și configurațiile de urgență pot fi verificate prin intermediul capabilităților interne de diagnosticare existente sau prin portaluri de diagnosticare temporare și controlate de acces. Asigurați-vă că solicitarea nu este returnată direct de CDN sau de cache-ul paginii; eliminați intrarea de diagnostic temporară când este finalizată.

php -v indică de obicei doar binarul CLI selectat în prezent de către shell; comenzi precum php-fpm -i nu sunt echivalente cu verificarea lucrătorului existent care primește trafic. Nu expuneți pagina completă phpinfo() în rețeaua publică pentru o perioadă lungă de timp.

4.5 Verificări ale regresiei afacerii și eliminarea setărilor de urgență

Verificați autentificarea normală, citirea și scrierea sesiunii, formarea și încărcarea, importul, gestionarea erorilor și stabilitatea lucrătorului în jurul funcțiilor afectate de această modificare. Verificați dacă rata de eroare, întârzierea răspunsului, vârful memoriei, ieșirea procesului și frecvența de reconstrucție sunt anormale.

Dacă memory_limit=-1 este setat temporar, bugetul limitat care corespunde capacității afacerii va fi restabilit după ce patch-ul oficial va intra în vigoare; dacă pm.max_requests=1 este setat, configurația ciclului de viață evaluat în funcție de capacitate va fi restabilită după confirmarea reparației. Limitele de dimensiune de intrare și controalele de acces la sursă pot fi păstrate în funcție de nevoile afacerii.

Dacă apar probleme de compatibilitate în timpul upgrade-ului, ar trebui să se acorde prioritate suspendării portalului afectat, restricționării accesului său extern sau ajustării aplicației înainte de a reveni. Permiterea directă a timpului de rulare nereparat să servească din nou rețeaua publică va redeschide riscul inițial.

5. Măsuri de atenuare atunci când actualizarea imediată nu este posibilă

Această secțiune este destinată reducerii pe termen scurt a expunerii sau îmbunătățirii disponibilității. Fiecare măsură acoperă doar o anumită cale, iar o combinație de măsuri multiple nu este echivalentă cu o reparație completă. S1S2S3

5.1 Prioritizează controalele de trafic înainte de PHP

Dacă serviciul permite acest lucru, restricționați temporar punctele finale sensibile la surse de încredere sau impuneți controlul accesului înainte de PHP. Pentru încărcări de lucru, limitați dimensiunea corpului cererii, numărul de câmpuri, numărul de părți, anteturile pe parte și adâncimea de imbricare. Serviciile care nu au nevoie de mai multe părți îl pot respinge pe front-end. S2

Aceste restricții trebuie să acopere toate intrările în PHP. Numai interceptarea URL numită „încărcare” va pierde alte intrări care sunt încă analizate automat de PHP în corpul cererii. Pentru cazuri precum transferurile fragmentate, lipsa lungimii declarate disponibile etc., limita ar trebui să se bazeze pe dimensiunea reală de citire; aplicația ar trebui să aibă, de asemenea, propriul buget de dimensiune de ieșire atunci când decomprimați sau extindeți din nou conținutul.

5.2 FPM pool șablon de configurare

Plasați următoarele setări în secțiunea de configurare FPM pool care deservește de fapt cererile, nu textual în php.ini. Valorile 8M și 4M sunt exemple de ajustare pentru volumul de muncă. Lăsați loc pentru câmpurile de formular și limitele cu mai multe părți atunci când limitați întreaga solicitare POST. S11S12

; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

Numai PHP 8.5, plus:

php_admin_flag[fatal_error_backtraces] = off

Funcțiile și limitele fiecăruia sunt următoarele:

Configurareefectul așteptatDescrierea restricțiilor care trebuie păstrate
memory_limit=-1Eliminați condiția previzibilă de declanșare a limitei superioare a memoriei de solicitare PHPNu previne eșecul de alocare de bază; anularea bugetului inițial poate crește riscul de epuizare a memoriei și de întrerupere a serviciului.
post_max_size mai micReduceți dimensiunea datelor care intră în procesul de analizareAnalizorul nefixat are decalaj cunoscut; amplificarea memoriei nu poate fi prevenită independent
upload_max_filesize < post_max_sizeLimitați dimensiunea unui singur fișier și rezervați spațiu de supraîncărcare pentru cerereNu constrânge toate câmpurile, metadatele sau alocările în aplicație
Închideți progresul încărcăriiBlocați calea aferentă sesiunii confirmateNu acoperă alte variante globale de stat
PHP 8.5 închidere fatală backtraceBlocați producătorii de statut afiliați confirmațiNu acoperă alte căi, cum ar fi sesiunea

Limitele măsurii provin din anunțul oficial; pentru sintaxa pool-ului și semantica configurației la nivel de management, consultați manualul PHP. S1S2S3S11

Setările php_admin_* la nivel de management nu pot fi înlocuite de aplicații prin ini_set(). Toate configurațiile de intrare, la nivel de director și front-end ar trebui în continuare revizuite pentru a confirma că valorile cererilor reale sunt cele așteptate. După modificare, reconstruiți toți lucrătorii pentru a preveni ca procesele existente să continue să păstreze starea veche.

Dacă alegeți să modificați php.ini direct, sintaxa ar trebui schimbată în:

memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off

Spre deosebire de php_admin_value în pool, simpla setare a memory_limit=-1 în php.ini nu împiedică aplicația să o modifice din nou. Cadrul, codul aplicației și alte configurații ar trebui verificate pentru a vedea dacă au resetat valoarea limitată; atunci când este necesară aplicarea, utilizați setările la nivel de management adecvate pentru SAPI curent și verificați valoarea efectivă efectivă. S11S12

Adăugați fatal_error_backtraces = Off numai pentru PHP 8.5. Nu utilizați ini_set() la nivel de aplicație ca o soluție pentru dezactivarea progresului de încărcare și nu vă bazați pe FPM .user.ini pentru a-l face efectiv înainte de analizarea cererii. S1S3

5.3 Gestionați costul eliminării limitelor de memorie PHP

memory_limit=-1 este o atenuare temporară a căii pentru medii neremediate și nu trebuie copiată ca configurație implicită pe termen lung. Când o aplicație sau o solicitare scapă de sub control, poate folosi mai mult din memoria gazdei. Prin urmare, înainte de utilizare, ar trebui să evaluați numărul de concurențe, maximul de lucrător individual și capacitatea totală de serviciu și să implementați limitele de intrare front-end. S2

Limitele de memorie container sau cgroup pot oferi limite de disponibilitate, dar nu garantează că alocările nu vor eșua niciodată; întregul container, comandantul și toți lucrătorii pot fi, de asemenea, reziliați atunci când limita este declanșată. Granularitatea izolației și strategiile de terminare trebuie evaluate împreună cu implementarea și nu pot fi numite protecție completă pentru aceste două CVE. S2

Nu înlocuiți strategiile de mai sus cu RLIMIT_AS, RLIMIT_DATA sau restricții corespunzătoare privind spațiul de adrese ale procesului; acestea pot cauza direct eșecul alocării de bază în calea încă problematică OOM. S2

5.4 Nginx Exemplu de configurare

Se aplică implementării în care Nginx transmite cereri către PHP-FPM. Poate fi setat la nivelul de configurare al serviciului de găzduire propriu-zis:

client_max_body_size 8m;
fastcgi_request_buffering on;

client_max_body_size limitează dimensiunea corpului cererii; fastcgi_request_buffering on îi permite lui Nginx să citească mai întâi corpul complet al cererii și apoi să îl trimită către backend-ul FastCGI. Dacă are efect într-un anumit server sau location trebuie verificat împreună cu moștenirea și relațiile de acoperire existente. S13S14

ONumai atunci când afacerea nu are nevoie de mai multe piese, puteți adăuga o regulă de respingere la intrarea de serviciu corespunzătoare:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

Acesta este un șablon simplu de restricție de intrare folosind if și return, nu o regulă generală de filtrare pentru vulnerabilitățile parserului. Verificați sintaxa configurației și solicitările normale înainte de implementare și verificați dacă error_page personalizat redirecționează 403 solicitări către PHP. Potrivirea șirurilor nu oferă garanții complete pentru toate diferențele de analiză. S15

În plus, aceste configurații nu limitează automat cantitatea de date, numărul de câmpuri sau numărul de obiecte PHP care pot fi decomprimate de aplicație; companiile care trebuie să încarce ar trebui să folosească restricții suplimentare care să înțeleagă structura solicitărilor lor.

5.5 Atenuare opțională: o solicitare pentru fiecare lucrător FPM

Pentru implementările FPM care își pot permite cheltuielile generale, pot fi evaluate setările pe termen scurt:

pm.max_requests = 1

Și reconstruiește muncitorul existent. Acesta blochează lanțul de solicitări încrucișate descris la nivel de reutilizare a lucrătorilor, dar va crește costul general de creare și inițializare a procesului; în același timp, nu poate repara aceeași solicitare OOM și probleme de curățare ale lui CVE-2026-109618. Când valoarea este mai mică, dar mai mare decât 1, există încă o fereastră de reutilizare a cererii. S3S11

Limitele de acoperire 5.6 WAF și Cloudflare

Cloudflare a anunțat aranjamente de implementare pentru protecție împotriva PHP2Shell, inclusiv planul Free. Când utilizați serviciile sale, ar trebui să verificați dacă traficul real trece prin proxy, dacă regulile de protecție sunt în vigoare și dacă site-ul de origine poate fi ocolit direct; pentru planurile plătite, trebuie să verificați și configurația și excepțiile Regulilor gestionate corespunzătoare. S16

Unele dintre detecțiile descrise de furnizor utilizează semnale de răspuns, astfel încât toate protecțiile nu pot fi interpretate ca „fiecare atac este blocat înainte de a ajunge la PHP”. WAF poate ajuta la reducerea expunerii și poate oferi informații de observație, dar actualizările continue la PHP sunt încă necesare. S16

5.7 De ce măsurile comune sunt insuficiente

măsuri sau hotărârineajunsuri
Închideți doar file_uploadsNu poate acoperi toată procesarea în mai multe părți și nu poate aplica propria cale OOM
Setarea enable_post_data_reading=OffSchimbați comportamentul de completare automată a POST/FILES; organismul solicitant poate fi în continuare citit de aplicație și poate perturba activitatea normală
Opriți afișarea erorilor, înregistrați sau utilizați @Procesarea de diagnosticare internă poate accesa în continuare starea de suspendare
Creșteți cantitatea de muncitoriNu stabiliți un mecanism de curățare a stării sigure și nici nu eliminați reutilizarea unui singur lucrător
Configurați numai disable_functions sau open_basedirAceste limitări nu remediază corupția memoriei stratului motor C
Verificați o singură versiune sau o singură copie o singură datăNu se poate dovedi că toate intrările și instanțele de rulare au fost înlocuite
Nu sunt văzute jurnalele de excepțiiNu poate dovedi că vulnerabilitatea nu există sau că nu a fost exploatată înainte.

Printre acestea, baza mecanismului de configurare și vulnerabilitate a lui PHP poate fi găsită în S2S3S12; judecățile privind limitele de acoperire, acceptare și permisiuni se bazează pe sugestiile de implementare prezentate de aceste mecanisme.

6. Idei de implementare și puncte de revizuire a patch-ului oficial

6.1 Utilizați remedieri complete pentru ramura corectă

Depunerea oficială reprezentativă pentru PHP 8.5 este:

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

Commit-ul asociază în mod explicit două CVE, atât pentru a ajusta mecanismul de ieșire OOM, cât și pentru a remedia starea globală care poate fi accesată în timpul fazei de inițializare. Trimiteți pagina cu diferența completă, vezi S4S5. Alte ramuri ar trebui să folosească propriile versiuni oficiale de securitate sau corecții corespunzătoare și nu se poate presupune că modificările aduse 8.5 pot fi aplicate direct oricărei versiuni mai vechi.

6.2 OOM Reparare: restaurați mai întâi starea procesabilă și apoi terminați cererea

Implementarea formală introduce două niveluri de procesare soft și hard OOM: când este atinsă limita soft, starea în așteptare este înregistrată și o ieșire controlată este efectuată într-o locație sigură, cum ar fi VM; interfața de alocare eșuată permite apelantului să gestioneze în mod explicit eșecul. Pentru alocările care nu pot returna în mod direct eșecul, dacă se așteaptă să fie depășit un prag mai mare, procesul va fi încheiat direct pentru a evita continuarea procesării cererilor într-o stare intermediară nesigură. S2S5

Următorul este un extras din codul cheii din 8.5 diff folosit pentru a marca OOM în așteptare:

EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

VM manipularea întreruperilor și alte locații sigure apelați ulterior zend_handle_delayed_oom(). Contextul său de execuție a codului utilizatorului folosește o cale de desfășurare controlată; calea hard OOM apelează _exit(137). S5

Din punct de vedere al designului, modificările importante sunt: Evită traversarea arbitrară a stivei de apeluri C atunci când structura este într-o stare intermediară și plasează ieșirea într-o locație care poate menține constrângerile de stare. După ce limita soft este declanșată, poate fi necesară memorie suplimentară pentru a finaliza procesul, astfel încât noul prag soft nu poate fi înțeles ca o limită superioară absolută pentru memoria totală a procesului.

Nici nu poate fi rezumat ca „PHP a șters tot zend_bailout()”. Patch-ul folosește în continuare mecanisme relevante în contexte specifice; ceea ce este fixat este momentul periculos de ieșire și managementul de stat însoțitor. S5

6.3 Actualizați apelanții de alocare și analizarea în mai multe părți împreună

Dacă modificați doar o funcție de alocare în „return NULL la eșec” și apelantul inițial încă presupune că un pointer valid este returnat întotdeauna, veți introduce noi accesări de pointer nul sau curățare incompletă. Interfața de alocare eșuată din patch trebuie revizuită împreună cu verificarea apelantului și propagarea excepțiilor. S5

Remedierile legate de mai multe părți includ, de asemenea, efectuarea de verificări cumulative bazate pe volumul real de citire, reducerea procesării antetelor inutile sau duplicate și adoptarea unei logici consecvente de ieșire și curățare atunci când OOM este în așteptare. Aceste modificări reduc atât amplificarea resurselor, cât și fac ca analizatorul să respecte noul protocol OOM. S5

Pentru echipele care își mențin propriile filiale, se recomandă ca următoarele probleme să fie în centrul examinării codului:

  • Este starea vizibilă pentru lumea exterioară înainte de a fi inițializată complet?
  • După eșecul alocării sau excepția de apel invers, proprietatea este încă unică și lipsită de ambiguitate?
  • Puteți ajunge la ieșirea de curățare unificată dacă nu reușiți la jumătatea drumului?
  • Funcția de curățare poate recunoaște câmpurile neinițializate sau eliberate?
  • Bugetul de analiză se bazează pe volumul real de procesare, nu doar pe cererile de încredere?
  • Noua valoare de returnare a eșecului a fost gestionată de toți apelanții?

Acestea sunt întrebări de revizuire rezumate pe baza mecanismului de remediere și nu sunt concluzia unui audit care a fost finalizat pentru o bază de cod nefurnizată.

6.4 Remediere încrucișată: inițializare mai devreme, curățare finală mai târziu

Corespunzător cu CVE-2026-109619, patch-ul ajustează mai multe limite ale ciclului de viață în același timp. Fișierele și operațiunile enumerate mai jos iau ca exemplu diferența oficială PHP 8.5. S5

locațieschimba directiaProblema rezolvata
Zend/zend_execute_API.c etc.Resetați starea executorului, cum ar fi erori, excepții, handlere, obiecte etc.După încheierea cererii, există încă referințe vechi care pot fi accesate de următoarea solicitare.
Calea de pornire a lui main/main.cApelați php_basic_early_rinit() înainte ca SAPI să fie activatCând apare un consumator timpuriu, starea de bază relevantă nu a fost încă inițializată.
Închideți calea lui main/main.cDistrugeți HTTP globals și marcați-l ca nedefinitValoarea eliberată este în continuare considerată un obiect valid
înainte ca heap-ul de cereri să fie în sfârșit eliberatCurățați din nou ultimul mesaj de eroareDiagnosticele de curățare tardivă repopulează starea de eroare
ext/session/session.cprogresul încărcării Calea timpurie este inițializată globală a primei sesiuniModulul obișnuit RINIT a accesat anterior starea veche
Cod legat de serializareLimitați analizarea claselor și apelurile inverse ale utilizatorilor în procesarea timpurieExecutați cod de utilizator suplimentar când inițializarea nu este completă

De exemplu, secvența de pornire include:

zend_activate();
php_basic_early_rinit();
sapi_activate();

După ce HTTP globals este distrus, adăugați semnul de eroare de stare:

zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);

Aceste fragmente ilustrează două principii: inițializați înainte de cel mai devreme consumator posibil și efectuați curățarea finală după ultima operațiune care ar putea recrea starea. Resetarea unui indicator numai în timpul normal RINIT sau o etapă anterioară de oprire poate pierde accesări mai devreme sau ulterioare. S5

6.5 De ce nu este recomandat să vă faceți propria „reparație pe o singură linie”?

Înlocuirea tuturor zend_bailout() cu _exit() sau doar adăugarea unei verificări a indicatorului nul la o anumită intrare, ar acoperi un număr mare de contexte de execuție diferite. Aceștia pot omite alte câmpuri de stare sau pot modifica distrugerea, apelurile extinse, găzduirea procesului și semantica finală a solicitării.

Pentru versiunile acceptate, corecțiile complete care au fost deja lansate au prioritate. Migrarea filialelor proprii ar trebui să înregistreze sursa patch-urilor, liniile de bază aplicabile, gestionarea conflictelor și schimbările de comportament și să utilizeze cazurile de utilizare a regresiei în amonte corespunzătoare și verificarea acestui proces de afaceri. Sugestiile de aici provin dintr-o analiză a domeniului de aplicare a patch-ului în alocător, VM, sesiuni și modificări ale ciclului de viață al cererii. S4S5

7. Backport de urgență pentru PHP 7.4, 8.0, 8.1

PHP oferă oficial backport-ul minim al codului sursă pentru trei ramuri vechi, în funcție de gravitate. Numele filialelor sunt:

PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619

Pentru legăturile de ramuri, consultați S7S8S9. Acestea sunt livrări de urgență pentru această vulnerabilitate și nu reprezintă o revenire la suportul obișnuit din amonte pentru vechea filială și nici nu înlocuiesc alte actualizări de securitate. S1

7.1 Luați backportul PHP 8.1 ca exemplu

Documentele relevante pentru PHP 8.1 sunt:

1d7dec178a094e6e75b229ce22754045f8c6070a

Strategia sa favorizează eșecul rapid: apelarea _exit(1) după emiterea diagnosticelor în calea OOM corespunzătoare și includerea stării globale și a altor corecții relevante; în timp ce dezactivează intern procesarea corespunzătoare a progresului de încărcare a sesiunii. Pentru trimiterea codului sursă relevant, consultați S6.

Aceasta este o diferență de comportament față de designul OOM mai complet întârziat din ramura acceptată. Doar pentru că configurația încă arată că progresul încărcării este activat, nu înseamnă că comportamentul de procesare internă după acest backport va rămâne neschimbat.

7.2 Prețul pe care trebuie să-l acceptați la implementare

Ieșirea directă din proces poate duce la eșecul cererii curente, sărind apelurile normale de închidere PHP și închiderea unei părți a aplicației; dacă gazda adoptă un model de fir, este, de asemenea, necesar să se evalueze impactul întregului proces de ieșire a gazdei asupra altor lucrări concurente. Dacă managerul de proces poate retrage procesul de înlocuire la timp, ar trebui inclus și în verificare.

Prin urmare, utilizatorii versiunilor mai vechi ar trebui să ia în considerare în ordine:

  1. Migrați la ramura PHP acceptată și la versiunea sa fixă.
  2. Utilizați o versiune care acoperă în mod explicit atât CVE, cât și actualizarea producătorului LTS.
  3. Dacă este într-adevăr supus versiunii vechi a codului sursă, utilizați backport-ul oficial de urgență al versiunii potrivite pentru a verifica modificările complete și compatibilitatea și aranja migrarea ulterioară.

„Backportul minim” descrie aici compatibilitatea și domeniul de implementare selectat de oficial și nu ar trebui să fie interpretat automat ca „remedieri de vulnerabilități incomplete cunoscute”. Ar trebui să judeci pe baza codului sursă al ramurii corespunzătoare și a anunțului producătorului și să nu ștergi singur modificările de sprijin. S1S6

8. Criterii de acceptare și inspecții ulterioare

Se recomandă ca următoarele rezultate să fie folosite ca bază pentru finalizarea acestei reparații:

Elemente de acceptareStandarde de finalizare
acoperirea vulnerabilitățiiAnunțul despre build sau furnizor fixează în mod explicit CVE-2026-109618 și CVE-2026-109619
Acoperire de implementareToate portalurile, pool-ul, serviciile și replicile folosesc timpul de execuție reparat
Procesul intră în vigoareVechiul lucrător, vechiul proces gazdă și vechiul container ies toate
Verificarea cererii autenticeSAPI confirmat, construit și configurat cu legătura Web reală pentru a elimina direcționarea greșită a memoriei cache
disponibilitatea afaceriiFuncțiile cheie precum sesiunea, încărcarea, importul și gestionarea erorilor au revenit în mod normal.
Încheierea măsurilor temporareMemoria nelimitată și configurațiile extreme de reciclare a lucrătorilor au fost restaurate conform planului de capacitate sau au un motiv clar pentru reținere
Dovada schimbăriiÎnregistrați versiunea pachetului sau rezumatul imaginii, actualizați domeniul de aplicare, timpul de finalizare și rezultatele verificării

Cele de mai sus sunt sugestii pentru implementare. Dacă trebuie să verificați comportamentul OOM, ieșirea anormală sau corecțiile personalizate, ar trebui să utilizați testarea de regresie în amonte sau injecția controlată a erorilor într-un mediu izolat pentru a evita crearea în mod repetat de epuizare a memoriei în mediul de producție ca metodă de acceptare.

Verificați, de asemenea, evenimentele PHP fatale, blocarea lucrătorului, repornirea anormală, rata de eroare de solicitare și evenimentele WAF înainte și după actualizare. Jurnalele pot oferi doar indicii de investigație: apariția OOM nu înseamnă că a fost exploatat, iar lipsa alarmelor nu dovedește că nu a avut loc nicio exploatare. Upgrade-ul remediază căile de vulnerabilitate care pot fi atinse în viitor; dacă sunt găsite anomalii precum manipularea fișierelor sau scurgerea acreditărilor, ar trebui efectuate investigații separate ale incidentelor.

Toate link-urile surselor sunt colectate mai jos. Avizele, corecțiile și îndrumările furnizorului reflectă verificări începând cu O22 octombrie 2026; implementările ulterioare ar trebui să verifice actualizările furnizorului. Citările numerotate din text se referă la aceste intrări.

S1 — PHP buletinul oficial de securitate și versiunea de reparații

  • Sursa: Proiectul PHP, 21 octombrie 2026.
  • Scop: Domeniul de risc, patru versiuni oficiale de reparații, măsuri oficiale temporare și instrucțiuni de urgență pentru sucursalele vechi.
  • Referință: PHP 2026 This security bulletin se află în arhiva buletinului anual

S2 — CVE-2026-109618 Buletin Tehnic Oficial

  • Sursa: php/php-src GitHub Security Advisory, 21 octombrie 2026.
  • Identificare: GHSA-w8hw-w9fx-j79w.
  • Scop: Limită de acoperire pentru OOM, amplificare în mai multe părți, diferență și atenuare SAPI.
  • Referință: RCE via OOM corruption

S3 — CVE-2026-109619 Buletin Tehnic Oficial

  • Sursa: php/php-src GitHub Security Advisory, 21 octombrie 2026.
  • Identificare: GHSA-6wmf-4rv5-p3rp.
  • Scop: Stare de suspendare a cererilor încrucișate, producători și consumatori, inițializare timpurie, atenuare a configurației.
  • Referință: RCE via stale global state

S4 — PHP 8.5 trimitere oficială a remedierii

  • Sursa: php/php-src.
  • Trimiteți: 31c0ea7d7ff1d1fccb6492e52dab544011628065.
  • Scop: Confirmați transmiterea oficială pentru a remedia două vulnerabilități în același timp și explicați direcția generală a schimbării.
  • Referință: Avoid state corruption via bailout

S5 — PHP 8.5 Diferența completă și restaurată oficial

  • Sursa: diferență de aceeași transmitere oficială.
  • Scop: Verificați implementarea specifică a alocătorului, VM, HTTP globals, sesiune, serializare și ciclu de viață al cererii.
  • Referință: official complete diff

S6 — PHP 8.1 transmitere oficială de backport de urgență

S7 — PHP 7.4 sucursală oficială backport de urgență

S8 — PHP 8.0 sucursală oficială backport de urgență

S9 — PHP 8.1 sucursală oficială backport de urgență

S10 — Ubuntu Buletin de securitate USN-8948-1

  • Sursa: Canonical / Ubuntu, 21 octombrie 2026.
  • Scop: Lansați backport și exemple de versiuni complete de pachet.
  • Referință: USN-8948-1: PHP vulnerabilities

S11 — Manual de configurare PHP-FPM

  • Sursa: document oficial PHP.
  • Scop: semantică de configurare, cum ar fi php_admin_value, php_admin_flag, pm.max_requests etc.
  • Referință: PHP-FPM Configuration

S12 — PHP Core INI Manual de configurare

  • Sursa: document oficial PHP.
  • Scop: Definirea și domeniul de aplicare al corpului cererii, încărcare, memorie și configurație automată de citire POST.
  • Referință: Description of core php.ini directives

S13 — Nginx solicită limita de dimensiune a corpului

S14 — Nginx FastCGI tampon de solicitare

S15 — Nginx Instrucțiuni de stare și returnare

  • Sursa: document oficial Nginx.
  • Scop: Sintaxa de configurare a if și return.
  • Referință: ngx_http_rewrite_module

S16 — Cloudflare PHP2Shell Instrucțiuni de protecție