Blog

PHP en je serverstack upgraden met AI, veilig en snel

Geplaatst op vrijdag 30 oktober 2026 door Jeroen Derks

TL;DR: In oktober 2026 zijn kritieke lekken gedicht waarmee code op afstand kon worden uitgevoerd, in PHP (PHP2Shell) en in de Brotli-bibliotheek die onder meer Node.js, Python, Java en .NET gebruiken (Node2Shell). PHP 8.1 of ouder, en Node.js 20 of ouder of de oneven releaselijnen 21, 23 en 25, krijgen van het PHP- of Node.js-project geen ondersteunde release met een fix. Een gerepareerd pakket van je distributie of leverancier, ook een onderhouden backport, dicht deze lekken, maar zorgt er niet voor dat het PHP- of Node.js-project een end-of-life-versie weer ondersteunt; de blijvende stap is een upgrade naar een ondersteunde versie. Ik gebruik AI om servers en applicaties sneller te inventariseren, te analyseren en te upgraden, waarbij elke wijziging wordt gecontroleerd en eerst op een kopie wordt getest.

Veel servers draaien langer dan iemand had gepland. Een website of applicatie gaat live, werkt, en de server eronder blijft jarenlang ongemoeid. Dan stuurt een hostingprovider een waarschuwing, signaleert een beveiligingsscan een verouderde versie, of haalt een kwetsbaarheid het nieuws. Tegen die tijd is de upgrade geen stap meer maar een reeks stappen, en weet niemand meer waarom die ene cronjob of Apache-module er staat.

Een server upgraden vraagt zorg en testwerk, maar een groot deel van het werk is saai lezen en vergelijken, en daar helpt AI. Dit artikel beschrijft hoe dat werkt en wat het voor jouw server kan doen.

PHP2Shell: waarom dit nu speelt

Op 21 oktober 2026 bracht het PHP-project noodbeveiligingsupdates uit voor twee kritieke kwetsbaarheden, bekend als PHP2Shell (CVE-2026-109618 en CVE-2026-109619). Ze kunnen een aanvaller code op de server laten uitvoeren zonder in te loggen; welke aanvalspaden werken, hangt af van de PHP-handler, de configuratie en de applicatie. Volgens het PHP-project is het risico het grootst bij mod_php, waar een gedemonstreerde exploit de aanval uitvoert voordat er ook maar enige applicatiecode draait. Een volledig bijgewerkte WordPress-, Drupal- of Joomla-site is dus nog steeds kwetsbaar als de PHP-versie eronder niet is gepatcht.

Volgens Uni Bamberg gaan de lekken terug tot PHP 5.4, dat in 2012 uitkwam; controleer voor alles wat ouder is de beveiligingsmelding van je pakketleverancier, in plaats van aan te nemen dat het niet getroffen is. De gerepareerde upstream-releases van het PHP-project zijn PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Linuxdistributies en leveranciers leveren de fix in hun eigen pakketten, vaak met lagere versienummers; Ubuntu 24.04 repareerde het bijvoorbeeld in versie 8.3.6-0ubuntu0.24.04.13 van het pakket php8.3. Of een server gepatcht is, bepaalt dus de changelog van het pakket of de beveiligingsmelding voor CVE-2026-109618 en CVE-2026-109619, niet het versienummer alleen. Voor de andere versies ziet het er zo uit:

  • PHP 8.1, 8.0 en 7.4: het PHP-project brengt hiervoor geen updates meer uit. Het securityteam publiceerde wel minimale bronpatches, en sommige Linuxdistributies en commerciële supportleveranciers bieden gebackporte fixes aan. Zo'n pakket dicht deze twee lekken, maar de versie blijft zonder ondersteuning van het PHP-project, dus controleer wat je leverancier dekt en plan de upgrade.
  • PHP 7.3 en ouder, inclusief heel PHP 5.x: het PHP-project biedt hiervoor geen fix, zelfs geen bronpatch. Sommige commerciële leveranciers leveren wel gebackporte pakketten. Zo meldt CloudLinux gepatchte alt-php-pakketten voor PHP 5.2 tot en met 5.6 en 7.0 tot en met 7.4, gepatchte ea-php-pakketten voor cPanel EasyApache en TuxCare ELS-pakketten. Zulke pakketten kunnen tijd kopen terwijl een upgrade wordt gepland, maar ze zorgen er niet voor dat het PHP-project deze versies weer ondersteunt. De blijvende oplossing blijft een upgrade naar een ondersteunde versie.
  • PHP 8.2: gepatcht, maar deze versie is op 31 december 2026 end-of-life. Daarna brengt het PHP-project er geen beveiligingsfixes meer voor uit, dus dit is het moment om de volgende stap te plannen.

