--- title: "PHP2Shell: cauze și ghid de remediere" description: "Înțelegeți defectele ciclului de viață PHP2Shell, actualizările de rulare, atenuările temporare, selecția patch-urilor și verificarea prin calea de solicitare Web live." language: "ro" url: "https://keendigit.com/ro/insights/php2shell-remediation-guide" author: "KeenDigit" published: "2026-10-22" --- # PHP2Shell: cauze și ghid de remediere Înțelegeți defectele ciclului de viață PHP2Shell, actualizările de rulare, atenuările temporare, selecția patch-urilor și verificarea prin calea de solicitare Web live. **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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1); 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1) [S10](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-10) 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. [S1](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3) ## 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. [S1](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3) | Proiect | CVE-2026-109618 | CVE-2026-109619 | | ---------------------------------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | nume oficial | RCE via OOM corruption | RCE 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 tipic | Procesul de inițializare, execuție sau curățare a cererii curente | Cererea 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ății | Nu; 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ărilor | Remediați proprietatea statului, timpul de curățare și inițializarea timpurie | | Cerințe de eliminare | trebuie reparat | trebuie reparat în același timp | Baza: Două buletine oficiale de securitate și trimiteri de remedieri. [S2](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3)[S4](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-4) ### 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1) 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. [S2](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3) 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ă. [S2](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3)[S5](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-5) ### 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2) 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2) #### 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2) 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. [S1](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2) ### 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3) Analiza oficială împarte condițiile de exploatare în „producători” și „consumatori”: | rol sau condiție | sensul | Implicații pentru protecție | | ------------------------- | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | | producator de stat | Puneți statul deținut de această solicitare într-o locație care poate fi încă accesată ulterior | Pentru a verifica dacă curățarea corespunzătoare este finalizată după o ieșire anormală | | Starea rămâne | Nu 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 muncitorilor | Același lucrător continuă să proceseze cererile ulterioare | Lucrătorii multipli sunt doar o diferență de programare, nu o garanție de siguranță a memoriei | | consumator anticipat | Citiț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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3) #### 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3) 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3) 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3) 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3) ## 3. Reparați versiunea și selectarea patch-urilor ### 3.1 Linia de bază oficială a remedierii în amonte | Sucursala actuală PHP | Prima versiune care include această remediere oficială | Sugestii | | -------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | | 8.2 | 8.2.35 | Faceți upgrade la această versiune sau la o versiune ulterioară care conține aceleași remedieri | | 8.3 | 8.3.36 | La fel ca mai sus | | 8.4 | 8.4.27 | La fel ca mai sus | | 8.5 | 8.5.12 | La fel ca mai sus | | 8.1 și versiuni anterioare | Sprijinul general în amonte s-a încheiat | Prioritizează 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1) 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: ```text 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-10) ### 3.3 Alegerea patch-ului potrivit | scena | Plan prioritar | Puncte cheie pentru acceptare | | -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | Folosind pachetul de distribuție PHP | Instalați actualizări de securitate lansate de producător | Anunț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ți | Instanța care rulează folosește noua imagine; toate copiile vechi sunt eliminate | | Ramuri suportate autocompilate | Utilizați versiunea oficială de securitate a acestei ramuri sau setul complet de corecții oficiale | Potrivirea ramurilor, completarea dependenței, compatibilitatea extensiilor și trecerea regresiei | | Sub rezerva 7.4, 8.0, 8.1 | Prioritizează backport-ul furnizorului; evaluați filiala oficială a codului sursă de urgență, dacă este necesar | Identificaț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. [S1](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1)[S4](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-4)[S6](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-6) ## 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: | dovezi | Ce se poate dovedi | Nu pot dovedi nimic singur | | ------------------------------------------------------------------- | ------------------------------------------------------------- | ----------------------------------------------------- | | Manager de pachete sau metadate de imagine | Surse de instalare și versiuni complete | Traficul a fost schimbat la această instanță | | Starea procesului și a implementării | lucrătorul sau containerul completează înlocuirea | Intrarea exterioară trebuie direcționată către acesta | | Rezultate de diagnosticare restricționate accesate prin portal real | Web SAPI reală și configurație de rulare | Dacă backportul de eliberare acoperă două CVE | | Anunțul furnizorului sau înregistrarea completă a patch-urilor | Această remediere a erorilor este inclusă în această versiune | Toate 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ă. [S1](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3) ### 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2) 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. [S11](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-12) ```ini ; 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: ```ini php_admin_flag[fatal_error_backtraces] = off ``` Funcțiile și limitele fiecăruia sunt următoarele: | Configurare | efectul așteptat | Descrierea restricțiilor care trebuie păstrate | | ------------------------------------- | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | `memory_limit=-1` | Eliminați condiția previzibilă de declanșare a limitei superioare a memoriei de solicitare PHP | Nu 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 mic | Reduceți dimensiunea datelor care intră în procesul de analizare | Analizorul nefixat are decalaj cunoscut; amplificarea memoriei nu poate fi prevenită independent | | `upload_max_filesize < post_max_size` | Limitați dimensiunea unui singur fișier și rezervați spațiu de supraîncărcare pentru cerere | Nu constrânge toate câmpurile, metadatele sau alocările în aplicație | | Închideți progresul încărcării | Blocați calea aferentă sesiunii confirmate | Nu acoperă alte variante globale de stat | | PHP 8.5 închidere fatală backtrace | Blocați producătorii de statut afiliați confirmați | Nu 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. [S1](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-11) 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: ```ini 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ă. [S11](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-12) 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. [S1](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1)[S3](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3) ### 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2) 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2) 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2) ### 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: ```nginx 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. [S13](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-13)[S14](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-14) **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: ```nginx 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-15) Î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: ```ini 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. [S3](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-11) ### 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-16) 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-16) ### 5.7 De ce măsurile comune sunt insuficiente | măsuri sau hotărâri | neajunsuri | | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Închideți doar `file_uploads` | Nu poate acoperi toată procesarea în mai multe părți și nu poate aplica propria cale OOM | | Setarea `enable_post_data_reading=Off` | Schimbaț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 muncitori | Nu 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_basedir` | Aceste 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ții | Nu 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 [S2](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-3)[S12](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-12); 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: ```text 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 [S4](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-5). 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ă. [S2](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-2)[S5](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-5) Următorul este un extras din codul cheii din 8.5 diff folosit pentru a marca OOM în așteptare: ```c 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-5) 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-5) ### 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-5) 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-5) 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-5) | locație | schimba directia | Problema 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.c` | Apelați `php_basic_early_rinit()` înainte ca SAPI să fie activat | Când apare un consumator timpuriu, starea de bază relevantă nu a fost încă inițializată. | | Închideți calea lui `main/main.c` | Distrugeți HTTP globals și marcați-l ca nedefinit | Valoarea eliberată este în continuare considerată un obiect valid | | înainte ca heap-ul de cereri să fie în sfârșit eliberat | Curățați din nou ultimul mesaj de eroare | Diagnosticele de curățare tardivă repopulează starea de eroare | | `ext/session/session.c` | progresul încărcării Calea timpurie este inițializată globală a primei sesiuni | Modulul obișnuit RINIT a accesat anterior starea veche | | Cod legat de serializare | Limitați analizarea claselor și apelurile inverse ale utilizatorilor în procesarea timpurie | Executați cod de utilizator suplimentar când inițializarea nu este completă | De exemplu, secvența de pornire include: ```c zend_activate(); php_basic_early_rinit(); sapi_activate(); ``` După ce HTTP globals este distrus, adăugați semnul de eroare de stare: ```c 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-5) ### 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. [S4](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-5) ## 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: ```text 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 [S7](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-7)[S8](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-8)[S9](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-9). 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1) ### 7.1 Luați backportul PHP 8.1 ca exemplu Documentele relevante pentru PHP 8.1 sunt: ```text 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](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-6). 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. [S1](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-1)[S6](https://keendigit.com/ro/insights/php2shell-remediation-guide#source-6) ## 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 acceptare | Standarde de finalizare | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | acoperirea vulnerabilității | Anunțul despre build sau furnizor fixează în mod explicit CVE-2026-109618 și CVE-2026-109619 | | Acoperire de implementare | Toate portalurile, pool-ul, serviciile și replicile folosesc timpul de execuție reparat | | Procesul intră în vigoare | Vechiul lucrător, vechiul proces gazdă și vechiul container ies toate | | Verificarea cererii autentice | SAPI confirmat, construit și configurat cu legătura Web reală pentru a elimina direcționarea greșită a memoriei cache | | disponibilitatea afacerii | Funcțiile cheie precum sesiunea, încărcarea, importul și gestionarea erorilor au revenit în mod normal. | | Încheierea măsurilor temporare | Memoria 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. ## Anexă: Surse și link-uri citate 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](https://www.php.net/archive/2026.php#2026-10-21-5) 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](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) ### 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](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) ### 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](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065) ### 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](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065.diff) ### S6 — PHP 8.1 transmitere oficială de backport de urgență - Sursa: php/php-src. - Trimiteți: `1d7dec178a094e6e75b229ce22754045f8c6070a`. - Scop: Verificați ieșirea rapidă a ramurilor vechi și încărcați modificările comportamentului de progres. - Referință: [PHP 8.1 Emergency backport submission](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a) - Referință: [corresponds to complete diff](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a.diff) ### S7 — PHP 7.4 sucursală oficială backport de urgență - Sursa: php/php-src, PHP ramuri de cod sursă enumerate în buletinul oficial de securitate. - Referință: [PHP-7.4-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619) ### S8 — PHP 8.0 sucursală oficială backport de urgență - Sursa: php/php-src, PHP ramuri de cod sursă enumerate în buletinul oficial de securitate. - Referință: [PHP-8.0-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619) ### S9 — PHP 8.1 sucursală oficială backport de urgență - Sursa: php/php-src, PHP ramuri de cod sursă enumerate în buletinul oficial de securitate. - Referință: [PHP-8.1-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619) ### 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](https://ubuntu.com/security/notices/USN-8948-1) ### 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](https://www.php.net/manual/en/install.fpm.configuration.php) ### 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](https://www.php.net/manual/en/ini.core.php) ### S13 — Nginx solicită limita de dimensiune a corpului - Sursa: document oficial Nginx. - Scop: Semnificația lui `client_max_body_size` și nivelurile de configurare disponibile. - Referință: [ngx\_http\_core\_module / client\_max\_body\_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) ### S14 — Nginx FastCGI tampon de solicitare - Sursa: document oficial Nginx. - Scop: Secvența de procesare și funcția `fastcgi_request_buffering`. - Referință: [ngx\_http\_fastcgi\_module / fastcgi\_request\_buffering](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_request_buffering) ### 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](https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if) ### S16 — Cloudflare PHP2Shell Instrucțiuni de protecție - Sursa: blogul oficial Cloudflare. - Scop: Descrierea domeniului său de implementare WAF, aranjamentul planului Free și mecanismul de detectare. - Referință: [Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/) ## Consultanta intretinere securitate Aveți nevoie de ajutor pentru a vă actualiza sistemele PHP? Putem evalua expunerea, planifica actualizarea și verificăm aplicația care rulează. [Discutați actualizările de securitate]() [Pagina originală]() · [Index de conținut]() KeenDigit LLC · ID de înregistrare Wyoming: 2026-002106155 [Verificați cu secretarul de stat din Wyoming]() © 2026 KeenDigit LLC · Sheridan, Wyoming, SUA · Toate drepturile rezervate.