Kort sagt: Hos cloud- og PaaS-udbydere patcher udbyderen ikke automatisk. Administrerer den PHP-kørselsmiljøet, opdaterer den det, men ofte først med det næste deployment. Bygger I images eller builds selv eller driver I platformen selv, skal I bygge om og udrulle. Afgørende er altid det kørselsmiljø, som jeres website lige nu leverer.
PHP-opdatering hos PaaS: Hvem ejer kørselsmiljøet?
Platformtjenester, i fagsproget PaaS (Platform as a Service), tager serverdriften fra virksomhederne. I uploader kode, platformen bygger og driver den. Ved PHP2Shell opstår der heraf en typisk usikkerhed: Hvem skal egentlig opdatere PHP?
Vercel sætter det på spidsen i sin bulletin om PHP2Shell: En opdatering af det lokale udviklingsmiljø, af applikationskoden eller af plugins er ikke nok. Afgørende er PHP-kørselsmiljøet i det deployment, der faktisk besvarer forespørgsler. Om dette kørselsmiljø er patchet, afhænger af, hvem der stiller det til rådighed, og hvornår det sidst blev bygget.
Fire driftsmodeller sammenlignet
Udbydernes betegnelser er forskellige. For patch-spørgsmålet lader de fleste tilbud sig henføre til en af disse modeller:
| Model | Hvem opdaterer PHP? | Hvad I skal gøre |
|---|---|---|
| Kørselsmiljø administreret af udbyderen | Udbyderen | Indhent bekræftelse, deploy evt. på ny, så det nye kørselsmiljø tager over |
| Build-baseret kørselsmiljø (buildpack) | Udbyderen stiller ny version til rådighed, jeres build fastlåser den | Udløs et nyt build, kontrollér versionen i build-loggen |
| Eget container-image | I | Byg imaget om med rettet PHP, og udrul det |
| Selvdrevet platform | I, for platform og applikationer | Patch platformen og hver applikation for sig |
Mange virksomheder bruger flere modeller samtidig, f.eks. et administreret kørselsmiljø til websitet og egne containere til interne værktøjer. Hver applikation har derfor brug for sit eget svar.
En fælde gemmer sig i ordet „administreret“. Selv om udbyderen vedligeholder kørselsmiljøet, kører en allerede udrullet applikation ofte videre med den status, den blev bygget med. Den nye version tager så først over ved det næste build eller deployment. Nogle platforme holder desuden ældre deployments eller preview-miljøer tilgængelige på egne adresser. Spørg derfor ikke kun, om udbyderen har patchet, men også, fra hvornår jeres kørende instanser bruger patchen, og hvad der sker med gamle deployments.
Hvad Vercel og Coolify siger om PHP2Shell
To udbydere har offentliggjort deres henvisninger. De er lærerige, fordi de klart angiver grænserne for deres egne beskyttelsesforanstaltninger.
Vercel har ifølge sin egen bulletin før offentliggørelsen aktiveret beskyttelsesregler i sin web application firewall (WAF), et filter for webforespørgsler. De gælder automatisk for PHP-funktioner på Vercel og for forespørgsler, som Vercel videresender til eksterne PHP-servere. Samtidig kræver Vercel, at PHP-kørselsmiljøet straks opdateres til en rettet version. Container-deployments skal bygges om med et opdateret PHP-basisimage og udrulles. Forespørgsler, der omgår Vercel og går direkte til en ekstern PHP-server, dækker WAF'en ikke.
Coolify, en platform, der kan drives selv, var ifølge sin egen advisory selv berørt: alle grene af version 4. Som første rettede statusser nævner Coolify 4.0.1, 4.1.3, 4.2.1, 4.3.24 og 4.4.7 og anbefaler 4.4.7. Vigtigt er tilføjelsen: Coolify-opdateringen opdaterer ikke de PHP-applikationer, I driver via den. Deres kørselsmiljøer eller images skal I opdatere separat og bygge om eller udrulle. Det gælder ifølge Coolify også for kunder hos Coolify Cloud og også bag Cloudflare, fordi Cloudflare-regler kun kontrollerer trafik, der løber via Cloudflare.
Hvad Cloudflare-regler kan, indplacerer indlægget Cloudflare-beskyttelsesregler mod PHP2Shell.
Sådan kontrollerer I det leverende kørselsmiljø
Følgende skridt fungerer uafhængigt af udbyderen. De sigter mod et bevis, ikke en fornemmelse.
- Opregn alle miljøer: produktion, staging, preview-deployments og baggrundstjenester som queue-workers. Hvert miljø kan have et andet kørselsmiljø.
- Aflæs kørselsmiljøets version pr. miljø: i udbyderens konsol, i build-loggen eller i projektets konfigurationsfil.
- Kontrollér datoen for det seneste deployment: Ligger den før 21.10.2026, kører der med stor sandsynlighed stadig det gamle kørselsmiljø, hvis udbyderen ikke udtrykkeligt bekræfter noget andet.
- Se efter i den kørende instans: Tilbyder platformen en konsol, viser den følgende kommando instansens version.
- Medregn eksterne PHP-servere: Servere, som platformen videresender forespørgsler til, kræver en egen opdatering og bør ikke kunne nås direkte fra internettet.
# I konsollen for den kørende instans (hvis udbyderen tilbyder den)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Forventet er 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller en backport bekræftet af udbyderen. Bemærk, at en instans' kommandolinje ikke altid bruger samme kørselsmiljø som webprocessen. Opret ikke en offentligt tilgængelig phpinfo-fil til kontrollen. Hvordan I fortolker versionsnummer og backport-status korrekt, beskriver Kontrollér PHP-version og patchstatus.
Et nyt deployment fjerner ikke malware, der tidligere er kommet ind i persistente lagre som upload-volumener eller databasen. Disse områder kontrollerer I separat.
Fastlæg ansvaret skriftligt
PHP2Shell viser, hvor uklar grænsen mellem platform og kunde ofte er. Fastlæg for hver applikation, hvem der stiller kørselsmiljøet, hvem der bygger om ved sikkerhedsmeddelelser, og hvordan udbyderen varsler patches. Dertil hører også, hvem der har adgang til platformens konsol, når det haster, og hvem der uden for arbejdstiden må udløse et nyt build.
Til jeres egen dokumentation rækker en kort tabel pr. applikation: platform, driftsmodel, PHP-gren, dato for det seneste build, ansvarlig. Den, der har denne liste ved hånden ved den næste meddelelse, sparer de dage, som mange teams efter den 21. oktober brugte på at lede. Ved container-applikationer hører det med, hvem der vedligeholder basisimaget; baggrunden forklarer PHP i containere.
For administrerede servere uden PaaS-karakter gælder lignende spørgsmål, som vi har samlet under Managed server: Afklar ansvaret.
Hvordan hjælper PHP SOS konkret?
- Tilknyt: Vi henfører hver af jeres applikationer til en driftsmodel og afklarer, hvem der stiller PHP-kørselsmiljøet.
- Dokumentér: Vi kontrollerer kørselsmiljø, builddato og deployment pr. miljø og dokumenterer resultatet.
- Byg om og udrul: Via PHP-patchservice opdaterer vi images og builds og udruller dem kontrolleret.
- Luk huller: Vi kontrollerer, om eksterne PHP-servere kan nås direkte, og begrænser adgangen.
Ofte stillede spørgsmål
Patcher min PaaS-udbyder PHP automatisk?
Det afhænger af modellen. Administrerer udbyderen kørselsmiljøet, opdaterer den det, men ofte først for nye deployments. Bygger I selv images eller builds, skal I bygge om og udrulle på ny. Lad jer bekræfte statussen for jeres applikation.
Er min platformudbyders WAF nok mod PHP2Shell?
Nej. Vercel og Coolify skriver udtrykkeligt, at beskyttelsesregler ikke erstatter opdateringen af PHP-kørselsmiljøet. De virker desuden kun på trafik, der løber via platformen.
Skal jeg deploye på ny efter patchen?
Ofte ja. Vercel nævner for container-deployments genopbygning med et opdateret PHP-basisimage og et nyt deployment. På build-baserede platforme fastlåses kørselsmiljøet ved buildet; først et nyt build overtager patchen.
Jeg bruger Coolify. Er Coolify-opdateringen nok?
Nej. Ifølge Coolify-advisoryen opdaterer opdateringen kun Coolify selv. PHP-kørselsmiljøerne eller container-imagene for jeres applikationer skal I opdatere separat og bygge om eller udrulle på ny.