Het PHP-project noemt wel tijdelijke configuratiemaatregelen, maar zegt duidelijk dat die een installatie niet veilig maken. Alleen een update doet dat.

Los van deze twee lekken publiceerde het PHP-project een informatieve melding op 23 oktober 2026 over CVE-2026-115560, een derde manier om code op afstand uit te voeren die na de noodreleases overblijft. Die wordt onwaarschijnlijk geacht en treft alleen applicaties die session.serialize_handler instellen op php_binary of php_serialize en die tijdens het draaien met ini_set() omzetten naar php vóór session_start(), terwijl session upload progress aanstaat. Geldt dat voor je applicatie, dan stelt het PHP-project voor om session.upload_progress.enabled=0 in te stellen tot de volgende reguliere bugfixrelease, die met een volledige melding komt.

Niet alleen PHP: Node.js, Python en meer

Dezelfde dag bracht Node.js een beveiligingsupdate uit die tien kwetsbaarheden verhelpt, waarvan vier met de beoordeling hoog. De ernstigste, CVE-2026-111497, zit in de Brotli-decompressiebibliotheek van Google en heeft meerdere namen: Node2Shell, HTTP2Shell en Broccoli2Shell. Het decomprimeren van gegevens die een aanvaller aanlevert, kan leiden tot het op afstand uitvoeren van code. De gerepareerde versies zijn Node.js 22.23.4, 24.22.1 en 26.12.1. Node.js 20 en ouder, en de oneven releaselijnen 21, 23 en 25, zijn end-of-life en krijgen geen fix van het Node.js-project.

Het lek zit in de Brotli-bibliotheek, die Node.js meelevert, dus controleer zowel de Node.js-runtime zelf als je dependencies. Brotli is getroffen vanaf versie 1.0.3; de gerepareerde releases zijn 1.0.10, 1.1.1 en 1.2.1, één per releaselijn. Linuxdistributies backporten de fix vaak zonder het versienummer te veranderen, dus de changelog van het pakket of de beveiligingsmelding bepaalt of je getroffen bent, niet het versienummer alleen. Het lek reikt veel verder dan Node.js:

  • Python: de pakketten brotli en brotlicffi moeten worden bijgewerkt naar 1.2.1 en 1.2.1.0 of nieuwer. Let op: populaire HTTP-clients zoals requests (via urllib3), httpx, aiohttp en Scrapy gebruiken deze pakketten automatisch zodra ze geïnstalleerd zijn. Je code hoeft Brotli nergens te noemen om getroffen te zijn.
  • Java: brotli4j is gerepareerd in versie 1.24.0.
  • .NET: gerepareerd in 8.0.33, 9.0.22 en 10.0.14. .NET 7 krijgt geen fix.
  • Ruby en Go: ook deze worden als getroffen genoemd. Of je applicatie kwetsbaar is, hangt af van de Brotli-bibliotheek die ze gebruikt. Een bibliotheek met een eigen kopie van de decoder blijft kwetsbaar tot die zelf een update uitbrengt.
  • PHP op Windows: de Brotli-decoder is bereikbaar via de cURL-extensie als automatische HTTP-decompressie aanstaat. De opnieuw gebouwde Windows-pakketten 8.2.35-1, 8.3.36-1, 8.4.27-1 en 8.5.12-1, uitgebracht op 26 oktober 2026, bevatten Brotli 1.2.1. Het achtervoegsel -1 geeft een herbouw van het pakket aan en PHP meldt nog steeds dezelfde versie, dus een eerder Windows-pakket van dezelfde PHP-versie bevat de Brotli-fix niet.
  • Andere software: curl, Bun, Envoy en Istio, en ook de Brotli-pakketten van Linuxdistributies. Niet elke distributie had op het moment van schrijven al een fix klaar.

