Kort sagt: Hos moln- och PaaS-leverantörer patchar inte leverantören automatiskt. Sköter den PHP-körmiljön uppdaterar den den, ofta dock först vid nästa deployment. Bygger ni images eller builds själva eller driver plattformen själva måste ni bygga om och rulla ut. Avgörande är alltid den körmiljö som er webbplats levererar just nu.
PHP-uppdatering hos PaaS: vem äger körmiljön?
Plattformstjänster, på fackspråk PaaS (Platform as a Service), tar över serverdriften åt företag. Ni laddar upp kod, plattformen bygger och driver den. Vid PHP2Shell uppstår därav en typisk osäkerhet: vem ska egentligen uppdatera PHP?
Vercel sammanfattar det i sitt bulletin om PHP2Shell: en uppdatering av den lokala utvecklingsmiljön, av applikationskoden eller av plugins räcker inte. Avgörande är PHP-körmiljön för den deployment som faktiskt besvarar förfrågningar. Om den körmiljön är patchad beror på vem som tillhandahåller den och när den byggdes senast.
Fyra driftmodeller i jämförelse
Leverantörernas beteckningar skiljer sig åt. För patchfrågan kan de flesta erbjudanden föras till en av dessa modeller:
| Modell | Vem uppdaterar PHP? | Vad ni måste göra |
|---|---|---|
| Körmiljö som leverantören sköter | Leverantören | Hämta bekräftelse, vid behov deploya om så att den nya körmiljön får verkan |
| Build-baserad körmiljö (buildpack) | Leverantören tillhandahåller ny version, ert bygge lägger fast den | Utlös en ny build, kontrollera versionen i byggloggen |
| Egen container-image | Ni | Bygg om imagen med rättat PHP och rulla ut |
| Egendriven plattform | Ni, för plattform och applikationer | Patcha plattformen och varje applikation för sig |
Många företag använder flera modeller samtidigt, till exempel en skött körmiljö för webbplatsen och egna containrar för interna verktyg. Varje applikation behöver därför ett eget svar.
En fälla ligger i ordet ”skött”. Även om leverantören underhåller körmiljön fortsätter en redan utrullad applikation ofta att köra med den nivå den byggdes med. Den nya versionen får då verkan först vid nästa build eller deployment. Vissa plattformar håller dessutom äldre deployments eller förhandsgranskningsmiljöer nåbara på egna adresser. Fråga därför inte bara om leverantören har patchat, utan också från när era körande instanser använder patchen och vad som händer med gamla deployments.
Vad Vercel och Coolify säger om PHP2Shell
Två leverantörer har gjort sina anvisningar offentliga. De är lärorika eftersom de tydligt anger gränserna för de egna skyddsåtgärderna.
Vercel har enligt eget bulletin före publiceringen aktiverat skyddsregler i sin Web Application Firewall (WAF), ett filter för webbförfrågningar. De gäller automatiskt för PHP-funktioner på Vercel och för förfrågningar som Vercel vidarebefordrar till externa PHP-servrar. Samtidigt kräver Vercel att PHP-körmiljön omedelbart uppdateras till en rättad version. Container-deployments ska byggas om med en uppdaterad PHP-basimage och rullas ut. Förfrågningar som går förbi Vercel och direkt till en extern PHP-server täcker WAF inte.
Coolify, en plattform som kan drivas själv, var enligt eget advisory självt berört: alla grenar av version 4. Som första rättade nivåer anger Coolify 4.0.1, 4.1.3, 4.2.1, 4.3.24 och 4.4.7 och rekommenderar 4.4.7. Viktigt är tillägget: Coolify-uppdateringen uppdaterar inte de PHP-applikationer som ni driver via den. Deras körmiljöer eller images måste ni uppdatera separat och bygga om respektive rulla ut. Det gäller enligt Coolify även kunder hos Coolify Cloud och även bakom Cloudflare, eftersom Cloudflare-regler bara granskar trafik som går via Cloudflare.
Vad Cloudflare-regler åstadkommer placerar inlägget Cloudflares skyddsregler mot PHP2Shell in i sitt sammanhang.
Så kontrollerar ni den levererande körmiljön
Stegen nedan fungerar oberoende av leverantör. De syftar på ett bevis, inte på en känsla.
- Lista alla miljöer: Produktion, staging, förhandsgranskningsdeployments och bakgrundstjänster som queue-workers. Varje miljö kan ha en annan körmiljö.
- Läs av körmiljöversionen per miljö: i leverantörens konsol, i byggloggen eller i projektets konfigurationsfil.
- Kontrollera datumet för den senaste deploymenten: Ligger det före den 21 oktober 2026 körs med hög sannolikhet fortfarande den gamla körmiljön, om inte leverantören uttryckligen bekräftar något annat.
- Titta efter i den körande instansen: Erbjuder plattformen en konsol visar kommandot nedan instansens version.
- Ta med externa PHP-servrar: Servrar dit plattformen vidarebefordrar förfrågningar behöver en egen uppdatering och bör inte vara direkt nåbara från internet.
# I konsolen för den körande instansen (om leverantören erbjuder det)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Förväntat resultat är 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller en backport som leverantören har bekräftat. Observera att en instans kommandorad inte alltid använder samma körmiljö som webbprocessen. Lägg inte upp någon offentligt nåbar phpinfo-fil för kontrollen. Hur ni tolkar versionsnummer och backport-nivå på rätt sätt beskrivs i Kontrollera PHP-version och patchnivå.
En ny deployment tar inte bort skadlig kod som tidigare har kommit in i beständiga lagringsplatser som uppladdningsvolymer eller databasen. De områdena granskar ni separat.
Dokumentera ansvaret skriftligt
PHP2Shell visar hur oklar gränsen mellan plattform och kund ofta är. Fastställ för varje applikation vem som tillhandahåller körmiljön, vem som bygger om vid säkerhetsmeddelanden och hur leverantören aviserar patchar. Dit hör också vem som har tillgång till plattformens konsol när det brådskar, och vem som utanför kontorstid får utlösa en ny build.
För den egna dokumentationen räcker en kort tabell per applikation: plattform, driftmodell, PHP-gren, datum för senaste bygget, ansvarig. Den som har den listan till hands vid nästa meddelande sparar de dagar som många team ägnade åt letande efter den 21 oktober. För containerapplikationer hör dit vem som underhåller basimagen; bakgrunden förklaras i PHP i containrar.
För hanterade servrar utan PaaS-karaktär gäller liknande frågor, som vi har sammanfattat under Managed server: klargör ansvaret.
Hur hjälper PHP SOS konkret?
- Tilldela: Vi för varje applikation till en driftmodell och klarlägger vem som tillhandahåller PHP-körmiljön.
- Styrka: Vi kontrollerar körmiljö, byggdatum och deployment per miljö och dokumenterar resultatet.
- Bygga om och rulla ut: Via PHP-patchtjänsten uppdaterar vi images och builds och rullar ut dem kontrollerat.
- Stänga luckor: Vi kontrollerar om externa PHP-servrar är direkt nåbara och begränsar åtkomsten.
Vanliga frågor
Patchar min PaaS-leverantör PHP automatiskt?
Det beror på modellen. Sköter leverantören körmiljön uppdaterar den den, ofta dock först för nya deployments. Bygger ni images eller builds själva måste ni bygga om och rulla ut på nytt. Låt bekräfta nivån för er applikation.
Räcker min plattformsleverantörs WAF mot PHP2Shell?
Nej. Vercel och Coolify skriver uttryckligen att skyddsregler inte ersätter uppdateringen av PHP-körmiljön. De verkar dessutom bara på trafik som går via plattformen.
Måste jag göra en ny deployment efter patchen?
Ofta ja. Vercel nämner för container-deployments ombyggnad med uppdaterad PHP-basimage och en ny deployment. På build-baserade plattformar läggs körmiljön fast vid bygget; först en ny build tar över patchen.
Jag använder Coolify. Räcker Coolify-uppdateringen?
Nej. Enligt Coolify-advisoryn uppdaterar uppdateringen bara Coolify självt. PHP-körmiljöerna eller container-imagerna för era applikationer måste ni uppdatera separat och bygga om respektive rulla ut på nytt.