Kort gezegd: De toeleveringsketen van een website loopt van het PHP-project via distributie en hoster tot CMS, plug-ins, bureau en ingebonden diensten. Voor de IT-beveiliging telt elke schakel, want een patch bereikt uw website pas als iedereen hem heeft doorgegeven. Wie de keten opschrijft, voor elke schakel een verantwoordelijke instantie en een bewijsstuk vastlegt en toegangen beperkt, maakt haar robuust.
Een patch en zijn lange reis
Op 21 oktober 2026 om 14:00 UTC publiceerde het PHP-project de correcties voor PHP2Shell. Daarmee was het lek voor geen enkele website gedicht. Eerst moesten distributies zoals Debian, Ubuntu of de RHEL-familie de correcties in hun pakketten overnemen; volgens berichten werden backports deels nog dezelfde dag geleverd. Daarna moesten hosters en beheerders deze pakketten installeren en alle PHP-processen herstarten. Pas daarna was de betreffende website beschermd.
Elke schakel in deze keten kan vertragen. En aan elke schakel hangt een andere organisatie met eigen prioriteiten. Wie niet weet hoe zijn keten eruitziet, kan niet zeggen waar de patch op dit moment zit.
Sommige ketens hebben extra schakels die vrijwel niemand kent. Veel Debian- en Ubuntu-servers betrekken PHP niet uit de distributie, maar uit de repository van Ondřej Surý op sury.org, een veelgebruikte externe bron. Volgens berichten heeft die builds geleverd voor alle takken van 5.6 tot 8.5. Dat is nuttig, maar het is niet het beveiligingsarchief van Debian: wie deze bron gebruikt, hangt aan een andere schakel, met eigen ritme en eigen verantwoordelijkheid. Of een server zo is ingericht, blijkt uit de lijst van pakketbronnen, en precies die informatie hoort in de documentatie van de keten.
De schakels van de toeleveringsketen op een rij
De volgende tabel toont de typische schakels van een PHP-website en wat u van elke schakel kunt eisen.
| Schakel | Typisch risico | Wat u moet vastleggen |
|---|---|---|
| PHP-project | lek in de interpreter, einde van de ondersteuning | ondersteunde versie in gebruik, plan voor einde ondersteuning |
| Distributie of externe bron | backport ontbreekt of komt laat | bekende pakketbron, beveiligingsmeldingen geabonneerd |
| Hoster of platformdienst | update zonder herstart, geen informatie | plicht tot update, herstart, bewijs en melding |
| CMS-fabrikant | lek in de kern | updatekanaal, verantwoordelijke persoon |
| Aanbieder van plug-ins en thema's | opgegeven of onveilige uitbreidingen | alleen onderhouden plug-ins uit officiële bronnen |
| Bureau of ontwikkelaar | verregaande toegangen, onduidelijke verantwoordelijkheid | persoonlijke toegangen, schriftelijke opdrachten |
| Externe scripts en diensten | vreemde code in de browser, gegevenslek | lijst, vaste versies, doel gecontroleerd |
Twee voorbeelden uit de PHP2Shell-week laten zien hoe gemakkelijk een schakel wordt gemist. Vercel wijst erop dat een update van de lokale ontwikkelomgeving, de toepassingscode of de plug-ins niet volstaat; doorslaggevend is de PHP-runtime die daadwerkelijk uitlevert. Coolify adviseert de PHP-runtime van elke toepassing afzonderlijk bij te werken, ook achter Cloudflare. En volgens berichten plant WordPress.org geen eigen update tegen PHP2Shell, omdat het lek in de interpreter zit. Wie op het CMS wacht, wacht tevergeefs.
De keten zichtbaar maken: vijf stappen
Zo brengt u orde in de afhankelijkheden van uw websites:
- Keten per website opschrijven: van de PHP-runtime tot externe scripts, met de naam van de aanbieder of persoon.
- Verantwoordelijkheid per schakel vastleggen: wie installeert updates, wie controleert, wie informeert wie?
- Bewijsstukken afspreken: wat geldt als afgerond? Bij de PHP-runtime bijvoorbeeld pakketstatus en herstart, zoals beschreven onder Zo vraagt u uw hoster naar de patchstatus.
- Toegangen beperken: elk bureau en elke dienstverlener krijgt alleen de rechten die nodig zijn, met persoonlijke accounts.
- Alternatieven plannen: wat te doen als een schakel uitvalt, bijvoorbeeld als een plug-inaanbieder ermee stopt of een dienstverlener onbereikbaar is?
Vraag elke dienstverlener hoe hij u over kritieke lekken informeert. Wie alleen op verzoek antwoordt, is in een situatie als PHP2Shell een risico voor uw tijdschema. Leg het antwoord schriftelijk vast.
Plug-ins en uitbreidingen: de onoverzichtelijkste plek
Bij veel websites is het grootste deel van de toeleveringsketen onzichtbaar: plug-ins en thema's die in de loop der jaren zijn toegevoegd. Elk komt van een andere aanbieder, met eigen tempo bij beveiligingsupdates. Sommige aanbieders geven hun product op zonder dat aan te kondigen. Andere uitbreidingen worden uit onofficiële bronnen betrokken en krijgen nooit updates.
Hier helpt een eenvoudige regel: elke plug-in heeft een doel, een onderhouden aanbieder en een officiële bron nodig. Ontbreekt een van de drie, dan komt hij op de lijst om te vervangen. Iets vergelijkbaars geldt voor ingebonden diensten zoals betaalaanbieders, boekingssystemen, chatvensters of analysetools. Ze brengen eigen code naar uw pagina of ontvangen gegevens van uw bezoekers. Leg vast welke diensten zijn ingebonden, wie ze heeft besteld en of ze nog nodig zijn. Een vergeten script van een aanbieder met wie allang geen contract meer bestaat, is een schakel zonder verantwoordelijke.
Hoe u plug-ins en pakketten duurzaam actueel houdt, beschrijft Afhankelijkheden actueel houden: Composer, npm en plug-ins.
Toeleveringsketen, contracten en NIS2
Voor bedrijven die onder NIS2 vallen, hoort de beveiliging van de toeleveringsketen uitdrukkelijk bij het risicobeheer, dus ook de relaties met dienstverleners en aanbieders. Details staan onder NIS2 en webserverbeveiliging. Maar ook zonder wettelijke plicht geldt: uitbestede taken blijven uw risico. Daarom horen de resultaten van de vijf stappen in de contracten met bureau, hoster en dienstverleners; welke punten daar moeten worden geregeld, beschrijft Contracten met IT-dienstverleners: beveiligingsplichten helder regelen. Deze pagina is algemene informatie en geen juridisch advies.
Hoe helpt PHP SOS concreet?
- Wij tekenen samen met u de toeleveringsketen van elke website op, van de PHP-runtime tot externe scripts.
- Wij controleren plug-ins, thema's en pakketten op onderhoudstoestand en herkomst en adviseren waar nodig vervanging.
- Wij stemmen met hoster en bureau af wie welke schakels verantwoordt en welke bewijsstukken worden geleverd.
- Waar een schakel onbezet is, nemen wij hem duurzaam over via een beveiligingsonderhoudscontract.
Conclusie: De beveiliging van een website is zo sterk als de traagste schakel van haar toeleveringsketen. Wie de keten kent en elke schakel koppelt aan een verantwoordelijke instantie en een bewijsstuk, weet in een noodgeval waar de patch zit.
Veelgestelde vragen
Wat betekent toeleveringsketen bij een website?
Alle betrokkenen van wier werk de beveiliging van uw website afhangt: het PHP-project, de Linux-distributie, hoster of platformdienst, CMS-fabrikant, aanbieders van plug-ins en thema's, het bureau en ingebonden diensten zoals betaalaanbieders of externe scripts.
Ben ik verantwoordelijk als een dienstverlener niet patcht?
De verantwoordelijkheid voor de eigen website en de gegevens erop blijft in de regel bij u, ook als taken zijn uitbesteed. Daarom moeten verantwoordelijkheden contractueel duidelijk zijn en worden gecontroleerd. Voor de juridische beoordeling zijn een advocaat en de functionaris voor gegevensbescherming bevoegd.
Volstaat het als de hoster PHP bijwerkt?
Voor de PHP-runtime bij de hoster wel, mits hij ook alle processen herstart en dat aantoont. Draaien delen van uw toepassing elders, bijvoorbeeld in containers, op platformdiensten of op een tweede server, dan moet daar elke runtime afzonderlijk worden bijgewerkt.
Hoe herken ik risicovolle plug-ins?
Waarschuwingssignalen zijn lange tijd geen updates, een aanbieder zonder herkenbaar beveiligingscontact, aanschaf uit onofficiële bronnen en functies die niemand meer gebruikt. Zulke plug-ins moeten worden vervangen of verwijderd.