Opvallend is dat een deel van deze kwetsbaarheden is gevonden door onderzoekers die AI gebruikten. Als AI helpt fouten te vinden die jarenlang onopgemerkt bleven, verwacht ik dat beveiligingsupdates in een hoger tempo blijven komen. Een server die meerdere versies achterloopt, kan dat niet bijhouden.

Waarom upgrades meestal worden uitgesteld

Hoe complex een upgrade is, verschilt per server. Een groot deel van het werk is echter saai uitzoek- en vergelijkwerk dat moeilijk in te schatten is:

  • Eerst moet je uitzoeken wat er eigenlijk op de server staat: pakketten, PHP-extensies, Node.js- en Python-versies, aanpassingen in de configuratie, virtual hosts, geplande taken en services.
  • Je moet elke applicatie controleren op code die op de nieuwe versie niet meer werkt. Vanaf PHP 5 is dat een grote sprong: de oude mysql_*-functies zijn verwijderd in PHP 7.0, en each() en create_function() in PHP 8.0, om er een paar te noemen.
  • Oude PHP-versies draaien vaak op een oude release van het besturingssysteem, die dan ook moet worden geüpgraded, samen met de database en de webserver.
  • Releasenotes en migratiehandleidingen van elk onderdeel moeten worden gelezen en met jouw opzet worden vergeleken.
  • Daarna moet alles worden getest, het liefst zonder de live site aan te raken.

Het meeste hiervan is zorgvuldig lezen en vergelijken, en dat maakt het duur als het volledig met de hand gebeurt. Daar helpt AI.

Hoe ik AI inzet bij een upgrade

AI vervangt hier geen ervaring. Het versnelt het lezen, het vergelijken en de repetitieve wijzigingen, terwijl ik over elke beslissing blijf gaan.

1. Inventarisatie van de server

De AI helpt me scripts te schrijven die de server systematisch in kaart brengen: geïnstalleerde pakketten en versies, PHP-extensies en php.ini-instellingen, Node.js- en Python-runtimes en hun dependencies, de configuratie van de webserver, cronjobs, services en logbestanden. De AI werkt daarna met de geanonimiseerde uitvoer van die scripts, niet met de live server. Zo komen ook de vergeten onderdelen boven, zoals een meegeleverde kopie van een kwetsbare bibliotheek, die anders pas na de upgrade aan het licht zouden komen.

2. Analyse van de code

Tools voor statische analyse zoals PHPStan, Rector en PHPCompatibility vinden code die in de beoogde PHP-versie verouderd of verwijderd is. Voor Node.js en Python melden npm audit en pip-audit dependencies met bekende kwetsbaarheden, en laten npm outdated en pip list --outdated zien welke dependencies achterlopen. Deze tools dekken de dependencies van het project, niet de Node.js- of Python-runtime zelf; die wordt apart gecontroleerd. De AI loopt de resultaten door, groepeert ze, doet een voorstel welke echte problemen zijn en welke ruis, en stelt concrete oplossingen voor; ik controleer die schifting aan de hand van de beveiligingsmeldingen en de code voordat ik ernaar handel. Bij een sprong van PHP 5 of 7 naar een actuele versie is dit waar ik AI het nuttigst vind.

3. Releasenotes en dependencies

Per onderdeel vergelijkt de AI de wijzigingen tussen de huidige versie en de doelversie met je configuratie en code: gewijzigde standaardwaarden, verwijderde opties, pakketten die een nieuwere hoofdversie nodig hebben. Dat levert een lijst op met punten die specifiek voor jouw server van belang zijn, geen algemene checklist.

4. Upgradeplan

Op basis hiervan stel ik een stappenplan op: de volgorde van de upgrades, wat er na elke stap wordt getest en hoe je terugdraait als er iets misgaat. Bij een grote sprong, zoals van PHP 5.6 naar 8.4, kan dat tussenstappen betekenen. Na een upgrade van de database betekent teruggaan meestal de back-up terugzetten in plaats van de oude software opnieuw installeren, dus wordt vooraf afgesproken wat er gebeurt met gegevens die na de overstap zijn geschreven.

5. Eerst uitvoeren op een kopie

