21 oktober 2026 | PHP | IT-beveiliging
Op 21 oktober 2026 heeft het PHP-beveiligingsteam updates uitgebracht voor alle nog ondersteunde PHP-versies. Ze dichten twee kritieke kwetsbaarheden die bekend zijn geworden als PHP2Shell. Het BSI heeft hierover een waarschuwing uitgegeven en eist dat getroffen systemen onverwijld worden gepatcht. Wie een webserver met PHP beheert, moet vandaag nog handelen. Dat geldt ook voor iedereen die “slechts” een WordPress, Nextcloud of Joomla draait, want deze applicaties draaien op PHP.
Dit artikel vat samen wat er is gebeurd, welke PHP-versies getroffen zijn, welke versie u nu nodig hebt en hoe u in enkele minuten controleert of uw server beveiligd is.
Inhoud van dit artikel
- Wat is er gebeurd? Het tijdsverloop
- De twee PHP-kwetsbaarheden in overzicht
- Wie wordt getroffen?
- Deze PHP-versies zijn veilig
- Zo controleert en actualiseert u uw server
- PHP 8.1 en ouder: geen officiële update
- Overbruggingsmaatregelen en de vraag “Server offline halen?”
- Veelgestelde vragen
- Ondersteuning door Biricon IT Services
Wat is er gebeurd? Het tijdsverloop
Het PHP-beveiligingsteam heeft de publicatie van de correcties vooraf aangekondigd, zodat hosters en beheerders tijd hadden om zich voor te bereiden. De publicatie zelf vond plaats op 21 oktober 2026. Het BSI heeft nog dezelfde dag zijn waarschuwing (versie 1.1) uitgegeven.
- 20 oktober 2026: Voorwaarschuwing van het PHP-beveiligingsteam dat de volgende dag beveiligingsupdates verschijnen.
- 21 oktober 2026, 14:00 UTC (16:00 uur CEST): De patches voor PHP 8.5, 8.4, 8.3 en 8.2 worden gepubliceerd.
- 21 oktober 2026: Het BSI waarschuwt voor de “kritieke kwetsbaarheden die webapplicaties wereldwijd bedreigen” en adviseert onverwijld te patchen. Volgens opgave van het BSI hebben grote hostingproviders deels servers preventief offline gehaald.
De twee PHP-kwetsbaarheden in overzicht
Het betreft twee afzonderlijke fouten in de PHP-kern: CVE-2026-109618 en CVE-2026-109619. Beide kunnen volgens opgave van het PHP-beveiligingsteam ertoe leiden dat een aanvaller programmacode op de server kan uitvoeren zonder zich aan te melden (unauthenticated Remote Code Execution). De kwetsbaarheden worden beoordeeld met CVSS v4.0: 9,2 (kritiek).
| Kenmerk | Betekenis |
|---|---|
| Kenmerken | CVE-2026-109618 en CVE-2026-109619 |
| Beoordeling | CVSS v4.0: 9,2 — kritiek |
| Impact | Code uitvoeren op de server (Remote Code Execution), zonder aanmelding |
| Oorzaak 1 | Beschadigd geheugen wanneer PHP tijdens de verwerking geen werkgeheugen meer krijgt (Out-of-Memory) |
| Oorzaak 2 | Verouderde globale status die tussen verzoeken in het geheugen blijft staan |
| Bijzonder kwetsbaar | Apache met mod_php |
Volgens de inschatting van het BSI waren er op het moment van publicatie geen bevestigde aanvallen, maar waren er wel onbevestigde aanwijzingen voor pogingen tot misbruik. Bij kritieke kwetsbaarheden in zo wijdverbreide software moet men er volgens de ervaring rekening mee houden dat aanvallers de correcties analyseren en geautomatiseerde aanvallen voorbereiden. Het tijdvenster om te patchen is daarom kort.
Wie wordt getroffen?
Getroffen is in principe elke server waarop PHP draait, ongeacht hoe PHP is gekoppeld: PHP-FPM, mod_php in Apache, php-cgi, FrankenPHP of LiteSpeed. Het risico is volgens het PHP-beveiligingsteam het hoogst bij Apache met mod_php.
Het BSI noemt uitdrukkelijk applicaties die op PHP zijn gebouwd en daarom ook getroffen kunnen zijn:
- Contentmanagementsystemen: WordPress, Drupal, TYPO3, Joomla
- Webshopsystemen: Magento
- Cloud- en bestandsopslag: Nextcloud
- Firewallinterfaces: pfSense, OPNsense
De applicatie zelf hoeft hiervoor niet foutief te zijn. Het lek zit in PHP, daarom helpt een update van WordPress, Nextcloud & co. alleen niet. De PHP-versie op de server moet worden bijgewerkt. Bij firewalls zoals pfSense en OPNsense komt de gecorrigeerde PHP-versie via de betreffende firmware-update van de fabrikant.
Deze PHP-versies zijn veilig
De kwetsbaarheden zijn in de volgende versies verholpen. Alles daaronder geldt als kwetsbaar.
| PHP-tak | Minimaal vereist | Opmerking |
|---|---|---|
| PHP 8.5 | 8.5.12 | actuele tak |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Ondersteuning eindigt op 31 december 2026 |
| PHP 8.1 en ouder | geen officiële update, zie onderaan | |
Zo controleert en actualiseert u uw server
1. Geïnstalleerde PHP-versie vaststellen
Op de opdrachtregel van de server toont php -v de versie van de opdrachtregel-PHP. De webserver kan een andere PHP-versie gebruiken. Controleer daarom ook de versie van PHP-FPM resp. van de Apache-module, bijvoorbeeld met php-fpm8.3 -v of via een pagina die phpinfo() weergeeft (verwijder deze daarna direct weer).
2. Update installeren via pakketbeheer
Bij Debian, Ubuntu, RHEL en verwante distributies komt de gecorrigeerde versie via het gewone pakketbeheer, bijvoorbeeld apt update && apt upgrade of dnf upgrade. Bij externe bronnen zoals de Sury-PPA of de Remi-repository verschijnen de nieuwe pakketten meestal op korte termijn.
apt changelog php8.3-fpm of rpm -q --changelog php | grep CVE-2026-1096).
3. PHP-dienst herstarten
Een pakketupdate alleen volstaat niet: draaiende PHP-processen behouden de oude code in het geheugen. Herstart PHP-FPM (systemctl restart php8.3-fpm) resp. Apache (systemctl restart apache2) en controleer daarna of de processen na de update zijn gestart.
4. Gehoste websites
Bij shared hosting actualiseert in de regel de provider. In het klantenmenu is meestal de PHP-versie per website in te stellen. Kies daar een van de hierboven genoemde veilige versies, of vraag de provider naar de stand van de patches. Volgens opgave van het BSI hebben sommige providers servers preventief van het net gehaald. Als uw site kort onbereikbaar is, kan dat de oorzaak zijn.
PHP 8.1 en ouder: geen officiële update
Voor PHP 8.1 en ouder zijn er geen officiële beveiligingsupdates meer. Beheerders van dergelijke systemen hebben twee mogelijkheden:
- Overstappen op een ondersteunde versie (aanbevolen). Hoe ouder de versie, des te groter de aanpassingsinspanning voor applicatie en extensies, daarom moet een overstap vooraf worden getest.
- Correcties terugporteren. Het PHP-beveiligingsteam heeft de correcties in ontwikkeltakken op GitHub beschikbaar gesteld. Wie PHP zelf compileert, kan deze wijzigingen in oudere versies overnemen. Dat is een overbruggingsoplossing en vereist vakkennis.
Ook PHP 8.2 wordt nog slechts tot 31 december 2026 ondersteund. Plan de overstap naar PHP 8.4 of 8.5 daarom nu in en schuif haar niet door naar de jaarwisseling.
Overbruggingsmaatregelen en de vraag “Server offline halen?”
Het PHP-beveiligingsteam heeft met de aankondiging ook voorlopige beschermingsmaatregelen beschreven. Deze verminderen het risico, maar dichten de lekken niet volledig. Ze vervangen de update niet en zijn er alleen voor bedoeld om de tijd tot de update te overbruggen.
Of een server tot de update van het net moet worden gehaald, hangt af van zijn belang en zijn bereikbaarheid. Het BSI geeft aan dat grote aanbieders deze stap hebben gezet. Als vuistregel geldt:
- Openbaar bereikbare server, update nu mogelijk: onmiddellijk patchen, uitschakelen niet nodig.
- Openbaar bereikbare server, update op korte termijn niet mogelijk: toegang beperken (bijvoorbeeld via de firewall alleen voor bekende adressen) of de dienst tijdelijk uitschakelen, vooral bij
mod_php. - Alleen intern bereikbare server: op korte termijn patchen, de urgentie is lager.
Veelgestelde vragen
Moet ik WordPress, Joomla of Nextcloud bijwerken?
Niet vanwege dit lek. Het zit in PHP, niet in de toepassing. Werk de PHP-versie op de server bij. Een update van de toepassing is los daarvan toch zinvol.
Hoe kan ik zien of iemand het lek al heeft misbruikt?
Een betrouwbare uitspraak is moeilijk. Opvallend zijn onbekende PHP-bestanden in de webmap, ongebruikelijke processen onder de gebruiker van de webserver, nieuwe gebruikersaccounts of cronjobs en ongebruikelijk uitgaand dataverkeer. Bij een concrete verdenking moet het systeem forensisch worden onderzocht en bij twijfel opnieuw worden ingericht.
Is een Web Application Firewall voldoende?
Een firewall kan bekende aanvalspatronen onderscheppen, maar is geen vervanging voor de update. Meer over het samenspel van meerdere beschermingslagen leest u in ons artikel Odoo 19 beveiligen: firewall, 2FA & Web RBL. De uitgangspunten gelden voor elke webtoepassing.
Is Odoo getroffen?
Nee. Odoo is in Python geschreven en draait niet op PHP. Alleen PHP-toepassingen die op dezelfde server draaien, zouden getroffen zijn.
Waar vind ik de officiële informatie?
De aankondiging van het PHP-beveiligingsteam vindt u in de nieuwsarchieven op php.net (bericht van 20 oktober 2026), de versies op php.net/downloads. De waarschuwing van het BSI heeft het nummer 2026-297981-1032 en is op bsi.bund.de gepubliceerd.
Ondersteuning door Biricon IT Services
Als u niet zeker weet welke PHP-versie op uw server draait, of hulp nodig hebt bij het patchen, helpen wij u graag: bij de inventarisatie van alle PHP-systemen, bij het installeren van de updates, bij de overstap naar een ondersteunde PHP-versie en bij de controle op compromittering. Als IT-dienstverlener beheren wij servers, firewalls en webtoepassingen voor kleine en middelgrote bedrijven.
Stand per 21 oktober 2026. De situatie kan op korte termijn veranderen; bepalend zijn de publicaties van het PHP-beveiligingsteam en het BSI.