Kort gezegd: Wie nog PHP 8.1 of ouder draait, krijgt van het PHP-project geen officiële beveiligingsupdates meer, ook niet voor PHP2Shell. Een PHP 8.1-upgrade naar een ondersteunde versie is daarom geen kwestie van luxe, maar de eigenlijke oplossing. Wij controleren uw toepassingen, testen in een kopie, migreren gecontroleerd en beveiligen de tijd tot dan.
Waarom PHP 8.1 en ouder nu een acuut risico is
De PHP2Shell-kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 maken code-uitvoering zonder inloggen mogelijk. Ze zijn verholpen in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Voor PHP 8.1 en ouder zijn er geen officiële updates meer, alleen minimale broncode-backports voor 7.4, 8.0 en 8.1. Volgens de vakpers zijn bijna alle versies tot en met PHP 5.4 getroffen.
Sommige distributies en hosters installeren eigen backports. Of uw systeem daartoe behoort, moet de aanbieder voor uw concrete pakketstand bevestigen. Zonder die bevestiging moet u ervan uitgaan dat de server openstaat. Wat dat in detail betekent, beschrijft PHP 8.1 en ouder: wat nu geldt.
PHP 8.1 upgrade: welke doelversie?
Het doel moet een versie zijn die het PHP-project nog ondersteunt en die uw toepassing vrijgeeft. De actuele stand van de ondersteuning publiceert php.net op de pagina van de ondersteunde versies. PHP 8.2 eindigt op 31 december 2026; een overstap naar 8.2 zou dus slechts een tussenstap zijn met een spoedig vervolgproject.
Welke PHP-versie uw CMS of shopsysteem ondersteunt, controleren we aan de hand van de systeemeisen van de fabrikant, bijvoorbeeld op wordpress.org, shopware.com of typo3.org, en niet uit het hoofd. Vaak moet eerst het CMS zelf worden bijgewerkt. Oude shops zijn een typisch geval, zie Shopware 5: oude shops op een oude PHP-versie.
Hoe helpt PHP SOS concreet?
- Inventarisatie en beveiliging: wij leggen alle toepassingen, hun PHP-versie, CMS-stand, extensies en eigen code vast. Parallel voeren we de overbruggingsmaatregelen volgens php.net door, zodat het risico tot de migratie daalt; details onder WAF en virtueel patchen.
- Compatibiliteit controleren: wij vergelijken de systeemeisen van de fabrikanten, controleren afhankelijkheden met Composer en zoeken in de eigen code naar verouderde functies. Hoe dat bij afhankelijkheden eruitziet, beschrijft Composer-afhankelijkheden op lekken controleren.
- Test in een kopie: de toepassing draait eerst in een testomgeving met de nieuwe PHP-versie. Fouten verhelpen we daar of we documenteren ze voor uw bureau.
- Omschakeling met terugweg: de live-omschakeling vindt plaats in een afgesproken onderhoudsvenster met een actuele back-up en een vastgelegde terugweg.
- Nacontrole: na de omschakeling controleren we foutlogs en centrale functies en verwijderen we de oude PHP-versie als die niet meer nodig is.
Een ongevaarlijke blik op welke websites welke PHP-versie gebruiken, is op veel systemen mogelijk via de lopende FPM-pools:
# lopende PHP-FPM-master en pools tonen
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# geïnstalleerde PHP-versies (Debian/Ubuntu)
ls /etc/php/
Een upgrade naar een nieuwe PHP-versie verwijdert geen schadelijke software die eerder is binnengebracht. Stond de server sinds 17 oktober 2026 onbeschermd aan het netwerk, dan hoort een controle op sporen erbij.
Typische struikelblokken bij de upgrade
De meeste problemen bij het wisselen van de PHP-versie zijn voorspelbaar als men weet waar te zoeken:
- Verouderde extensies: plugins of modules die niet meer worden onderhouden, draaien op nieuwere PHP-versies vaak niet. Daarvoor is een vervanger of een aanpassing nodig.
- Eigen code: functies die PHP inmiddels als verouderd heeft gemarkeerd of heeft verwijderd, leiden tot waarschuwingen of afbrekingen. Strengere typecontroles leggen oude programmeerfouten bloot.
- Afhankelijkheden: bibliotheken die via Composer zijn ingebonden, vragen soms zelf nieuwe versies en trekken verdere wijzigingen na zich mee.
- PHP-extensies op de server: niet elke extensie die onder de oude versie was geïnstalleerd, is automatisch ook voor de nieuwe aanwezig.
- Cronjobs en opdrachtregel: de website draait al op de nieuwe versie, maar geplande taken roepen nog de oude PHP-versie aan.
Wie deze punten vooraf controleert, verkort de omschakeling en voorkomt verrassingen in de live-omgeving.
Wat u krijgt en wat wij nodig hebben
U krijgt een overzicht van alle toepassingen met uitgangs- en doelversie, een migratieplan met volgorde en risico's, een testprotocol, de documentatie van de omschakeling en een lijst van punten die uw bureau of ontwikkelaar nog moet afhandelen.
Wij hebben van u nodig:
- server- of paneeltoegang en toegang tot de CMS-backends
- toegang tot broncode en repository bij maatwerk
- contact met bureau of ontwikkelaar die de toepassing kennen
- een testomgeving of toestemming er een aan te maken
- onderhoudsvensters en een aanspreekpunt voor de acceptatie
Wat we niet beloven
Wij beloven niet dat elke oude toepassing zonder wijzigingen op een nieuwe PHP-versie draait. Bij systemen zonder doorontwikkeling kan een grotere ombouw of een overstap nodig zijn; dat zeggen we openlijk zodra het zich aftekent. Uitspraken over compatibiliteit baseren we op de opgaven van de fabrikanten. En overbruggingsmaatregelen zijn geen vervanging van de migratie, ze overbruggen alleen de tijd. Langetermijnrisico's van verouderde versies beschrijft PHP end of life: risico's van verouderde versies.
Veelgestelde vragen
Is PHP 8.1 getroffen door PHP2Shell?
Volgens de vakpers zijn bijna alle versies tot en met PHP 5.4 getroffen. Voor PHP 8.1 en ouder zijn er geen officiële updates meer van het PHP-project, alleen minimale broncode-backports voor 7.4, 8.0 en 8.1. Sommige distributies installeren eigen backports; dat moet de betreffende aanbieder bevestigen.
Naar welke PHP-versie moet ik upgraden?
Naar een versie die het PHP-project nog actief ondersteunt en die uw toepassing volgens de systeemeisen van de fabrikant vrijgeeft. PHP 8.2 bereikt op 31 december 2026 het einde van de ondersteuning en is daarom slechts beperkt zinvol als doel.
Kan ik de PHP-versie niet gewoon in het hostingpaneel omzetten?
Technisch kan dat vaak met één klik. Of de toepassing daarna nog draait, hangt af van CMS-versie, extensies en eigen code. Zonder test riskeert u storingen of defecte functies, bijvoorbeeld in de kassa van een shop.
Wat als mijn CMS de nieuwe PHP-versie niet ondersteunt?
Dan moet eerst het CMS worden bijgewerkt, onder omstandigheden naar een nieuwe hoofdversie. Bij systemen zonder doorontwikkeling kan een overstap nodig zijn. Tot dan beveiligen wij de server met overbruggingsmaatregelen.