# PHP end of life: risico's van verouderde versies

> PHP end of life begrijpen: wat er na het einde van de ondersteuning gebeurt, waarom PHP 8.1 en ouder na PHP2Shell kritiek zijn en hoe u overstapt.

Bron: https://phpsos.de/nl/ratgeber/php-end-of-life-risiken/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort gezegd:** PHP end of life betekent: het PHP-project levert voor deze tak geen beveiligingsupdates meer. PHP2Shell toont de gevolgen duidelijk, want voor PHP 8.1 en ouder is er geen officiële fix en PHP 8.2 eindigt op 31-12-2026. Wie vandaag op een oude tak draait, moet de overstap nu plannen en niet pas bij de volgende noodsituatie.

## Wat PHP end of life betekent

Elke PHP-tak, bijvoorbeeld 8.2 of 8.3, wordt door het PHP-project maar gedurende een beperkte periode onderhouden. Eerst zijn er foutcorrecties en beveiligingsupdates, later alleen nog beveiligingsupdates. Daarna eindigt de ondersteuning volledig. De actuele periodes publiceert php.net op de pagina over ondersteunde versies.

Na het einde van de ondersteuning blijft de software weliswaar draaien. Wordt er echter een nieuwe kwetsbaarheid bekend, dan komt er van het PHP-project geen patch meer. De server blijft kwetsbaar totdat iemand anders bijwerkt of totdat u naar een ondersteunde tak overstapt.

Voor directie en IT-leiding is dit vooral een planningsvraag. Een migratie is rustig voor te bereiden. Onder tijdsdruk na een kritieke melding wordt ze duur en riskant.

## Wat PHP2Shell over verouderde versies laat zien

Op 21-10-2026 publiceerde het PHP-project patches voor twee kritieke kwetsbaarheden, CVE-2026-109618 en CVE-2026-109619. Beide maken het mogelijk om op afstand en zonder aanmelding schadelijke code uit te voeren en zijn beoordeeld met CVSS v4.0 9.2. Volgens de vakpers zijn vrijwel alle versies tot en met PHP 5.4 getroffen.

| Tak | Status volgens PHP-project | PHP2Shell-fix |
|---|---|---|
| PHP 8.5 | ondersteund | 8.5.12 |
| PHP 8.4 | ondersteund | 8.4.27 |
| PHP 8.3 | ondersteund | 8.3.36 |
| PHP 8.2 | ondersteund tot 31-12-2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | geen officiële updates | alleen minimale backports van de broncode |
| PHP 7.3 en ouder | geen officiële updates | geen backport van het PHP-project |

