Pe scurt: La furnizorii cloud și PaaS nu face automat patch furnizorul. Dacă el administrează runtime-ul PHP, îl actualizează, adesea însă abia cu următorul deployment. Dacă construiți singur imaginile sau build-urile ori operați singur platforma, trebuie să reconstruiți și să redistribuiți. Decisiv este întotdeauna runtime-ul pe care îl livrează acum site-ul dumneavoastră.
Actualizarea PHP la PaaS: al cui este runtime-ul?
Serviciile de platformă, în jargonul de specialitate PaaS (Platform as a Service), scutesc companiile de operarea serverelor. Încărcați codul, platforma îl construiește și îl operează. La PHP2Shell, de aici rezultă o nesiguranță tipică: cine trebuie, de fapt, să actualizeze PHP?
Vercel o spune pe scurt în bulletinul său despre PHP2Shell: o actualizare a mediului local de dezvoltare, a codului aplicației sau a pluginurilor nu este suficientă. Decisiv este runtime-ul PHP al deployment-ului care răspunde efectiv la cereri. Dacă acest runtime este actualizat depinde de cine îl furnizează și de când a fost construit ultima dată.
Patru modele de operare comparate
Denumirile furnizorilor diferă. Pentru întrebarea despre patch, majoritatea ofertelor pot fi atribuite uneia dintre aceste modele:
| Model | Cine actualizează PHP? | Ce aveți de făcut |
|---|---|---|
| Runtime administrat de furnizor | Furnizorul | Obțineți confirmarea, eventual redistribuiți, pentru ca noul runtime să se aplice |
| Runtime bazat pe build (buildpack) | Furnizorul pune la dispoziție versiunea nouă, build-ul dumneavoastră o fixează | Declanșați un build nou, verificați versiunea în jurnalul de build |
| Imagine de container proprie | Dumneavoastră | Reconstruiți imaginea cu PHP corectat și redistribuiți-o |
| Platformă operată de dumneavoastră | Dumneavoastră, pentru platformă și aplicații | Actualizați platforma și fiecare aplicație separat |
Multe companii folosesc simultan mai multe modele, de exemplu un runtime administrat pentru site și containere proprii pentru instrumente interne. Fiecare aplicație are de aceea nevoie de un răspuns propriu.
O capcană se ascunde în cuvântul „administrat”. Chiar dacă furnizorul întreține runtime-ul, o aplicație deja distribuită continuă adesea să ruleze cu nivelul cu care a fost construită. Versiunea nouă se aplică atunci abia la următorul build sau deployment. Unele platforme mențin în plus deployment-uri mai vechi sau medii de previzualizare accesibile la adrese proprii. Întrebați de aceea nu doar dacă furnizorul a aplicat patchul, ci și de când instanțele dumneavoastră care rulează îl folosesc și ce se întâmplă cu deployment-urile vechi.
Ce spun Vercel și Coolify despre PHP2Shell
Doi furnizori și-au făcut publice indicațiile. Sunt instructive, deoarece numesc clar limitele propriilor măsuri de protecție.
Vercel a activat, conform bulletinului propriu, înainte de publicare reguli de protecție în Web Application Firewall (WAF), un filtru pentru cereri web. Ele se aplică automat funcțiilor PHP de pe Vercel și cererilor pe care Vercel le redirecționează către servere PHP externe. În același timp, Vercel cere actualizarea imediată a runtime-ului PHP la o versiune corectată. Deployment-urile cu containere trebuie reconstruite cu o imagine de bază PHP actualizată și redistribuite. Cererile care ocolesc Vercel și merg direct la un server PHP extern nu sunt acoperite de WAF.
Coolify, o platformă care poate fi operată singur, a fost, conform advisory-ului propriu, ea însăși afectată: toate ramurile versiunii 4. Drept primele niveluri corectate, Coolify menționează 4.0.1, 4.1.3, 4.2.1, 4.3.24 și 4.4.7 și recomandă 4.4.7. Important este completarea: actualizarea Coolify nu actualizează aplicațiile PHP pe care le operați prin ea. Runtime-urile sau imaginile lor trebuie actualizate separat și reconstruite sau redistribuite. Aceasta se aplică, conform Coolify, și clienților Coolify Cloud și chiar în spatele Cloudflare, deoarece regulile Cloudflare verifică doar traficul care trece prin Cloudflare.
Ce realizează regulile Cloudflare încadrează articolul Reguli de protecție Cloudflare împotriva PHP2Shell.
Cum verificați runtime-ul care livrează
Pașii următori funcționează indiferent de furnizor. Ei vizează o dovadă, nu o senzație.
- Listați toate mediile: producție, staging, deployment-uri de previzualizare și servicii de fundal precum workerii de coadă. Fiecare mediu poate avea un alt runtime.
- Citiți versiunea runtime-ului pentru fiecare mediu: în consola furnizorului, în jurnalul de build sau în fișierul de configurare al proiectului.
- Verificați data ultimului deployment: Dacă este anterioară datei de 21.10.2026, cu mare probabilitate rulează încă vechiul runtime, dacă furnizorul nu confirmă explicit altceva.
- Priviți în instanța care rulează: Dacă platforma oferă o consolă, comanda următoare arată versiunea instanței.
- Includeți serverele PHP externe: Serverele către care platforma redirecționează cereri au nevoie de propria actualizare și nu ar trebui să fie accesibile direct din internet.
# În consola instanței care rulează (dacă este oferită de furnizor)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Se așteaptă 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 ori un backport confirmat de furnizor. Rețineți că linia de comandă a unei instanțe nu folosește întotdeauna același runtime ca procesul web. Nu creați pentru verificare un fișier phpinfo accesibil public. Cum interpretați corect numărul versiunii și nivelul backportului descrie Verificarea versiunii PHP și a nivelului de patch.
Un deployment nou nu elimină programele malițioase care au ajuns înainte în stocări persistente, precum volumele de upload sau baza de date. Verificați aceste zone separat.
Consemnați responsabilitatea în scris
PHP2Shell arată cât de neclară este adesea granița dintre platformă și client. Consemnați pentru fiecare aplicație cine furnizează runtime-ul, cine reconstruiește la anunțurile de securitate și cum anunță furnizorul patchurile. Aici intră și cine are acces la consola platformei când este urgent și cine poate declanșa un build nou în afara programului de lucru.
Pentru propria documentație este suficient un tabel scurt pentru fiecare aplicație: platforma, modelul de operare, ramura PHP, data ultimului build, responsabilul. Cine are această listă la îndemână la următorul anunț economisește zilele pe care multe echipe le-au petrecut căutând după 21 octombrie. La aplicațiile cu containere, aici intră și cine întreține imaginea de bază; contextul îl explică PHP în containere.
Pentru serverele administrate fără caracter PaaS se aplică întrebări similare, pe care le-am rezumat la Server administrat: clarificarea responsabilității.
Cum ajută PHP SOS concret?
- Atribuirea: Atribuim fiecare dintre aplicațiile dumneavoastră unui model de operare și clarificăm cine furnizează runtime-ul PHP.
- Dovedirea: Verificăm runtime-ul, data build-ului și deployment-ul pentru fiecare mediu și documentăm rezultatul.
- Reconstruire și redistribuire: Prin serviciul de patch PHP actualizăm imaginile și build-urile și le redistribuim controlat.
- Închiderea lacunelor: Verificăm dacă serverele PHP externe sunt accesibile direct și restrângem accesul.
Întrebări frecvente
Aplică furnizorul meu PaaS patchul PHP automat?
Depinde de model. Dacă furnizorul administrează runtime-ul, îl actualizează, adesea însă abia pentru deployment-urile noi. Dacă construiți singur imaginile sau build-urile, trebuie să reconstruiți și să redistribuiți. Faceți-vă confirmat nivelul pentru aplicația dumneavoastră.
Este suficient WAF-ul furnizorului meu de platformă împotriva PHP2Shell?
Nu. Vercel și Coolify scriu explicit că regulile de protecție nu înlocuiesc actualizarea runtime-ului PHP. În plus, ele acționează doar asupra traficului care trece prin platformă.
Trebuie să fac un deployment nou după patch?
Adesea da. Vercel menționează pentru deployment-urile cu containere reconstruirea cu o imagine de bază PHP actualizată și un deployment nou. La platformele bazate pe build, runtime-ul este fixat la build; abia un build nou preia patchul.
Folosesc Coolify. Este suficientă actualizarea Coolify?
Nu. Conform advisory-ului Coolify, actualizarea actualizează doar Coolify însuși. Runtime-urile PHP sau imaginile de container ale aplicațiilor dumneavoastră trebuie actualizate separat și reconstruite sau redistribuite.