Kort gezegd: Bij cloud- en PaaS-aanbieders patcht niet automatisch de aanbieder. Beheert hij de PHP-runtime, dan werkt hij die bij, vaak echter pas met de volgende deployment. Bouwt u images of builds zelf, of draait u het platform zelf, dan moet u opnieuw bouwen en uitrollen. Maatgevend is altijd de runtime die uw website op dat moment levert.
PHP-update bij PaaS: van wie is de runtime?
Platformdiensten, in vakjargon PaaS (Platform as a Service), nemen bedrijven het serverbeheer uit handen. U uploadt code, het platform bouwt en draait die. Bij PHP2Shell ontstaat daaruit een typische onzekerheid: wie moet PHP eigenlijk bijwerken?
Vercel brengt het in zijn bulletin over PHP2Shell op het punt: een update van de lokale ontwikkelomgeving, de applicatiecode of de plug-ins volstaat niet. Beslissend is de PHP-runtime van de deployment die daadwerkelijk verzoeken beantwoordt. Of die runtime gepatcht is, hangt af van wie haar levert en wanneer ze voor het laatst is gebouwd.
Vier bedrijfsmodellen vergeleken
De benamingen van de aanbieders verschillen. Voor de patchvraag zijn de meeste aanbiedingen aan een van deze modellen toe te wijzen:
| Model | Wie werkt PHP bij? | Wat u moet doen |
|---|---|---|
| Door de aanbieder beheerde runtime | Aanbieder | Bevestiging vragen, zo nodig opnieuw deployen zodat de nieuwe runtime ingaat |
| Buildgebaseerde runtime (buildpack) | Aanbieder stelt nieuwe versie beschikbaar, uw build legt haar vast | Nieuwe build starten, versie in het buildlog controleren |
| Eigen containerimage | U | Image met verholpen PHP opnieuw bouwen en uitrollen |
| Zelf gedraaid platform | U, voor platform en applicaties | Platform patchen en elke applicatie afzonderlijk |
Veel bedrijven gebruiken meerdere modellen tegelijk, bijvoorbeeld een beheerde runtime voor de website en eigen containers voor interne tools. Elke applicatie heeft daarom een eigen antwoord nodig.
Een valkuil zit in het woord "beheerd". Ook als de aanbieder de runtime onderhoudt, draait een reeds uitgerolde applicatie vaak door met de stand waarmee ze is gebouwd. De nieuwe versie gaat dan pas in bij de volgende build of deployment. Sommige platformen houden bovendien oudere deployments of previewomgevingen onder eigen adressen bereikbaar. Vraag daarom niet alleen of de aanbieder heeft gepatcht, maar ook vanaf wanneer uw draaiende instanties de patch gebruiken en wat er met oude deployments gebeurt.
Wat Vercel en Coolify over PHP2Shell zeggen
Twee aanbieders hebben hun aanwijzingen openbaar gemaakt. Ze zijn leerzaam, omdat ze de grenzen van hun eigen beschermingsmaatregelen duidelijk benoemen.
Vercel heeft volgens het eigen bulletin vóór de publicatie beschermingsregels in zijn Web Application Firewall (WAF), een filter voor webverzoeken, geactiveerd. Ze gelden automatisch voor PHP-functies op Vercel en voor verzoeken die Vercel naar externe PHP-servers doorstuurt. Tegelijk vraagt Vercel de PHP-runtime onmiddellijk bij te werken naar een verholpen versie. Containerdeployments moeten met een bijgewerkte PHP-basisimage opnieuw worden gebouwd en uitgerold. Verzoeken die Vercel omzeilen en rechtstreeks naar een externe PHP-server gaan, dekt de WAF niet.
Coolify, een zelf te draaien platform, was volgens het eigen advisory zelf getroffen: alle takken van versie 4. Als eerste verholpen standen noemt Coolify 4.0.1, 4.1.3, 4.2.1, 4.3.24 en 4.4.7 en adviseert 4.4.7. Belangrijk is de toevoeging: de Coolify-update werkt de PHP-applicaties die u erop draait niet bij. Hun runtimes of images moet u afzonderlijk bijwerken en opnieuw bouwen of uitrollen. Dat geldt volgens Coolify ook voor klanten van Coolify Cloud en ook achter Cloudflare, omdat Cloudflare-regels alleen verkeer controleren dat via Cloudflare loopt.
Wat Cloudflare-regels bieden, plaatst het artikel Cloudflare-beschermingsregels tegen PHP2Shell in perspectief.
Zo controleert u de leverende runtime
De onderstaande stappen werken los van de aanbieder. Ze mikken op een bewijs, niet op een gevoel.
- Alle omgevingen opsommen: productie, staging, preview-deployments en achtergronddiensten zoals queue-workers. Elke omgeving kan een andere runtime hebben.
- Runtimeversie per omgeving aflezen: in de console van de aanbieder, in het buildlog of in het configuratiebestand van het project.
- Datum van de laatste deployment controleren: ligt die vóór 21 oktober 2026, dan draait met grote waarschijnlijkheid nog de oude runtime, tenzij de aanbieder uitdrukkelijk iets anders bevestigt.
- In de draaiende instantie kijken: biedt het platform een console, dan toont de volgende opdracht de versie van de instantie.
- Externe PHP-servers meenemen: servers waarnaar het platform verzoeken doorstuurt, hebben een eigen update nodig en mogen niet rechtstreeks vanaf internet bereikbaar zijn.
# In de console van de draaiende instantie (indien door de aanbieder aangeboden)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Verwacht worden 8.5.12, 8.4.27, 8.3.36 of 8.2.35 of een door de aanbieder bevestigde backport. Houd er rekening mee dat de opdrachtregel van een instantie niet altijd dezelfde runtime gebruikt als het webproces. Maak voor de controle geen openbaar bereikbaar phpinfo-bestand aan. Hoe u versienummer en backportstand correct duidt, beschrijft PHP-versie en patchstand controleren.
Een nieuwe deployment verwijdert geen malware die eerder in persistente opslag zoals upload-volumes of de database is beland. Die gebieden controleert u apart.
Verantwoordelijkheid schriftelijk vastleggen
PHP2Shell toont hoe onduidelijk de grens tussen platform en klant vaak is. Leg voor elke applicatie vast wie de runtime levert, wie bij beveiligingsmeldingen opnieuw bouwt en hoe de aanbieder patches aankondigt. Daartoe hoort ook wie toegang heeft tot de platformconsole wanneer het dringt, en wie buiten kantooruren een nieuwe build mag starten.
Voor de eigen documentatie volstaat een korte tabel per applicatie: platform, bedrijfsmodel, PHP-tak, datum van de laatste build, verantwoordelijke. Wie die lijst bij de volgende melding bij de hand heeft, bespaart de dagen die veel teams na 21 oktober met zoeken zijn kwijtgeraakt. Bij containerapplicaties hoort daarbij wie de basisimage onderhoudt; achtergronden daarbij legt PHP in containers uit.
Voor beheerde servers zonder PaaS-karakter gelden vergelijkbare vragen, die wij onder Managed server: verantwoordelijkheid vaststellen hebben samengevat.
Hoe helpt PHP SOS concreet?
- Toewijzen: Wij wijzen elk van uw applicaties aan een bedrijfsmodel toe en stellen vast wie de PHP-runtime levert.
- Aantonen: Wij controleren runtime, builddatum en deployment per omgeving en documenteren het resultaat.
- Opnieuw bouwen en uitrollen: Via de PHP-patchservice werken wij images en builds bij en rollen wij ze gecontroleerd uit.
- Hiaten dichten: Wij controleren of externe PHP-servers rechtstreeks bereikbaar zijn en beperken de toegang.
Veelgestelde vragen
Patcht mijn PaaS-aanbieder PHP automatisch?
Dat hangt af van het model. Beheert de aanbieder de runtime, dan werkt hij die bij, vaak echter pas voor nieuwe deployments. Bouwt u images of builds zelf, dan moet u opnieuw bouwen en opnieuw uitrollen. Laat de stand voor uw applicatie bevestigen.
Volstaat de WAF van mijn platformaanbieder tegen PHP2Shell?
Nee. Vercel en Coolify schrijven uitdrukkelijk dat beschermingsregels de update van de PHP-runtime niet vervangen. Ze werken bovendien alleen op verkeer dat via het platform loopt.
Moet ik na de patch opnieuw deployen?
Vaak wel. Vercel noemt voor containerdeployments het opnieuw bouwen met een bijgewerkte PHP-basisimage en een nieuwe deployment. Bij buildgebaseerde platformen wordt de runtime bij de build vastgelegd; pas een nieuwe build neemt de patch over.
Ik gebruik Coolify. Volstaat de Coolify-update?
Nee. Volgens het Coolify-advisory werkt de update alleen Coolify zelf bij. De PHP-runtimes of containerimages van uw applicaties moet u afzonderlijk bijwerken en opnieuw bouwen of uitrollen.