Voor 8.1 en ouder blijft zo alleen de weg via backports van distributies of hosters over. Die tonen vaak nog steeds het oude versienummer, ook al zijn ze gepatcht. Of een backport is geïnstalleerd, kan alleen de aanbieder bindend bevestigen. Details staan op de pagina [PHP 8.1 en ouder: wat nu geldt](https://phpsos.de/nl/php2shell/php-8-1-und-aelter/), het volledige overzicht onder [Welke PHP-versies zijn getroffen?](https://phpsos.de/nl/php2shell/betroffene-php-versionen/).

> **Belangrijk:**
> PHP 8.2 heeft de PHP2Shell-fix nog gekregen, maar bereikt op 31-12-2026 het einde van de ondersteuning. Wie nu van 8.1 migreert, moet direct een nieuwere tak kiezen.

## De risico's van verouderde PHP-versies in een overzicht

Het beveiligingsrisico staat voorop, maar is niet het enige. Verouderde PHP-versies trekken meer problemen na zich mee:

- **Geen patches voor nieuwe kwetsbaarheden:** Elke toekomstige zwakke plek blijft open of hangt af van backports van derden.
- **Verouderde bibliotheken:** Actuele pakketten vereisen nieuwere PHP-takken. Beveiligingscorrecties in bibliotheken zijn dan niet meer te installeren, zoals de gids [composer audit](https://phpsos.de/nl/ratgeber/composer-abhaengigkeiten-pruefen/) laat zien.
- **Afhankelijkheid van de aanbieder:** Hosters rekenen voor oude versies soms toeslagen of beëindigen de dienst. De termijn bepaalt dan de aanbieder, niet u.
- **Bewijsproblemen:** Tegenover verzekeraars, opdrachtgevers of bij audits is een niet-ondersteunde versie moeilijk te verantwoorden. Of daaruit contractuele of juridische gevolgen voortvloeien, stemt u af met verzekeraar of advocaat.
- **Groeiende migratie-inspanning:** Hoe groter de afstand tot de actuele versie, hoe meer code moet worden aangepast.

Bijzonder vaak getroffen zijn oudere webshopsystemen en lang niet aangeraakte maatwerkontwikkelingen. Een typisch voorbeeld is [Shopware 5](https://phpsos.de/nl/plattformen/shopware-5/), dat vaak nog op oudere PHP-takken draait.

## Inventarisatie: welke PHP-versies draaien er bij u?

De eerste stap is een volledig beeld. Op veel servers draaien meerdere PHP-versies parallel, bijvoorbeeld voor een oude website die niemand meer op het netvlies heeft. Deze opdrachten lezen alleen:

```bash
# Versie van de opdrachtregel
php -v
# Geïnstalleerde versies onder Debian/Ubuntu
ls /etc/php/
# Geïnstalleerde versies in Plesk
ls /opt/plesk/php/ 2>/dev/null
# Draaiende PHP-processen met versie in de naam
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
```

Leg voor elke website vast: domein, PHP-versie, uitvoeringsmodus, CMS met versie, verantwoordelijke persoon. Deze lijst is tegelijk de basis voor uw noodplan. Bij shared hosting vindt u de versies meestal in het klantenmenu van de hoster.

## Migratie plannen: zo gaat u te werk

Een migratie naar een ondersteunde tak volgt in de regel dezelfde stappen, onafhankelijk van het systeem:

1. **Doel bepalen:** een tak kiezen die volgens php.net nog zo lang mogelijk wordt ondersteund en volgens de systeemeisen van de fabrikant bij uw CMS past.
2. **Compatibiliteit controleren:** CMS, extensies, thema's en eigen code. De gegevens staan op de officiële pagina van de betreffende fabrikant.
3. **Staging opzetten:** een kopie van de website met de nieuwe PHP-versie, inclusief database.
4. **Testen:** alle belangrijke processen, van contactformulier tot bestelproces, plus het foutlog op waarschuwingen.
5. **Omschakelen en herstarten:** versie wisselen, alle PHP-processen herstarten, werking en foutlog controleren.

Plan realistisch. Een kleine website met een actueel CMS is vaak snel omgezet. Een over jaren gegroeide webshop met veel extensies en eigen code kan daarentegen aanpassing van code en extensies vereisen, tot en met de overstap naar een nieuwe hoofdversie van het shopsysteem. Verduidelijk vroeg wie intern beslist, welk budget beschikbaar is en of externe ontwikkelaars moeten worden betrokken.

Bepaal bovendien hoe u in de toekomst het einde van ondersteuningen in het oog houdt. Een vast moment per jaar waarop u de lijst van uw websites vergelijkt met de gegevens op php.net, voorkomt dat over twee jaar hetzelfde knelpunt opnieuw ontstaat.

Tot de omschakeling moet u de tussenmaatregelen van php.net gebruiken, bijvoorbeeld `session.upload_progress.enabled=0` in de serverconfiguratie. Ze zijn geen volledige bescherming, maar verlagen het risico.

## Hoe helpt PHP SOS concreet?

- We inventariseren alle PHP-versies, uitvoeringsmodi en toepassingen op uw servers.
- We beoordelen het risico per website en bepalen samen met u volgorde en doelversie.
- We voeren tot de migratie tussenmaatregelen door en vragen bevestigingen over backports bij de aanbieder op.
- We migreren via een stagingomgeving en documenteren test en omschakeling.

Het verloop beschrijft de dienst [PHP 8.1 en ouder: migratie naar een ondersteunde versie](https://phpsos.de/nl/leistungen/php-migration-legacy/).


## Veelgestelde vragen

**Wanneer eindigt de ondersteuning voor PHP 8.2?**  
PHP 8.2 bereikt op 31-12-2026 het einde van de ondersteuning door het PHP-project. De PHP2Shell-fix heeft deze tak nog gekregen met versie 8.2.35; voor latere kwetsbaarheden is daarna geen officiële update meer te verwachten.

**Krijgt PHP 8.1 een patch tegen PHP2Shell?**  
Van het PHP-project zijn er voor 8.1 en ouder geen officiële updates meer. Er bestaan alleen minimale backports van de broncode voor 7.4, 8.0 en 8.1. Of en hoe uw hoster of distributie die installeert, moet u bij de aanbieder navragen.

**Is een oude PHP-versie met backports van de hoster veilig?**  
Backports kunnen concrete kwetsbaarheden dichten, maar vervangen geen ondersteunde tak. Ze hangen af van de aanbieder, komen vaak later en dekken niet elke kwetsbaarheid. Als blijvende oplossing zijn ze dus ongeschikt.

**Hoe weet ik of mijn CMS met een nieuwe PHP-versie draait?**  
Controleer de systeemeisen op de officiële pagina van de fabrikant en test in een stagingomgeving. Voor extensies en thema's geldt hetzelfde, want die vormen vaak de eigenlijke knelpunten.

## Bronnen

- [php.net: ondersteunde versies](https://www.php.net/supported-versions.php)
- [php.net: beveiligingsmeldingen](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)