Deze week lag half Nederland eruit door twee kritieke lekken in PHP. Je site kon kwetsbaar zijn terwijl al je plugins keurig up-to-date waren. Dit is wat er speelde, en hoe wij onze klanten beschermden.
In één minuut: wat er misging en wat wij deden.
Wat er aan de hand was
Op 20 oktober lekte een demo uit van een aanvalstool met de naam PHP2Shell (CVE-2026-109618 en CVE-2026-109619). De fout zat niet in WordPress, een plugin of een thema, maar in PHP zelf: de taal die onder zo’n zeven van de tien websites draait. En hij zat er al sinds 2012, veertien jaar lang, onopgemerkt.
Bronnen: Wiz Research, W3Techs, Tenable
Half Nederland trok de stekker eruit
Omdat de details uitlekten vóór er een update was, haalden veel organisaties hun sites uit voorzorg offline. Een site die offline ging, was niet gehackt. Het was een voorzorgsmaatregel.
Bronnen: NOS, ANP
Wat was nou het probleem?
Niet jouw website
Het lek zat niet in WordPress, een plugin of een thema. Jouw site was niet verkeerd gebouwd.
Maar in PHP zelf
Met één slim verzoek kon een aanvaller code op de server draaien of geheugen uitlezen. Zonder in te loggen.
Het lek werd gevonden door Calif, Wiz en OpenAI, die met AI een veertien jaar oude fout in ongeveer een week tot een werkende aanval maakten.
De oorzaak: PHP ruimde de rommel niet op
CVE-2026-109618: het geheugen loopt vol, PHP ruimt niet netjes op, en de restanten laten een aanvaller code uitvoeren.
CVE-2026-109619: oude gegevens lekken door naar een volgend verzoek, zoals wachtwoorden, tokens en sleutels uit het servergeheugen.
Bron: Wiz Research, PHP GHSA
Zo hielden wij het tegen met Imunify360
Onze servers draaien op CloudLinux met Imunify360 als firewall. Die bewaakt elke site met meerdere lagen. Nog vóór de officiële patch er was, blokkeerde een nieuwe WAF-regel het verdachte verzoek, nog voordat het PHP bereikte.
website
De WAF-regel herkent het verdachte uploadverzoek en houdt het bij de voordeur tegen.
multipart-verzoek met PHP_SESSION_UPLOAD_PROGRESS
Plus op elke server: uploadvoortgang uitgeschakeld, sessiebeveiliging aangescherpt en een vernieuwde ModSecurity-regelset. Een tijdelijke afscherming, geen vervanging van de patch.
Bron: CloudLinux Imunify360
Welke PHP-versies, en de fix
| Branch | Kwetsbaar | Gedicht in |
|---|---|---|
| PHP 8.5 | < 8.5.12 | 8.5.12 |
| PHP 8.4 | < 8.4.27 | 8.4.27 |
| PHP 8.3 | < 8.3.36 | 8.3.36 |
| PHP 8.2 | < 8.2.35 | 8.2.35 |
| PHP 7.x en 8.1 | alles, vanaf 5.4 (2012) | CloudLinux backport |
Elke release vóór deze versies was kwetsbaar. Wij draaien inmiddels op al onze servers een gedichte PHP, voor alle versies. Je hoeft zelf niets te doen.
Bron: PHP.net advisory, CloudLinux
Waarom zie ik toch een ouder PHP-versienummer?
De versienummers hierboven zijn de releases van PHP.net. Wij draaien op CloudLinux, en dat verwerkt beveiligingspatches ook in bestaande PHP-versies. Dat heet een backport: het beveiligingslek wordt gedicht, terwijl het zichtbare PHP-versienummer gelijk kan blijven. Alle servers van WP Provider zijn voorzien van beide beveiligingspatches.
Heb je SSH-toegang? Met php -v zie je de PHP-versie voor de commandline en de bouwdatum. Bijvoorbeeld:
PHP 8.3.35 (cli) (built: Oct 21 2026 00:00:00) (NTS)
Het versienummer is hier nog 8.3.35, maar de bouwdatum laat zien dat het om een opnieuw gebouwde versie gaat. De datum alleen bewijst niet dat een specifieke patch aanwezig is. Daarom controleren wij ook de volledige pakketversie en de wijzigingsgeschiedenis, waarin CVE-2026-109618 en CVE-2026-109619 expliciet vermeld staan.
Een scanner die alleen het PHP-versienummer vergelijkt met de releases op PHP.net, kan daardoor onterecht waarschuwen. Let bovendien op: de PHP-versie op de commandline kan verschillen van de versie die je website gebruikt.
CloudLinux licht deze werkwijze toe op de officiële statuspagina.
Wat de patch doet
PHP ruimt nu netjes op
Loopt het geheugen vol, dan stopt PHP meteen en schoon. Geen oude gegevens die blijven hangen.
Imunify360 blokt de route
Een ModSecurity-regelset die de bekende aanvalsverzoeken al bij de voordeur tegenhoudt.
Workers opnieuw gestart
Oude PHP-processen blijven oude code draaien. Daarom herstarten we na de update elke PHP-worker.
Beheer je WordPress-sites voor klanten?
Dit hoort voor ons bij managed hosting: ontwikkelingen volgen, handelen en bereikbaar zijn voor vragen. Zodat jij als webdesigner, developer of bureau er voor je klanten kunt zijn. Zoek je een hostingpartner die hierin meedenkt? Laten we eens kennismaken.
Maak kennis met WP Provider
