Ukratko: Kod cloud i PaaS pružatelja zakrpu ne postavlja automatski pružatelj. Ako on upravlja PHP runtimeom, ažurira ga, no često tek uz sljedeći deployment. Gradite li image-e ili buildove sami ili sami vodite platformu, morate ponovno graditi i isporučivati. Mjerodavan je uvijek runtime koji Vaša web-stranica upravo isporučuje.
PHP ažuriranje kod PaaS-a: kome pripada runtime?
Platformske usluge, u struci PaaS (Platform as a Service), tvrtkama preuzimaju vođenje poslužitelja. Učitate kod, platforma ga gradi i pokreće. Kod PHP2Shella iz toga nastaje tipična nesigurnost: tko zapravo mora ažurirati PHP?
Vercel to u svom biltenu o PHP2Shellu sažima ovako: ažuriranje lokalnog razvojnog okruženja, koda aplikacije ili dodataka nije dovoljno. Odlučujući je PHP runtime deploymenta koji doista odgovara na zahtjeve. Je li taj runtime zakrpan, ovisi o tome tko ga stavlja na raspolaganje i kada je zadnji put izgrađen.
Četiri modela poslovanja u usporedbi
Nazivi pružatelja razlikuju se. Za pitanje zakrpe većina se ponuda može svrstati u jedan od ovih modela:
| Model | Tko ažurira PHP? | Što morate učiniti |
|---|---|---|
| Runtime kojim upravlja pružatelj | Pružatelj | Zatražiti potvrdu, po potrebi ponovno deployati da novi runtime stupi na snagu |
| Runtime temeljen na buildu (buildpack) | Pružatelj stavlja na raspolaganje novu verziju, Vaš build je utvrđuje | Pokrenuti novi build, provjeriti verziju u zapisniku builda |
| Vlastiti image kontejnera | Vi | Ponovno izgraditi image s ispravljenim PHP-om i isporučiti |
| Samostalno vođena platforma | Vi, za platformu i aplikacije | Zakrpati platformu i svaku aplikaciju zasebno |
Mnoge tvrtke koriste više modela istodobno, primjerice runtime pod upravljanjem za web-stranicu i vlastite kontejnere za interne alate. Svaka aplikacija stoga treba vlastiti odgovor.
Zamka je skrivena u riječi „upravljan“. Čak i kad pružatelj održava runtime, već isporučena aplikacija često radi dalje sa stanjem s kojim je izgrađena. Nova verzija tada stupa na snagu tek pri sljedećem buildu ili deploymentu. Neke platforme uz to drže starije deploymente ili pregledna okruženja dostupnima pod vlastitim adresama. Zato ne pitajte samo je li pružatelj zakrpao, nego i od kada Vaše aktivne instance koriste zakrpu te što se događa sa starim deploymentima.
Što Vercel i Coolify kažu o PHP2Shellu
Dva su pružatelja javno objavila svoje napomene. Poučne su jer jasno imenuju granice vlastitih zaštitnih mjera.
Vercel je prema vlastitom biltenu prije objave aktivirao zaštitna pravila u svom Web Application Firewallu (WAF), filteru web-zahtjeva. Vrijede automatski za PHP funkcije na Vercelu i za zahtjeve koje Vercel prosljeđuje vanjskim PHP poslužiteljima. Istodobno Vercel traži da se PHP runtime odmah ažurira na ispravljenu verziju. Deploymente u kontejnerima treba ponovno izgraditi s ažuriranim PHP osnovnim image-om i isporučiti. Zahtjeve koji zaobilaze Vercel i idu izravno na vanjski PHP poslužitelj WAF ne pokriva.
Coolify, platforma koju možete sami voditi, prema vlastitom je advisoryju i sam bio pogođen: sve grane verzije 4. Kao prva ispravljena stanja Coolify navodi 4.0.1, 4.1.3, 4.2.1, 4.3.24 i 4.4.7 te preporučuje 4.4.7. Važan je dodatak: Coolify ažuriranje ne ažurira PHP aplikacije koje preko njega vodite. Njihove runtimeove ili image-e morate zasebno ažurirati te ponovno izgraditi ili isporučiti. Prema Coolifyju to vrijedi i za korisnike Coolify Clouda te i iza Cloudflarea, jer Cloudflare pravila provjeravaju samo promet koji ide preko Cloudflarea.
Što Cloudflare pravila postižu, razvrstava članak Cloudflare zaštitna pravila protiv PHP2Shella.
Kako provjeriti runtime koji se isporučuje
Sljedeći koraci rade neovisno o pružatelju. Ciljaju na dokaz, a ne na osjećaj.
- Popisati sva okruženja: produkcija, staging, pregledni deploymenti i pozadinske usluge poput queue workera. Svako okruženje može imati drugi runtime.
- Očitati verziju runtimea po okruženju: u konzoli pružatelja, u zapisniku builda ili u konfiguracijskoj datoteci projekta.
- Provjeriti datum zadnjeg deploymenta: Ako je prije 21. 10. 2026., vrlo vjerojatno još radi stari runtime, osim ako pružatelj izričito ne potvrdi drukčije.
- Pogledati u aktivnoj instanci: Ako platforma nudi konzolu, sljedeća naredba prikazuje verziju instance.
- Uključiti vanjske PHP poslužitelje: Poslužitelji kojima platforma prosljeđuje zahtjeve trebaju vlastito ažuriranje i ne bi smjeli biti izravno dostupni s interneta.
# U konzoli aktivne instance (ako je pružatelj nudi)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Očekuju se 8.5.12, 8.4.27, 8.3.36 ili 8.2.35 ili backport koji je potvrdio pružatelj. Imajte na umu da naredbeni redak instance ne koristi uvijek isti runtime kao web-proces. Za provjeru ne postavljajte javno dostupnu phpinfo datoteku. Kako ispravno tumačiti broj verzije i stanje backporta, opisuje Provjera PHP verzije i stanja zakrpe.
Novi deployment ne uklanja zlonamjerni softver koji je prije dospio u trajnu pohranu, poput volumena za prijenose ili baze podataka. Ta područja provjerite zasebno.
Odgovornost zabilježiti pisano
PHP2Shell pokazuje koliko je granica između platforme i klijenta često nejasna. Za svaku aplikaciju zabilježite tko daje runtime, tko pri sigurnosnim objavama ponovno gradi i kako pružatelj najavljuje zakrpe. Tome pripada i tko ima pristup konzoli platforme kad je hitno te tko izvan radnog vremena smije pokrenuti novi build.
Za vlastitu dokumentaciju dovoljna je kratka tablica po aplikaciji: platforma, model poslovanja, PHP grana, datum zadnjeg builda, odgovorna osoba. Tko tu listu ima pri ruci kod sljedeće objave, štedi dane koje su mnogi timovi nakon 21. listopada potrošili na traženje. Kod aplikacija u kontejnerima tu spada i tko održava osnovni image; pozadinu objašnjava stranica PHP u kontejnerima.
Za upravljane poslužitelje bez PaaS karaktera vrijede slična pitanja koja smo saželi u članku Upravljani poslužitelj: razjasniti odgovornost.
Kako PHP SOS konkretno pomaže?
- Razvrstati: Svaku Vašu aplikaciju razvrstavamo u model poslovanja i razjašnjavamo tko daje PHP runtime.
- Dokazati: Provjeravamo runtime, datum builda i deployment po okruženju te dokumentiramo rezultat.
- Ponovno graditi i isporučiti: Putem PHP usluge zakrpa ažuriramo image-e i buildove i kontrolirano ih isporučujemo.
- Zatvoriti praznine: Provjeravamo jesu li vanjski PHP poslužitelji izravno dostupni i ograničavamo pristup.
Česta pitanja
Zakrpava li moj PaaS pružatelj PHP automatski?
To ovisi o modelu. Ako pružatelj upravlja runtimeom, on ga ažurira, no često tek za nove deploymente. Ako image-e ili buildove gradite sami, morate ponovno graditi i ponovno isporučiti. Zatražite potvrdu stanja za svoju aplikaciju.
Je li WAF mog platformskog pružatelja dovoljan protiv PHP2Shella?
Ne. Vercel i Coolify izričito pišu da zaštitna pravila ne zamjenjuju ažuriranje PHP runtimea. Uz to djeluju samo na promet koji ide preko platforme.
Moram li nakon zakrpe ponovno deployati?
Često da. Vercel za deploymente u kontejnerima navodi ponovnu izgradnju s ažuriranim PHP osnovnim image-om i novi deployment. Kod platformi temeljenih na buildu runtime se utvrđuje pri buildu; tek novi build preuzima zakrpu.
Koristim Coolify. Je li dovoljno Coolify ažuriranje?
Ne. Prema Coolify advisoryju ažuriranje ažurira samo sam Coolify. PHP runtimeove ili image-e kontejnera svojih aplikacija morate zasebno ažurirati te ponovno izgraditi ili ponovno isporučiti.