Een website is software. De helft van het PHP-web krijgt geen beveiligingsupdates meer.
De site laadt nog, dus niemand controleert hem, terwijl de onderdelen waarmee hij is gebouwd hun ondersteuning verliezen, datum voor datum. Ongeveer de helft van de PHP-websites draait al op een versie die de ontwikkelaars niet meer patchen.
KORT ANTWOORD
Ongeveer de helft van alle websites die op PHP draaien, gebruikt een versie die de ontwikkelaars niet meer onderhouden, en dat aandeel stijgt op 31 december 2026 naar ongeveer twee op de drie. De meeste kwetsbaarheden zitten in plugins, niet in de kern. Controleer deze week uw PHP-versie en pluginlijst. Als niemand elke maand met die controle is belast, heeft uw site geen beheerder.
De website van een ingenieursbureau met veertig medewerkers ging in 2019 live. Een freelancer bouwde hem in WordPress, met een thema uit een marktplaats en zevenentwintig plugins, en nam daarna elders een fulltime baan aan. De site laadt nog steeds. Het contactformulier verstuurt nog steeds. De financieel directeur, die de site erfde, is al twee jaar niet meer ingelogd in het hostingpaneel, omdat er niets mis leek.
Dat er niets mis lijkt, is precies het probleem. Een website is geen brochure die eenmalig is gedrukt. Het is software, opgebouwd uit onderdelen waarvan de makers blijven werken aan fixes, of daarmee stoppen. Als de fixes stoppen, blijft de site werken. Hij wordt alleen niet meer beschermd.
De helft van het PHP-web draait op een versie zonder beveiligingsupdates
PHP draait WordPress en de meeste websites van kleine bedrijven. W3Techs vindt het op 69,9% van de websites waarvan W3Techs de servertaal kan vaststellen.
Het PHP-project publiceert precies wanneer elke versie geen beveiligingsupdates meer krijgt. Volgens php.net bereikte versie 7.4 het einde van de ondersteuning op 28 november 2022, 8.0 op 26 november 2023 en 8.1 op 31 december 2025. Na die datums wordt een nieuw gevonden kwetsbaarheid in die versie nooit meer verholpen.
Niemand publiceert hoeveel websites nog op die versies draaien, dus heeft Elevates het zelf berekend. Neem de versieaandelen van W3Techs van 19 september 2026: 28,0% van de PHP-sites draait op versie 7, 7,8% op versie 5 en 0,1% op versie 4. Van de 64,1% op versie 8 plaatst de uitsplitsing van W3Techs 16,1% op 8.1 en 6,2% op 8.0. Tel dat op en ongeveer 50,2% van de PHP-websites draait op een versie die geen beveiligingsupdates meer krijgt.
Figuur 1PHP-ondersteuning
De helft van het PHP-web draait op code die niemand meer patcht.
Aandeel van de websites op PHP waarvan de versie geen beveiligingsupdates meer krijgt, 19 september 2026.
Dat is geen randgroep van vergeten hobbysites. Het is de helft van de gangbaarste manier waarop kleine bedrijven online komen.
Op 31 december 2026 wordt de helft twee op de drie
De ondersteuningskalender staat niet stil. php.net vermeldt dat de beveiligingsondersteuning voor PHP 8.2 eindigt op 31 december 2026. W3Techs plaatst 28,9% van de PHP 8-sites nu op 8.2.
Als niemand overstapt, stijgt het aandeel PHP-websites op een niet-ondersteunde versie op nieuwjaarsdag van ongeveer 50% naar ongeveer 68,7%. Opnieuw de berekening van Elevates, met dezelfde bronnen en dezelfde datum.
Figuur 2De kalender
Elke deadline was jaren van tevoren gepubliceerd.
Wanneer elke PHP-versie geen beveiligingsupdates meer kreeg, en wat dat doet met het aandeel blootgestelde sites.
Elk van die datums is jaren van tevoren gepubliceerd. Geen enkele was een verrassing voor wie keek. De sites die erlangs gingen, hadden gewoon niemand die keek.
Het zwakke punt is niet WordPress. Het is wat erop wordt vastgeschroefd
WordPress draait 40,2% van alle websites en krijgt veel de schuld. Die schuld komt op de verkeerde plek terecht.
Patchstack, een bedrijf dat WordPress-beveiliging verkoopt, publiceert jaarlijks een telling van nieuwe kwetsbaarheden in het ecosysteem. Het rapport van 2026 telde 11.334 nieuwe kwetsbaarheden in 2025, 42% meer dan in 2024. Daarvan zat 91% in plugins en 9% in thema's. De WordPress-kern had er zes, allemaal met lage prioriteit.
De kern is dus het best beschermde deel van de site. De plugins zijn waar het risico zit, en elke plugin is een aparte leverancier. Een contactformulier van de ene ontwikkelaar, een slider van de tweede, een cookiebanner van de derde, een back-uptool van de vierde. Elk heeft een eigen releaseschema, eigen prioriteiten en een eigen kans om door de maker te worden verlaten.
Zevenentwintig plugins zijn zevenentwintig leveranciers. De meeste bedrijven kunnen er niet één noemen.
Bijna de helft van de lekken is openbaar voordat er een fix bestaat
De geruststellende veronderstelling is dat updaten genoeg is: zet automatische updates aan en het probleem lost zichzelf op. De cijfers zeggen iets anders.
In hetzelfde rapport stelde Patchstack vast dat 46% van de kwetsbaarheden bij openbaarmaking nog geen fix van de ontwikkelaar had gekregen, tegen 33% een jaar eerder. Zijn eigen conclusie: website-eigenaren "kunnen niet op pluginupdates vertrouwen als beveiligingsmaatregel."
Updaten dicht de gaten waarvoor een fix bestaat. Het helpt niet bij een plugin waarvan de maker niets meer van zich laat horen, en niet in de dagen tussen het openbaar worden van een kwetsbaarheid en het verschijnen van een patch. Voor die gevallen moet iemand beslissen: de plugin uitschakelen, vervangen, of het risico bewust aanvaarden. Een automatische update kan die beslissing niet nemen. Daar is een mens voor nodig.
Aanvallers handelen in uren. De meeste eigenaren in kwartalen
Het venster tussen openbaarmaking en aanval is kort. Patchstack stelde vast dat ruwweg de helft van de kwetsbaarheden met grote impact binnen 24 uur werd misbruikt. Gewogen naar de intensiteit van het misbruik was de mediane tijd tot het eerste misbruik vijf uur.
Figuur 3Tijd tot aanval
Zet dat nu af tegen hoe de meeste bedrijven met hun website omgaan. De site wordt bekeken als iemand klaagt, of als er een redesign op tafel ligt, om de paar jaar. Een venster van vijf uur en een beoordelingscyclus van drie jaar komen elkaar niet tegen.
Ook de hostingpartij is geen vangnet. Patchstack testte gangbare verdedigingen, waaronder web application firewalls en Cloudflare, tegen echte exploits van WordPress-kwetsbaarheden, en meldt dat ze 12% van de WordPress-specifieke aanvallen tegenhielden. Beschouw dat als de eigen test van een leverancier, want Patchstack verkoopt het alternatief. Ook met een flinke korrel zout zegt het hetzelfde: de firewall van de hostingpartij is geen onderhoud.
"Het werkt nog" is niet hetzelfde als "het wordt nog onderhouden"
Dit is de zin die verouderde sites online houdt. De homepage laadt, dus de site zal wel in orde zijn.
Een niet-gepatchte site ziet er precies zo uit als een gepatchte, tot op de dag dat dat niet meer zo is. Wat eerst verandert, is onzichtbaar: een spampagina in een map waar niemand komt, een doorverwijzing die alleen werkt voor bezoekers die via Google binnenkomen, een script dat aan de afrekenpagina is toegevoegd. Zoekmachines en browsers merken het misschien eerder op dan de eigenaar, en ze reageren door bezoekers te waarschuwen en weg te sturen.
Een inbraak brengt drie kosten met zich mee, en het herstel is de kleinste. De eerste is de tijd waarin de site andermans doelen diende voordat iemand het merkte. De tweede is vertrouwen: een klant die een browserwaarschuwing bij uw domein ziet, leest de uitleg niet. De derde is juridisch. Bevat de site persoonsgegevens, dan kan een datalek meldplichten onder artikel 33 van de AVG in werking stellen, met een termijn van uiterlijk 72 uur nadat u er kennis van hebt genomen.
Geen van die kosten staat op de factuur van de website. Ze worden allemaal betaald door het bedrijf dat de site bezit.
Wat u vanmiddag kunt controleren zonder iemand te betalen
Het grootste deel van de eerste ronde is gratis, en u kunt het zelf doen.
- Zoek uw PHP-versie op. Uw hostingpaneel toont hem, meestal onder een kopje als PHP-instellingen of software. Begint hij met 7, of is het 8.0 of 8.1, dan krijgt hij geen beveiligingsupdates meer. Is het 8.2, dan stopt dat op 31 december 2026.
- Tel uw plugins. Open in het WordPress-beheer de pluginpagina. Noteer hoeveel er geïnstalleerd zijn en hoeveel er actief zijn.
- Verwijder wat inactief is. Een inactieve plugin staat nog op de server en de code ervan is nog bereikbaar. Als niemand kan zeggen waarom hij er staat, verwijder hem dan.
- Controleer de laatste update van elke actieve plugin. De pluginbibliotheek op WordPress.org toont wanneer elke plugin voor het laatst is bijgewerkt. Een plugin die een jaar of langer niet is aangeraakt, is een plugin om te vervangen.
- Zet automatische updates aan voor kleine releases, en controleer of back-ups echt draaien en kunnen worden teruggezet. Een back-up die niemand ooit heeft teruggezet, is hoop, geen back-up.
- Noteer wie beheerderstoegang heeft. Verwijder de accounts van mensen die zijn vertrokken.
Voor veel kleine sites is dat één middag, en het sluit een groot deel van het gemakkelijke risico. Doe het ook als u nooit met een bureau praat.
Waar de middag ophoudt
De gratis ronde heeft een plafond, en dat is snel bereikt.
Van PHP 7.4 naar 8.3 gaan is geen schakelaar in het hostingpaneel. Code die voor de oude versie is geschreven, kan op de nieuwe stukgaan: een thema dat functies gebruikt die de nieuwe versie heeft verwijderd, een plugin die er nooit voor is bijgewerkt. Op een oude site levert het omzetten van de schakelaar vaak een wit scherm op. Dus wordt de upgrade uitgesteld en blijft de site op de versie die geen fixes meer krijgt. Zo is de helft van het PHP-web gekomen waar het nu staat.
Hetzelfde geldt voor een verlaten plugin die iets doet waar het bedrijf op steunt, zoals het boekingsformulier of het ledengedeelte. Vervangen betekent die functie opnieuw bouwen, testen en de gegevens verhuizen. Dat is technisch werk, en geen checklist dekt dat.
En de checklist moet volgende maand opnieuw worden doorlopen, en de maand daarna. De middag lost het probleem van vandaag op. Hij maakt niemand verantwoordelijk voor morgen.
Hoe een onderhouden website er maand na maand uitziet
Onderhoud klinkt vaag, en juist daarom wordt het overgeslagen. Het is niet vaag. Het is een korte routine met een agenda, en ze past op één pagina.
Elke maand: voer updates uit voor de kern, het thema en elke plugin, bij een grote update eerst op een kopie van de site. Lees de beveiligingsmeldingen voor de plugins die echt geïnstalleerd zijn, niet voor het hele ecosysteem. Controleer of de back-up van afgelopen nacht bestaat en compleet is.
Elk kwartaal: zet een back-up terug op een testkopie en bevestig dat de site daarmee werkt. Beoordeel wie beheerderstoegang heeft. Bekijk opnieuw elke plugin die in zes maanden niet is bijgewerkt en beslis of hij blijft.
Elk jaar: controleer de PHP-ondersteuningskalender en plan de volgende versiestap vóór de deadline, niet erna. Verleng het domein en de certificaten met een benoemd persoon die meekijkt, niet met een kaart die mogelijk is verlopen. Vraag of elke plugin nog zijn plek verdient, want de goedkoopste plugin om te beveiligen is de plugin die niet geïnstalleerd is.
Bij elke beveiligingsmelding zonder fix: beslis binnen een dag of u uitschakelt, vervangt of accepteert. Leg de beslissing met een datum vast.
Niets hiervan is exotisch. Het is dezelfde discipline die elk bedrijf al toepast op zijn boekhouding of zijn wagenpark: een schema, een benoemd persoon en een registratie. Wat op de meeste sites ontbreekt, is niet de kennis. Het is de naam naast de taak.
Software heeft een eigenaar nodig, geen lanceerdatum
De echte kloof is niet technisch. Het is dat niemand eigenaar is van de werking van de site.
Websites worden meestal verkocht als project: een ontwerp, een bouw, een lancering, een factuur. De werking wordt behandeld als bijzaak, of als een hostingtarief. Maar de lancering is de dag waarop de software begint te verouderen. Elke maand daarna levert ergens een leverancier een fix of stopt daarmee, en iemand moet dat opmerken.
Zo prijst Elevates een site: de bouw eenmalig en de werking maandelijks, met een benoemd persoon die verantwoordelijk is voor updates, back-ups en toegang. De bouw wordt nooit heropend om onderhoud te betalen, en onderhoud wordt nooit verstopt in de bouw. De eigen site van Elevates, elevates.it, is helemaal zonder pluginlaag gebouwd: de pagina's worden gecompileerd uit code die Elevates zelf beheert, zodat er om te beginnen minder leveranciers in de gaten te houden zijn.
Voor een site als die van het ingenieursbureau komt de eerlijke beoordeling meestal op een van twee plekken uit. Soms is het een middag opruimen, een PHP-upgrade die doorgaat en een maandelijkse routine die het bureau zelf kan uitvoeren of aan iemand kan overdragen. Dat kost niets dan aandacht, en het is de uitkomst om op te hopen. Soms overleven het thema en de helft van de plugins de upgrade niet, en is de keuze tussen opnieuw bouwen met minder bewegende delen of elke maand betalen om een oude stack op geleende tijd in leven te houden. In beide gevallen hoort het een bewuste beslissing te zijn, met de datums voor ogen.
De vraag voor deze week
Stel degene die uw website beheert één vraag: op welke PHP-versie draait de site, en wanneer krijgt die geen beveiligingsupdates meer?
Komt het antwoord snel, met een datum en een plan, dan heeft uw site een beheerder. Wordt de vraag doorgeschoven, of luidt het antwoord "het is prima, het werkt", dan heeft hij een lanceerdatum en sindsdien niets meer. Elevates kan de controle samen met u uitvoeren en vertellen in welke van de twee uitkomsten u zit.