Kort gezegd: Voor het PHP 8.1-beveiligingslek PHP2Shell bestaat geen officiële update. Het PHP-project levert voor 7.4, 8.0 en 8.1 alleen minimale broncode-backports, geen kant-en-klare releases. Wie deze versies draait, heeft een bevestigde backport van zijn aanbieder of overbruggingsmaatregelen nodig en moet de overstap naar een ondersteunde versie nu plannen.
Is er tegen het PHP 8.1-beveiligingslek een update?
Niet van het PHP-project. Op 21 oktober 2026 verschenen officiële correcties alleen voor de ondersteunde takken: 8.5.12, 8.4.27, 8.3.36 en 8.2.35. PHP 8.1 en oudere versies krijgen geen officiële updates meer.
Getroffen zijn ze toch. Volgens de vakpers reiken de kwetsbare versies vrijwel doorlopend tot PHP 5.4 terug. Wie een van deze versies openbaar bereikbaar draait, heeft dus een kritieke kwetsbaarheid met CVSS v4.0 9,2 zonder kant-en-klare patch.
Voor veel bedrijven is dat een verrassing, want zulke systemen draaien vaak al jaren stabiel en onopvallend. Dat een versie geen updates meer krijgt, merkt men in het dagelijks leven niet, totdat er een kwetsbaarheid als PHP2Shell opduikt. De broncode-backports voor 7.4, 8.0 en 8.1 zijn een uitzondering en geen hervatting van het reguliere onderhoud.
Wat de broncode-backports betekenen
Voor 7.4, 8.0 en 8.1 zijn er minimale broncode-backports. Dat zijn correcties in de broncode die op deze oudere takken zijn overgedragen. Ze zijn geen officiële release met versienummer, getest pakket en changelog.
Praktisch betekent dat: iemand moet de backport overnemen, PHP daaruit opnieuw bouwen, testen en uitrollen. Dat kan op drie manieren gebeuren:
- Uw distributie neemt de correctie over in haar pakketten, bijvoorbeeld in het kader van langetermijnonderhoud.
- Uw hoster bouwt eigen PHP-pakketten en installeert de backport.
- U zelf of een dienstverlener bouwt PHP uit de bronnen. Dat is veeleisend en moet bij elke volgende kwetsbaarheid worden herhaald.
Of uw systeem een backport heeft ontvangen, controleert u aan de pakketchangelog:
apt changelog php8.1-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # Debian/Ubuntu
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # RHEL-familie
Pakketnamen verschillen per distributie en pakketbron. Ontbreekt een vermelding, vraag het dan de aanbieder. Hoe de controle in detail werkt, staat onder PHP-versie en patchstand goed controleren.
De oude server beveiligen tot de migratie
Zolang er geen bevestigde backport draait, gelden de overbruggingsmaatregelen van php.net: niet-overschrijfbaar memory_limit=-1 met geheugengrens via cgroup, post_max_size van 8M of 32M met upload_max_filesize daaronder en session.upload_progress.enabled=0 in de serverconfiguratie, daarna alle workers herstarten. Ze zijn geen volledige bescherming. Details onder Spoedmaatregelen als u nog niet kunt patchen.
Daar komen maatregelen bij die de bereikbaarheid verkleinen: beheergedeelten alleen via VPN of vrijgegeven IP-adressen, niet benodigde websites uitschakelen, toegang tot de server strak begrenzen. Het BSI adviseert servers zonder update tijdelijk van het netwerk te halen. Voor een oude, moeilijk te migreren toepassing kan een afgeschermde oplossing het eerlijker antwoord zijn dan bedrijf in het open internet.
Draaide een server met PHP 8.1 of ouder sinds 17 oktober onbeschermd op het netwerk, neem dat dan serieus: het BSI rekende op snel grootschalig misbruik. Veiligstel de logs vanaf 20 oktober en laat de server op sporen controleren voordat u migreert.
Migratie plannen: naar welke versie?
Het doel is een versie die het PHP-project ondersteunt en die uw toepassing aankan. PHP 8.2 dicht het lek vanaf 8.2.35, maar bereikt op 31 december 2026 het einde van de ondersteuning. Wie nu migreert, moet daarom bij voorkeur naar 8.3 of nieuwer gaan, voor zover de toepassing dat toestaat. De actuele stand noemt php.net op de pagina van de ondersteunde versies.
Welke PHP-versie uw CMS of shop ondersteunt, controleert u volgens de systeemeisen van de fabrikant, bijvoorbeeld op wordpress.org, shopware.com of typo3.org. Vaak moet eerst de toepassing zelf worden bijgewerkt voordat PHP kan wisselen. Een typisch geval zijn oudere shops, die we beschrijven op de pagina Shopware 5. Achtergronden bij de gevolgen van verouderde versies vindt u onder PHP end of life: risico's van verouderde versies.
| Stap | Inhoud |
|---|---|
| Bestand | PHP-versie, toepassing, extensies, eigen aanpassingen |
| Eisen | ondersteunde PHP-versies volgens de fabrikant |
| Testomgeving | kopie met nieuwe PHP-versie, foutlog analyseren |
| Omschakeling | gepland onderhoudsvenster, terugweg voorbereid |
| Nawerk | overgangswaarden controleren, bewaking inrichten |
Hoe helpt PHP SOS concreet?
Met de migratie van PHP 8.1 en ouder leiden wij u van de oude versie naar een ondersteunde:
- Direct beveiligen: backportstand controleren, overbruggingsmaatregelen instellen, bereikbaarheid verkleinen.
- Sporen controleren: logs vanaf 20 oktober veiligstellen en op opvallende zaken analyseren.
- Migratie voorbereiden: compatibiliteit volgens de fabrikant uitzoeken, testomgeving opbouwen, fouten verhelpen.
- Omschakelen en aantonen: nieuwe PHP-versie installeren, alle processen herstarten, stand documenteren.
Veelgestelde vragen
Is PHP 8.1 getroffen door PHP2Shell?
Volgens de vakpers zijn bijna alle versies tot en met PHP 5.4 getroffen, PHP 8.1 inbegrepen. Het PHP-project publiceert voor 8.1 geen officiële updates meer, alleen minimale broncode-backports.
Wat is een broncode-backport?
Een correctie in de broncode die op een oudere versietak is overgedragen. Het is geen kant-en-klare release: iemand moet haar overnemen, PHP opnieuw bouwen, testen en uitrollen. Dat kan uw distributieaanbieder, uw hoster of een dienstverlener doen.
Volstaat het om over te stappen op PHP 8.2?
Op korte termijn dicht PHP 8.2.35 het lek. PHP 8.2 bereikt echter op 31 december 2026 het einde van de ondersteuning. Wie toch migreert, moet daarom nagaan of de toepassing volgens de fabrikant ook 8.3 of nieuwer ondersteunt.
Mijn shop draait alleen met PHP 7.4. Wat nu?
Dan zijn twee dingen tegelijk nodig: de server beveiligen met overbruggingsmaatregelen en afscherming, en de toepassing op een versie brengen die een ondersteunde PHP-versie aankan. Welke dat is, staat in de systeemeisen van de fabrikant.