Kort antwoord
PHP2Shell (CVE-2026-109618 en CVE-2026-109619) zijn twee kritieke lekken in PHP zelf, niet in je eigen code: elke PHP-installatie die webverzoeken verwerkt, is kwetsbaar tot je bijwerkt naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35 (of een gepatcht pakket van je leverancier) en daarna alle PHP-processen herstart. Op PHP 8.1 en ouder brengt het PHP-project geen nieuwe release meer uit; een backport van je hoster of Linux-distributie koopt tijd, upgraden naar 8.4 of 8.5 is het plan. Ook 8.2 is gepatcht, maar krijgt na 31 december 2026 geen beveiligingsupdates meer. Je hoster patcht hooguit de PHP op zijn paneel; PHP in containers, je Composer-pakketten en de upgrade van je code zijn het werk van wie je software beheert.
Van lezen naar doen.
Business Center Altena / HVS Trading (Henk Verhoeven)Multi-tenant Huurdersportaal met IoT-energiemonitoringIoT + AIgeautomatiseerd meterstanden aflezen
Ook een kale "Hello World"-pagina is kwetsbaar voor PHP2Shell, zolang de PHP eronder niet is bijgewerkt (php2shell.com, 2026). En een update van WordPress, je plug-ins of je eigen applicatie helpt niet: "Dit is geen probleem dat je oplost door alleen WordPress of plugins bij te werken" (Eye Security via Dutch IT Channel, 2026).
De vraag is dus niet hoe goed je code is, maar welke PHP eronder draait. Wie vandaag PHP 8.2 bijwerkt, staat bovendien op 31 december opnieuw zonder beveiligingsupdates (PHP.net Supported Versions, 2026).
Deze pagina hoort bij alles over maatwerk software laten bouwen en beheren. Hier draait het om de PHP onder je bedrijfsapplicatie: wat je deze week doet, en wat vóór de jaarwisseling.
Stand: 22 oktober 2026, 00:45 uur. We werken deze pagina bij zodra het PHP-team, het NCSC of CISA iets wijzigt.
Wat is PHP2Shell (CVE-2026-109618 en CVE-2026-109619)?
PHP2Shell is de naam voor twee kritieke beveiligingslekken in de PHP-runtime, de software die je PHP-code uitvoert. Het PHP-project dichtte ze op 21 oktober 2026 in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 (PHP.net security advisory, 2026).
In gewone taal: PHP reserveert voor elk webverzoek een stuk geheugen en ruimt dat aan het eind op. Een aanvaller stuurt een verzoek dat PHP bewust over zijn geheugenlimiet duwt, bijvoorbeeld een formulier met heel veel lege bestandsvelden of diep geneste veldnamen, terwijl het binnen de toegestane verzoekgrootte blijft.
PHP breekt dan midden in een handeling af en laat het geheugen in een verwarde staat achter. Met die verwarde staat kan een aanvaller gegevens uitlezen of eigen code laten draaien (remote code execution, RCE; Cloudflare, 2026; Calif, 2026).
De twee CVE's zijn twee kanten van hetzelfde probleem. Dit is de omschrijving van het PHP-team zelf:
| CVE | Officiële titel | Wat er misgaat |
|---|---|---|
| CVE-2026-109618 | RCE via OOM corruption | Bij een geheugentekort springt PHP uit een half afgemaakte handeling; de opruimroutine behandelt half geïnitialiseerde data daarna als geldig |
| CVE-2026-109619 | RCE via stale global state | Interne status (fouten, sessie, objecten) wijst na het vrijgeven nog naar dat geheugen; een volgend verzoek op dezelfde worker gebruikt het (use-after-free) |
Sommige analyses koppelen de aanvalspaden anders aan de twee nummers. Wij volgen de officiële advisories van het PHP-team.
Geraakt zijn volgens PHP "all PHP installations serving web requests": PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed (PHP.net, 2026). Volgens Sansec is ook de standaardconfiguratie kwetsbaar (Sansec, 2026); het PHP-team bevestigde een volledige aanval op mod_php met standaardinstellingen (GHSA-w8hw, 2026).
Wat een aanvaller ermee kan: zonder in te loggen code uitvoeren met de rechten van de webgebruiker. Ook zonder die stap kan hij procesgeheugen lezen, met daarin wachtwoorden, sessietokens, API-sleutels en certificaten (php2shell.com, 2026; Wiz, 2026).
Het NCSC gaf advies NCSC-2026-0443 uit met classificatie H/H (kans hoog, schade hoog) en adviseert "de beveiligingsupdates met spoed toe te passen". Het PHP-team zelf scoort beide lekken met CVSS v4.0 9.2, kritiek (GHSA, 2026).
Tijdlijn van lek tot patch
Nederlandse tijd, met UTC tussen haakjes waar het uitmaakt (PHP Foundation, 2026):
- 20 oktober, rond 17:00 (15:00 UTC): de CVE-nummers lekken uit, met een verkeerde releasetijd en score.
- 20 oktober, 21:30 (19:30 UTC): PHP vervroegt de release van 22 naar 21 oktober.
- 21 oktober, 05:02 (03:02 UTC): Cloudflare zet WAF-regels aan voor alle klanten, ook op het gratis plan.
- 21 oktober, vóór de release: de Rijksoverheid haalt Overheid.nl, MijnOverheid.nl en DigiD uit voorzorg offline (Rijksoverheid, 2026).
- 21 oktober, rond 16:00 (14:00 UTC): de vier gepatchte releases verschijnen; om 16:01 volgt het NCSC-advies.
Je eigen code doet er hier niet toe
PHP verwerkt een multipart-formulier al tijdens het opstarten van het verzoek, voordat je applicatie één regel draait (Wiz, 2026). Een firewall of beveiligingsplug-in binnen je applicatie ziet de aanval dus niet aankomen; Sansec schrijft dat deze paden draaien vóórdat zelfs zijn eigen beveiligingsproduct aan bod komt (Sansec, 2026).
Daarmee is ook de vraag "maar onze software is toch veilig gebouwd?" beantwoord. Dat kan kloppen, en toch dicht alleen een bijgewerkte PHP-runtime dit lek.
Welke PHP draait je echt? Zo check je je PHP-versie
Vier manieren, van eenvoudig naar technisch:
| Waar | Hoe | Let op |
|---|---|---|
| Hostingpaneel | Per domein de PHP-instelling bekijken | Plesk, cPanel en DirectAdmin kunnen per domein een andere versie draaien |
| De site zelf | Tijdelijk een bestand met phpinfo() of echo PHP_VERSION; in de webroot |
Lees de versie af en verwijder het bestand direct (PHP.net) |
| WordPress | Hulpmiddelen > Sitediagnose > Info > Server | Sitediagnose markeert een verouderde PHP ook als beveiligingspunt (WordPress.org, 2026) |
| De server | php -v op de commandoregel |
Toont de command-line-PHP, en die kan een andere zijn dan wat je website gebruikt |
Kijk daarna niet alleen naar het getal. Ubuntu dicht lekken met backports en houdt het oude nummer: op Ubuntu 24.04 is 8.3.6-0ubuntu0.24.04.13 gepatcht, terwijl een zelfgebouwde 8.3.30 dat niet is (Ubuntu, 2026).
Vergelijk dus de volledige pakketversie met de tracker van je distributie. Debian levert wél de nieuwe puntrelease, zoals 8.2.35-1~deb12u1 op bookworm (Debian, 2026).
Draait je applicatie in een container, dan zit PHP in het image. Een update via het hostingpaneel of apt upgrade op de host raakt dat image niet; het moet opnieuw gebouwd worden.
Het NCSC houdt daarom in zijn operationele repository aan dat je images, appliances en ingebouwde runtimes apart inventariseert (NCSC, 2026). Dat is werk dat buiten elk paneel valt.
Wat we zagen op onze eigen hostingomgeving
Gemeten na de release van 21 oktober 2026 op onze eigen hostingomgeving, alleen-lezend, afgeronde aantallen.
Van ruim 150 domeinen en subdomeinen had ongeveer 1 op de 12 echt PHP-bestanden in de webroot, grotendeels WordPress-sites.
Ruim twee derde draait als container achter een reverse proxy. De rest is statisch, wordt doorgestuurd naar een andere dienst of draait PHP rechtstreeks, zoals die WordPress-sites.
Wat we eruit leren:
- PHP aan is niet hetzelfde als PHP in gebruik. Zet PHP uit waar een domein statisch is of naar een container doorstuurt: onnodig aan is aanvalsoppervlak zonder functie.
- Bij PHP2Shell zit de fout vóór je code. Ook een site zonder eigen PHP-logica telt mee, zolang verzoeken bij PHP aankomen. Wordt een domein volledig naar een container doorgestuurd, dan telt de PHP in die container.
- PHP in een container valt buiten een update van de server-PHP. Neem containers apart mee in de inventaris.
- Inventariseren gaat vóór patchen. Wat je niet in beeld hebt, patch je niet.
Die inventaris is daarom de eerste stap bij elke applicatie die we in beheer nemen.
Weet je niet welke PHP je applicatie draait? Neem contact op of bel 085 016 0118; we zoeken het met je uit.
Welke PHP-versie is veilig? Per tak wat PHP2Shell betekent
Volgens de statistieken van WordPress.org draait 36,4% van de WordPress-sites op PHP 8.1 of ouder, en ongeveer 60% op een tak die vanaf 1 januari 2027 geen beveiligingsupdates van php.net meer krijgt (WordPress.org, 2026). Backports van hosters en distributies zijn in die cijfers onzichtbaar.
Onze tabel per PHP-tak (stand 22 oktober 2026, samengesteld door CleverTech AI uit php.net en leveranciersdocumentatie):
| Tak | Fix van php.net | Gepatcht pakket bij leveranciers (21-10) | Beveiligingsupdates tot (end of life) | Wat dit nu betekent | Route (ons advies) |
|---|---|---|---|---|---|
| 5.x en 7.0-7.3 | Nee | Ubuntu Pro/Legacy voor sommige (14.04 php5, 16.04 php7.0, 18.04 php7.2); Plesk verwijst voor 5.6, 7.2 en 7.3 naar betaalde TuxCare ELS | Lang voorbij | Kwetsbaar; onderzoekers vonden paden tot PHP 5.4 | Afschermen of offline, dan upgraden of herbouwen |
| 7.4 | Nee, wel een bronpatch | cPanel, Plesk op Linux (nieuwe build, zelfde versienummer), volgens het DirectAdmin-forum ook DirectAdmin; Ubuntu 20.04 alleen met Pro | 28-11-2022 | Kwetsbaar tenzij je leverancier een backport bevestigt | Upgrade naar 8.4 of 8.5 als project |
| 8.0 | Nee, wel een bronpatch | cPanel, Plesk op Linux (nieuwe build), volgens het DirectAdmin-forum ook DirectAdmin | 26-11-2023 | Kwetsbaar tenzij je leverancier een backport bevestigt | Upgrade naar 8.4 of 8.5 als project |
| 8.1 | Nee, wel een bronpatch | cPanel, Plesk op Linux (nieuwe build), volgens het DirectAdmin-forum ook DirectAdmin; Ubuntu 22.04 | 31-12-2025 | Kwetsbaar tenzij je leverancier een backport bevestigt | Upgrade naar 8.4 of 8.5 als project |
| 8.2 | 8.2.35 | Ook Debian bookworm | 31-12-2026 | Gepatcht, maar de tweede deadline ligt tien weken verder | Nu patchen, vóór de jaarwisseling upgraden |
| 8.3 | 8.3.36 | Ook Ubuntu 24.04 (8.3.6-0ubuntu0.24.04.13) |
31-12-2027 | Patchen | Patchen, upgrade in 2027 inplannen |
| 8.4 | 8.4.27 | Ook Debian trixie | 31-12-2028 | Patchen | Doelversie |
| 8.5 | 8.5.12 | Ook Ubuntu 26.04 (8.5.4-0ubuntu1.5) |
31-12-2029 | Patchen; ken fatal_error_backtraces |
Doelversie |
| 8.6 | RC4 bevat de fixes | n.v.t. | Release gepland op 19-11-2026 | Nog geen productieversie | Nog niet op inzetten |
Bronnen: PHP.net Supported Versions, PHP.net end of life, PHP.net advisory, cPanel EasyApache 4, Plesk, DirectAdmin-forum, Ubuntu, Debian en de PHP 8.6-planning, alle 2026.
PHP 8.2 is de tweede deadline: op 31 december 2026 is 8.2 end of life, dus na de patch van deze week heb je nog tien weken beveiligingsupdates. Vanaf 1 januari 2027 krijgen alleen 8.3, 8.4, 8.5 en straks 8.6 nog fixes van php.net.
Je framework bepaalt de ondergrens
Je kunt PHP pas omhoog zetten als je framework of platform meegaat. Dit zijn de minimumversies van de gangbare PHP-stacks:
| Framework of platform | Vraagt minimaal | Goed om te weten |
|---|---|---|
| Laravel 13 | PHP 8.3 | Beveiligingsupdates tot 17 maart 2028 |
| Laravel 12 | PHP 8.2 | Bugfixes stopten op 13 augustus 2026; beveiliging tot 24 februari 2027 |
| Symfony 8.1 | PHP 8.4 | Nieuwste tak |
| Symfony 7.4 LTS | PHP 8.2 | De LTS-tak voor wie op 8.2 of hoger zit |
| Symfony 6.4 LTS | PHP 8.1 | Draait nog op 8.1, een tak zonder release met de fix |
| Drupal 11 | PHP 8.3 | Drupal 10 vraagt minimaal 8.1 |
| Adobe Commerce / Magento | 2.4.6: PHP 8.1 of 8.2 | 2.4.9 draait op PHP 8.5; 2.4.6 heeft extended support tot 30 augustus 2027 |
| WordPress 7.1 | Draait op PHP 7.4 tot 8.5 | Aanbevolen: 8.3 of hoger |
| WooCommerce | Volgt WordPress | Aanbevolen: 8.3 of hoger, getest tot 8.4 |
| Joomla 6 | PHP 8.3 | Aanbevolen: 8.4 |
| Shopware 6.7 | PHP 8.2 | Aanbevolen: 8.4 |
| Nextcloud (nieuwste) | PHP 8.3 | Aanbevolen: 8.5 |
Bronnen: Laravel, Symfony, Drupal, Adobe Commerce, WordPress en het WordPress Core Handbook, WooCommerce, Joomla, Shopware en Nextcloud, alle 2026.
Daarom is een PHP-upgrade bijna altijd ook een framework-upgrade. Wie op 8.1 zit, zit meestal ook op een frameworkversie die zelf geen updates meer krijgt.
Wie lost wat op: jij, je hoster of je softwarepartij?
Het NCSC publiceerde op 21 oktober een beslisboom voor organisaties met PHP (NCSC, 2026). Wij vertalen de vier takken naar situaties die je in het MKB tegenkomt.
| Situatie (NCSC) | Zo herken je het | Wat je doet | Wie je belt |
|---|---|---|---|
| 1. PHP in eigen beheer, 8.2 of nieuwer | Jij of je IT-partij beheert de server; PHP draait 8.2 tot 8.5 | Nu bijwerken en herstarten, daarna nagaan of er misbruik was | Je beheerder of hostingpartij |
| 2. PHP in eigen beheer, ouder dan 8.2 | Een eigen server of VPS met PHP 7.4, 8.0 of 8.1 | Offline halen en upgraden voordat je weer online gaat | Je softwarepartij, want dit is codewerk |
| 3. Product met PHP, code niet van jou | Een pakket of portaal van een leverancier, op jouw server | Bereikbaarheid van buitenaf beperken, mitigeren, wachten op de patch van de leverancier | De leverancier van het product |
| 4. Alles extern | SaaS of cloud; je komt niet bij de server | Vragen wat er gedaan is, en wanneer | Je leverancier |
Volgens het NCSC krijgen organisaties in tak 2 de meeste downtime, met kans op conflicten met gekoppelde software. CISA geeft hetzelfde advies: systemen die niet meteen bij te werken zijn of nog op 8.1 of ouder draaien, offline halen (CISA, 2026).
Wie patcht wat, per hostingvorm
Dit is onze indeling. Het punt: de PHP-runtime en je applicatie hebben vaak een andere eigenaar.
| Hostingvorm | PHP-runtime bijwerken | Herstarten | Containers en images | Composer-pakketten en versie-upgrade |
|---|---|---|---|---|
| Gedeelde of managed hosting | Hoster | Hoster | n.v.t. | Jij of je softwarepartij |
| Eigen VPS of server | Jij of je beheerpartij | Jij of je beheerpartij | Jij of je beheerpartij | Jij of je softwarepartij |
| Containers | Niemand automatisch: het image moet opnieuw gebouwd | Bij uitrol van het nieuwe image | Wie de build-pipeline beheert | Je softwarepartij |
| SaaS met PHP eronder | Leverancier | Leverancier | Leverancier | Leverancier |
| Maatwerk PHP-applicatie | Hoster of beheerpartij | Hoster of beheerpartij | Beheerpartij | Je softwarepartij: code, framework en taksprong |
Een hoster doet de runtime. Applicatiebeheer, dus de code, de pakketten en de sprong naar een nieuwe PHP-tak, ligt bij wie je software beheert.
De grote leveranciers waren er op 21 oktober vroeg bij. cPanel leverde in EasyApache 4 release 25.91 de vier nieuwe versies plus backports voor 7.4, 8.0 en 8.1 (cPanel, 2026).
Plesk meldt dat alle meegeleverde PHP-versies geraakt zijn, met gepatchte builds voor PHP 7.4 tot en met 8.5 op Linux en 8.2 tot en met 8.5 op Windows; voor 5.6, 7.2 en 7.3 verwijst Plesk naar betaalde TuxCare ELS (Plesk, 2026).
De bewering dat een Plesk PHP-update "meestal vier dagen later" komt, kwam van een gebruiker op het Plesk-forum die eerdere releases optelde. Dit keer kregen leveranciers de patches vooraf, en volgens Plesk zelf stonden de builds op 21 oktober klaar.
Op een VPS ben je vaak zelf aan zet. GoDaddy patchte zijn Managed WordPress volledig, maar meldt dat VPS-klanten zelf moeten bijwerken (GoDaddy, 2026).
PHP2Shell staat op elke prioriteitenladder bovenaan: kritiek, vanaf internet bereikbaar en met aanvalsverkeer. Hoe je zo'n ladder voor al je systemen opzet, en wanneer patch management uitbesteden loont, werkt een aparte pagina uit.
Kun je vandaag niet updaten? Tijdelijke maatregelen en hun prijs
Deze maatregelen kopen uren of dagen, geen veiligheid. Elke maatregel heeft een nadeel dat je vooraf wilt kennen.
| Maatregel | Wat het doet | Nadeel |
|---|---|---|
session.upload_progress.enabled=0 in php.ini of de FPM-pool, daarna alle workers herstarten |
Blokkeert de bevestigde sessiepaden van CVE-2026-109619 | Niet tegen andere varianten; uploadvoortgangsbalken werken niet meer; via ini_set() of .user.ini is het te laat |
fatal_error_backtraces=0 en herstarten |
Sluit het bevestigde backtrace-pad | Alleen relevant op PHP 8.5 |
memory_limit=-1 afdwingen met php_admin_value, plus een limiet via cgroup v2 memory.max |
De geheugenlimietfout van PHP valt weg | Alleen mét een harde geheugenlimiet per pool of container (cgroup v2 memory.max). Zonder die limiet kan één verzoek al het geheugen van de server opmaken, en stopt het besturingssysteem willekeurige processen, ook je database en andere sites. Niet doen op een gedeelde server; vraag het je hoster. Een onderliggende allocatiefout kan het lek nog raken. Gebruik geen RLIMIT_AS of RLIMIT_DATA: volgens het PHP-team kunnen die juist de kwetsbare allocatiefout veroorzaken |
post_max_size omlaag (8M zonder uploads, 32M met) en upload_max_filesize daaronder; proxylimieten op parts, headers en nesting |
Maakt de bekende triggers lastiger | Ook verzoeken zonder Content-Length moeten begrensd; grote uploads werken niet meer |
| multipart/form-data blokkeren in nginx of Apache | Haalt de bekende trigger weg | Uploads en mogelijk afrekenformulieren werken niet meer |
| Alleen-lezen (alleen GET en HEAD) of offline | Haalt de bekende triggers weg; alleen offline sluit alles af | Je site toont alleen nog, of is weg |
Bronnen: PHP.net, GHSA-w8hw, GHSA-6wmf, php2shell.com en voor multipart blokkeren en alleen-lezen Sansec, alle 2026.
Test elke wijziging aan nginx of Apache eerst (nginx -t of apachectl configtest) en herlaad liever dan dat je herstart. Op een server met meerdere sites raakt een fout ze allemaal tegelijk; werkt je hoster met een paneel, zet de regel dan per domein via dat paneel.
Het PHP-team zegt het zelf: "There are no complete mitigations, updating is the only safe choice" (PHP.net, 2026). Zie elke maatregel als een brug naar de update, niet als vervanging ervan.
Na de PHP-update: vijf controles
Een update die niet geladen is, beschermt niets. Loop daarom na het bijwerken deze vijf punten langs.
| Controle | Waarom | Hoe |
|---|---|---|
| 1. Draait de site echt de nieuwe versie? | Het paneel kan een andere tak tonen dan de site gebruikt | Per domein controleren, zoals Eye Security adviseert: "Controleer na de update ook dat de website daadwerkelijk de bijgewerkte versie gebruikt" |
| 2. Zijn Apache, PHP-FPM en alle langlopende workers herstart? | Een draaiend proces houdt de oude PHP in het geheugen | Herstart expliciet, ook queue-workers en daemons (php2shell.com, 2026) |
| 3. Zijn containers en andere PHP-runtimes herbouwd? | Een paneel-update raakt images niet | Images opnieuw bouwen en uitrollen |
| 4. Stond de server open en bevat hij geheimen? | Het lek kan geheugen met wachtwoorden en sleutels vrijgeven | Wachtwoorden, API-sleutels en sessiesleutels vervangen; Patchstack: behandel de server als mogelijk gecompromitteerd (Patchstack, 2026) |
| 5. Ken je het nieuwe gedrag bij geheugentekort? | Na de fix stopt het proces bij de harde limiet en draaien shutdown-handlers niet meer | Test afhandelingen die op shutdown-handlers leunen (php2shell.com, 2026) |
Waar bronnen elkaar tegenspreken (stand 22 oktober 2026)
In de eerste twee dagen spraken bronnen elkaar op zes punten tegen. Dit is onze samenvatting, met wat wij eruit concluderen.
| Punt | Wie zegt wat | Wat wij concluderen |
|---|---|---|
| Ernstscore | PHP-team: CVSS v4.0 9.2; NVD: 9.8 (CVSS v3.1); Red Hat: 8.1, "Important"; de 10.0 uit het lek was volgens de PHP Foundation fout | 9.2 is de score van de maker; NVD rekent met de oudere v3.1-methode hoger |
| Actief misbruik | Misbruik gezien: watchTowr, "Exploitation has been observed in the wild" (via honeypots). Aanvalsverkeer: Cloudflare en Patchstack (later "only probing attacks, with no hard evidence of breaches yet"). Niet gezien: CISA "has not observed exploitation ... as of the time of publication"; Talos "has not seen them being exploited in the wild yet" (21-10, 14:00 UTC); geen vermelding in de KEV-catalogus van CISA | Aanvalsverkeer: ja. Bevestigde inbraken: op 22 oktober nog niet publiek gemeld. Handel alsof het wel zo is |
| Hoe ver terug | Onderzoekers vonden paden tot PHP 5.4 (php2shell.com, Sansec); Red Hat: RHEL 7 en ouder leveren PHP-versies die niet geraakt zijn; PHP.net: 8.1 en ouder krijgen geen updates meer van het PHP-project | Behandel alles onder 8.2 als kwetsbaar, tenzij je leverancier een backport bevestigt |
| "Geen fix voor 8.1" | Talos: "There is no patch for PHP 8.1 or older"; tegelijk bronbackports van php.net en gepatchte pakketten van cPanel, Plesk en Ubuntu | Geen nieuwe release, wel backports: die kopen tijd, het plan blijft upgraden |
| Publieke exploit | Een demovideo lekte (PHP Foundation); Sansec: "The writeups and an exploit tool are public" | Of er een kant-en-klare exploit rondgaat, verschilt per bron; reken erop |
| Welk pad bij welke CVE | Sansec koppelt de paden anders dan de officiële advisories | Wij volgen de GHSA's van het PHP-team |
Draai je PHP 8.1 of ouder: tijd kopen of upgraden?
Volgens een eerste schatting van Talos krijgt ongeveer de helft van de PHP-systemen geen patch (Talos, 2026). Voor die systemen zijn er drie routes.
| Optie | Wat het je koopt | Waar het ophoudt |
|---|---|---|
| Backport van je leverancier (cPanel, Plesk, Ubuntu Pro; voor 5.6, 7.2 en 7.3 verwijst Plesk naar TuxCare) | Deze twee lekken dicht, zonder codewijziging | Elk volgend lek vraagt een nieuwe backport; framework en pakketten blijven oud |
| Betaalde extended support, zoals bij one.com voor 8.0 en 8.1 (tunity.be, 2026) | Uitstel tegen een maandbedrag | Hetzelfde, plus een terugkerende rekening |
| Upgrade naar PHP 8.4 of 8.5 | Beveiligingsupdates tot eind 2028 of eind 2029 | Kost een project: code, framework en tests |
Een backport is een pleister met een houdbaarheidsdatum, geen route. Het NCSC verwacht dat aanvallers deze lekken lang blijven misbruiken, zoals eerder bij log4shell (NCSC, 2026).
Ons advies voor de doelversie: PHP 8.4 of 8.5. Met 8.3 koop je tijd tot eind 2027, en dan sta je opnieuw voor dezelfde vraag.
Wat er breekt van PHP 7.4 naar 8.x
| Versie | Wat verandert | Wat je merkt |
|---|---|---|
| 8.0 | 0 == "foo" is nu false; each() en create_function() zijn weg; veel waarschuwingen worden TypeError of Error |
Stille logicawijzigingen en harde fouten op plekken die jaren werkten |
| 8.1 | null doorgeven aan niet-nullable parameters van ingebouwde functies is deprecated |
Een stroom deprecation-meldingen in je logs |
| 8.2 | Dynamische properties zijn deprecated (tenzij #[\AllowDynamicProperties]), net als utf8_encode() en utf8_decode() |
Oudere modellen en bibliotheken die zomaar properties toevoegen |
| 8.4 | Impliciet nullable parameters zijn deprecated | Veel kleine aanpassingen in functiehandtekeningen |
Bron: de migratiegidsen van de PHP-handleiding voor 8.0, 8.1, 8.2 en 8.4.
Zo upgrade je je PHP-versie: de volgorde die werkt
| Stap | Gereedschap | Wat het oplevert |
|---|---|---|
| 1. Tests eerst | Je testsuite, aangevuld waar hij gaten heeft | Na de upgrade weet je wat er stuk is |
| 2. Blokkades vinden | composer why-not php 8.4 en composer audit (Composer) |
Welke pakketten de sprong tegenhouden, en welke bekende lekken hebben |
| 3. Statisch controleren | PHPCompatibility met testVersion 8.4, PHPStan met phpVersion |
Wat breekt, voordat het draait |
| 4. Automatisch herschrijven | Rector met withPhpSets(), eerst --dry-run; bij oude code withPhpLevel(), één stap per run |
Het voorspelbare deel van de diff |
| 5. Framework mee omhoog | De ondergrens uit de tabel hierboven | Een stack die weer updates krijgt |
| 6. Staging, dan overstap | Een kopie van productie en een terugvalpad | Een overstap zonder verrassingen in productie |
Wil je bij de upgrade ook containeriseren of naar een nieuwe omgeving verhuizen, plan dat dan als aparte stap. Eerst de nieuwe PHP, dan de nieuwe omgeving: zo weet je bij een fout welke van de twee hem veroorzaakte.
Waar AI helpt bij een PHP-upgrade, en waar niet
Rector doet het voorspelbare deel: regels die code altijd op dezelfde manier herschrijven. Een AI-codeeragent schrijft de rest van de mechanische wijzigingen en de tests die ontbreken.
Een mens beoordeelt elke wijziging, en de testsuite is het vangnet. Ook Anthropic beschrijft modernisering met Claude Code als stapsgewijs refactoren "while keeping humans in the loop" (Anthropic, 2026).
Hoeveel tijd dat bij PHP scheelt, is nog niet openbaar gemeten. Het beste openbare cijfer komt van Google: bij 39 migraties kwam ongeveer driekwart van de codewijzigingen van een taalmodel, en de ontwikkelaars schatten zelf 50% tijdwinst (Ziftci en anderen, arXiv, 2025).
Dat zijn algemene migraties binnen Google en zelfgerapporteerde schattingen, geen PHP-upgrades. Daarom noemen we geen percentage voor jouw upgrade, maar begroten we die na een code-audit.
Soms is herbouwen de enige route. In een multi-tenant zorgplatform waren besturingssysteem, PHP-versie en database alle drie end-of-life, zonder upgradepad dat niet feitelijk op herbouw neerkwam.
Of je dan moderniseert of vervangt, is een andere afweging. Die staat uitgewerkt bij legacy software vervangen.
Wat kost patchen, upgraden of laten beheren?
Onze prijzen zijn exclusief btw; bij marktreferenties vermeldt de bron de btw niet. Stand 22 oktober 2026; elke rij zegt of het onze prijs is of een marktreferentie.
| Route | Kosten | Herkomst |
|---|---|---|
| Patch binnen je tak op managed hosting | Meestal binnen je hostingabonnement | Algemeen; verschilt per hoster |
| Extended support voor een oude tak (noodoplossing) | €6,99 per maand bij one.com | Marktreferentie, tunity.be (2026) |
| PHP 7 naar 8, middelgrote applicatie | Vanaf €4.500, 2 tot 6 weken | Marktreferentie, php.nl (2026) |
| PHP-upgrade bij CleverTech AI | Begroten we na een code-audit | Eigen |
| Legacy moderniseren in plaats van vervangen | Vanaf €15.000 | Eigen prijs |
| Re-platforming per applicatie | €5.000-€15.000 | Eigen prijs |
| Containerisatie per applicatie | €8.000-€25.000 | Eigen prijs |
| Nieuwe bedrijfsapplicatie | €25.000-€75.000 | Eigen prijs |
| Beheer van een draaiende PHP-applicatie | €500-€750 per maand, na een code-audit, maandelijks opzegbaar | Eigen prijs |
In de beheerband zitten monitoring, beveiligingspatches, bugfixes en 8 uur support. Het hogere bedrag hoort bij applicaties met meerdere koppelingen en een responstijd die we vooraf vastleggen.
Hosting en servers rekenen we apart, en kosten van derden rekenen we één-op-één door. Hoe de rest van de rekening na de bouw eruitziet, lees je in wat maatwerk software na de oplevering kost; al onze tarieven staan op de tarievenpagina.
Wat wachten kost, is niet in euro's te zeggen: betrouwbare Nederlandse cijfers bestaan daarvoor niet. Het NCSC verwacht wel dat organisaties op oude versies de meeste downtime krijgen, met neveneffecten op gekoppelde applicaties (NCSC, 2026).
Hoe dat eruitziet, liet de Rijksoverheid zien met DigiD, MijnOverheid en Overheid.nl uit voorzorg offline. Voor een webshop of klantportaal betekent zo'n dag zonder site een dag zonder bestellingen of service.
Zo overvalt het volgende PHP-lek je niet: beheer dat elke dag doorloopt
De les van PHP2Shell is niet "sneller patchen", maar weten waar PHP draait en iemand hebben die het elke dag bijhoudt. Zo ziet dat werk eruit als je software bij ons in beheer is.
Inventaris eerst: waar PHP draait, welke takken, welke containers, en op welke domeinen PHP aan staat zonder dat het nodig is. Dat is het eerste wat we in beheer opbouwen.
Elke dag dependency-updates: we zetten elke dag de updates van je Composer- en npm-pakketten klaar, getoetst tegen de beveiligingsadviezen (composer audit). Ze gaan pas naar productie als de volledige testsuite groen is; major-versies beoordeelt een mens.
Taalversie-upgrades op tijd gepland: de sprong naar een nieuwe PHP-tak plannen we ruim vóór de einddatum, met Rector, AI en tests zoals hierboven; wat die sprong kost, spreken we vooraf af. Zo wordt 31 december geen noodgeval.
Beveiligde servers: cybersecurity voor je applicatie begint bij de server, dus na de inventaris zetten we PHP uit waar het niet nodig is en leggen we vast dat images bij elke PHP-release opnieuw gebouwd en uitgerold worden. Daarbij krijgt de webgebruiker zo weinig mogelijk schrijfrechten, werkt SSH alleen met sleutels en zonder root-login, en staat er een firewall voor alles wat niet open hoeft.
Elke dag een back-up: met één voorwaarde die PHP2Shell scherp maakt. Een aanvaller draait als de webgebruiker, dus een back-up op dezelfde server of op een schijf waar die gebruiker kan schrijven, is geen back-up.
Een back-up helpt pas als minstens één kopie buiten de server staat, niet beschrijfbaar is voor de webgebruiker en het terugzetten getest is. CISA adviseert offline, versleutelde back-ups die je regelmatig test (CISA #StopRansomware Guide, 2023); hoe je dat voor je hele bedrijf regelt, staat in het disaster recovery plan.
Voor dit beheer betaal je €500-€750 per maand per applicatie, na een code-audit en maandelijks opzegbaar. Hosting staat daar los van.
Bouwde een andere partij je software, dan begint het bij de overdracht. Hoe maatwerk software laten onderhouden werkt als de bouwer niet de beheerder wordt, staat op een eigen pagina.
Alles hierboven valt onder onderhoud en beheer van je maatwerksoftware. Het is hetzelfde werk, of je software nu op Laravel, Symfony of een eigen PHP-basis draait.
Stuur ons je repository of geef ons leestoegang tot de server: we zeggen welke PHP-tak je draait, wat de route is en wat beheer daarna kost. Neem contact op, bel 085 016 0118 of plan een gesprek.
Wat is er veranderd sinds 21 oktober?
- 22 oktober 2026, 00:45: geen van beide CVE's in de KEV-catalogus van CISA; NCSC-2026-0443 staat op versie 1.00, H/H.
- 21 oktober 2026: PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uitgebracht; advisories van het PHP-team, het NCSC, CISA en NCSC UK.
Opgesteld met AI-ondersteuning, geredigeerd en inhoudelijk verantwoord door het Redactieteam CleverTech AI.