De upgrade wordt eerst uitgevoerd op een kopie van de server, bijvoorbeeld een VPS die uit een back-up is gekloond. Hoe dat gaat, hangt af van hoe de server wordt gehost. Bij een bare-metalserver zet ik voor de generale repetitie eerst een kopie terug op een VPS; hardwarespecifiek gedrag vraagt aparte controles, omdat een virtuele kopie dat niet kan nabootsen. Voordat de kopie iets uitvoert, worden de geplande taken gestopt en worden uitgaande e-mail, betaalproviders en andere live koppelingen uitgeschakeld of naar testaccounts omgeleid, zodat de kopie niets kan doen met live gegevens of klanten. Gaat er daar iets mis, dan helpt de AI de foutmeldingen en logs te analyseren, en gaat de oplossing terug in het plan. Een beschikbare beveiligingsfix zou niet op de hele migratie moeten wachten: waar een onderhouden pakket het lek dicht, kan die gerichte update eerst worden getest en uitgerold, en volgt de grotere upgrade van framework, besturingssysteem en database een eigen, gerepeteerd plan.

Voor de overstap controleer ik op de kopie:

  • De geautomatiseerde tests van de applicatie, als die er zijn
  • De belangrijkste functies: inloggen, formulieren, zoeken, en bestellingen of betalingen in testmodus
  • Dat geplande taken, wachtrijen en achtergrondprocessen zonder fouten draaien
  • Dat e-mail correct wordt aangemaakt (opgevangen, niet verstuurd)
  • Dat de versies, extensies en instellingen van PHP, webserver en database de geplande zijn
  • Dat de foutlogs schoon blijven en dat pagina's ongeveer even snel reageren als voorheen

Pas als de upgrade op de kopie werkt, voer ik hem uit op de productieserver, op een met jou afgesproken moment en met een verse back-up klaar.

6. Achteraf controleren

Na de overstap controleer ik op de productieserver, zodat problemen zo vroeg mogelijk boven komen, het liefst voordat je gebruikers of klanten ze merken:

  • Dezelfde belangrijkste functies, opnieuw gecontroleerd
  • Logs en foutpercentages, een afgesproken periode in de gaten gehouden
  • Dat wat er werkelijk draait de gepatchte versies gebruikt: PHP-FPM- en Apache-workers en Node.js-processen herstart, containers opnieuw gebouwd, en meegeleverde kopieën van bibliotheken zoals Brotli bijgewerkt. Een bijgewerkt pakket op schijf helpt niet bij een proces dat nog de oude code draait.

Wat AI wel en niet doet

Meestal krijgt de AI helemaal geen toegang tot de server of tot privégegevens. Ik gebruik hem om de scripts te schrijven die het inventarisatie- en upgradewerk doen, op basis van kopieën van configuratiebestanden, de uitvoer van de inventarisatie en fragmenten uit logbestanden, met inloggegevens verwijderd en domeinnamen en andere identificerende gegevens geanonimiseerd.

AI maakt fouten. Hij kan een oplossing voorstellen die aannemelijk lijkt maar onjuist is, of een conclusie baseren op verouderde documentatie. Daarom wordt uitvoer van AI nooit ongecontroleerd toegepast. Ik beoordeel elke voorgestelde wijziging, die eerst op een kopie wordt getest, en beslissingen over je productieomgeving blijven bij mij als persoon.

De winst zit in snelheid en grondigheid. AI kan tijd besparen op het lezen en zoeken dat bij een upgrade komt kijken, en omdat hij systematisch controleert, kan hij helpen om minder details te missen. Dat kan de kosten van een goed onderbouwde upgrade verlagen.

Wat ik kan upgraden

  • PHP, van 5.x en 7.x naar een actuele versie, inclusief extensies en configuratie
  • Node.js en npm-dependencies
  • Python en pip-dependencies
  • Het besturingssysteem (bijv. Debian of Ubuntu naar een nieuwere release)
  • Webservers: Apache en nginx
  • Databases: MySQL en MariaDB
  • Composer-dependencies en frameworks
  • Ondersteunende diensten zoals Redis en TLS-certificaten

Is je server toe aan een upgrade?

Draai je nog PHP 5, 7, 8.0, 8.1 of 8.2, of een oudere versie van Node.js of Python? Weet je niet zeker welke versies je server eigenlijk draait? Neem contact op. Ik begin met een inventarisatie en vertel je wat de upgrade inhoudt en wat ervoor nodig is, voordat er iets wordt gewijzigd.

Neem contact met me op over het upgraden van je server.

Bronnen

Bel nu 020-7775488, dan is je server snel weer up-to-date!