PHP 8.1 of ouder en updaten lukt niet: wat nu?

Je hostingprovider vraagt om PHP te updaten. Je ontwikkelaar waarschuwt voor een beveiligingslek. Maar zodra je een nieuwere PHP-versie inschakelt, valt je klantenportaal, planning of facturatiesoftware uit. Wat als je PHP 8.1 of ouder gebruikt en je PHP niet meer kunt updaten zonder je bedrijf stil te leggen?

De PHP security advisory van 21 oktober 2026 maakt die vraag bijzonder actueel. CVE-2026-109618 en CVE-2026-109619 zijn twee kritieke kwetsbaarheden in PHP zelf. Een werkende website is daardoor geen bewijs van een veilige website. Hieronder lees je wat bekend is, welke tijdelijke keuzes je hebt en hoe je een geblokkeerde PHP-upgrade omzet in een haalbaar moderniseringstraject.

Wat melden CVE-2026-109618 en CVE-2026-109619?

Volgens de officiële PHP security advisory kunnen de kwetsbaarheden uitvoering van code op afstand mogelijk maken, zonder dat een aanvaller eerst inlogt. Dat heet remote code execution (RCE). De gevolgen kunnen ernstig zijn voor gegevens en bedrijfscontinuïteit.

• CVE-2026-109618 draait om geheugen dat bij een geheugentekort nog niet volledig is geïnitialiseerd, maar bij het opruimen toch wordt gebruikt. De technische melding van het PHP-project beschrijft de voorwaarden en impact.
• CVE-2026-109619 betreft interne toestand die naar vrijgegeven geheugen blijft verwijzen. Een volgend verzoek binnen dezelfde worker kan die toestand opnieuw gebruiken. Zie de afzonderlijke PHP-beveiligingsmelding.

Beide meldingen krijgen een CVSS v4.0-score van 9,2 op 10: kritiek. De precieze blootstelling hangt af van de server, instellingen, extensies en applicatie. Apache met mod_php en PHP-FPM vragen allebei aandacht; alleen van webserver veranderen bewijst geen veiligheid.

Welke PHP-versies moet je bijwerken?

Op 21 oktober 2026 publiceerde PHP beveiligingsreleases. Binnen de ondersteunde branches zijn de fixes beschikbaar vanaf:

PHP-branch	Release met de beveiligingsfixes
PHP 8.2	PHP 8.2.35
PHP 8.3	PHP 8.3.36
PHP 8.4	PHP 8.4.27
PHP 8.5	PHP 8.5.12

Controleer bij je leverancier welk pakket de fixes bevat; een distributie kan patches terugbrengen naar een oudere pakketversie. Gebruik de PHP-downloadpagina en de advisory als vertrekpunt. Dit overzicht is een momentopname, geen advies om toekomstige updates over te slaan.

PHP 8.1 en ouder ontvangen geen reguliere updates meer van het PHP-project. Voor PHP 7.4, PHP 8.0 en PHP 8.1 zijn uitzonderlijk minimale broncodebackports beschikbaar gesteld. Dat zijn geen nieuwe ondersteunde releases of een automatische hostingupdate. Vraag je beheerder of leverancier hoe beide fixes in jouw installatie terechtkomen.

PHP 8.1 end-of-life: waarom dit verder gaat dan één beveiligingslek

De officiële PHP end-of-life-tabel vermeldt dat ondersteuning voor PHP 8.1 op 31 december 2025 eindigde. Ook PHP 8.0, PHP 7.4 en eerdere branches zijn end-of-life. EOL betekent dat je niet op reguliere beveiligingsupdates van het PHP-project kunt rekenen.

Een oplossing voor deze twee CVE's maakt een oude PHP-omgeving dus nog niet duurzaam onderhoudbaar. Je blijft afhankelijk van beschikbare backports, je hostingcontract en de staat van frameworks, plug-ins en bibliotheken.

Kijk ook vooruit wanneer een tussenstap wel lukt: volgens het overzicht van ondersteunde PHP-versies eindigt de security support voor PHP 8.2 op 31 december 2026. Bepaal je doelversie op basis van compatibiliteit én resterende ondersteuning.

Waarom kun je je PHP-versie niet zomaar verhogen?

Bij legacy PHP-software is PHP vaak slechts één schakel. Een oud framework verwacht gedrag dat is veranderd. Een verlaten Composer-package blokkeert de installatie. Een koppeling gebruikt een extensie die ontbreekt. Of er zijn te weinig tests om te weten of facturen en berekeningen nog kloppen.

Veelvoorkomende blokkades zijn:

• Verouderde Laravel-, Symfony-, WordPress- of andere CMS-versies met afhankelijke modules.
• Maatwerk met verwijderde functies, gewijzigde types of oude databasecode.
• Een commerciële bibliotheek waarvoor geen compatibele versie beschikbaar is.
• Ontbrekende broncode, documentatie of toegang tot de oorspronkelijke leverancier.
• Bedrijfsregels die alleen in de bestaande toepassing zijn vastgelegd.

Maak daarom eerst zichtbaar wat de upgrade blokkeert. De conclusie ‘PHP updaten kan niet’ is te algemeen om een beslissing op te baseren. Benoem per blokkade het onderdeel, de eigenaar, de oplossing en de verwachte inspanning.

Wat kun je vandaag doen als een PHP-upgrade niet meteen lukt?

Werk aan twee sporen: beperk de huidige blootstelling en organiseer een concrete beveiligingsupdate of migratie. Laat je hostingpartner en ontwikkelaar daarbij dezelfde installatie beoordelen.

1. Controleer de PHP-versie die webverzoeken afhandelt

Vraag welke PHP-build je website werkelijk gebruikt. De commandoregel kan een andere versie gebruiken dan PHP-FPM of Apache. Neem ook subdomeinen, oude API's, testomgevingen en aparte pools mee. Leg vast welke leverancier verantwoordelijk is en of beide CVE-fixes aantoonbaar zijn geïnstalleerd.

2. Vraag naar een beveiligingsbackport of extended support

Een backport brengt een beveiligingspatch naar een oudere versie zonder de volledige applicatie meteen naar een nieuwe PHP-branch te verhuizen. Dat kan tijd kopen voor software die niet direct te migreren is.

Vraag je leverancier expliciet: dekt het aangeboden pakket beide CVE's, voor welke PHP-build, met welke updateprocedure en tot wanneer? Verifieer het geïnstalleerde pakket na de update en herstart de betrokken services volgens de leverancier. Alleen de vermelding ‘extended support’ is onvoldoende bewijs dat deze specifieke kwetsbaarheden zijn opgelost.

3. Pas tijdelijke maatregelen toe met kennis van de omgeving

Voor CVE-2026-109619 noemt het PHP-project onder meer het administratief uitschakelen van session.upload_progress.enabled, gevolgd door een herstart van alle workers. Dit moet vóór de verwerking van verzoeken gelden; alleen ini_set() in je applicatie is onvoldoende. Het blokkeert specifieke sessiepaden, geen volledige kwetsbaarheid. Verberg foutmeldingen niet als vermeende oplossing: daarmee verdwijnt de oorzaak niet. Lees de volledige instructies en beperkingen.

Voor CVE-2026-109618 bespreekt de advisory onder andere memory_limit=-1. Kopieer die instelling niet blind: je verwijdert daarmee PHP's geheugenlimiet per verzoek en kunt beschikbaarheidsproblemen veroorzaken. De maatregel is onvolledig en vraagt aanvullende begrenzing en beoordeling door je beheerder. Zie de officiële mitigatie-instructies.

4. Beperk toegang en bereid herstel voor

Onderzoek of de oude toepassing tijdelijk alleen via een VPN of toegangsfilter bereikbaar kan zijn. Een firewall of WAF kan extra bescherming bieden, maar bewijst niet dat de PHP-runtime gepatcht is. Laat publieke functies die je kunt missen tijdelijk uitschakelen na beoordeling van de bedrijfsimpact.

Controleer daarnaast of er bruikbare back-ups zijn en of herstel is getest. Bij vermoedens van misbruik hoort ook incidentonderzoek: een update verwijdert geen eerder geplaatste achterdeur. Laat verdachte bestanden, accounts en loggegevens beoordelen voordat je de omgeving als hersteld beschouwt.

Legacy PHP-software moderniseren: upgraden, gefaseerd vernieuwen of herbouwen?

De juiste aanpak hangt af van hoeveel van de toepassing nog onderhoudbaar is. Een volledige herbouw is geen automatische eerste stap.

Gericht upgraden past wanneer broncode en afhankelijkheden beschikbaar zijn en de belangrijkste blokkades oplosbaar zijn. Werk via een testomgeving, controleer de officiële PHP-migratiehandleidingen en test kritieke processen zoals aanmelden, facturatie, uploads en externe koppelingen.

Gefaseerd moderniseren past wanneer een groot systeem niet in één keer kan overstappen. Je vernieuwt onderdelen achtereenvolgens en maakt gegevensuitwisseling en verantwoordelijkheden expliciet. Zolang oude onderdelen actief blijven, moeten ook hun beveiliging en onderhoud geregeld zijn.

Software herschrijven kan zinvol zijn bij veel verlaten componenten, ondoorgrondelijke code of structureel ontbrekende ondersteuning. De waarde zit dan vaak in de bedrijfslogica: planningsregels, prijsafspraken, factuurstromen en uitzonderingen die je wilt behouden.

Bij Legacy Lab onderzoeken we welke route haalbaar is voor jouw maatsoftware. Bekijk bijvoorbeeld onze aanpak voor planningssoftware moderniseren, facturatiesoftware moderniseren en software herschrijven zonder broncode. Beschikbare toegang, gegevens en rechten bepalen wat mogelijk is.

Veelgestelde vragen over oude PHP-versies en beveiliging

Is mijn website veilig omdat alles nog werkt?

Nee. Een beveiligingsprobleem hoeft geen zichtbare fout te veroorzaken. Controleer de gebruikte PHP-build, de leveranciersmelding en de geïnstalleerde fixes. Een werkende pagina of een schone log is op zichzelf geen veiligheidscontrole.

Lost een WordPress-, plug-in- of frameworkupdate dit op?

De twee CVE's zitten in PHP zelf. Applicatie-updates blijven nodig, maar vervangen geen gepatchte PHP-runtime. Vraag je host dus ook naar de PHP-beveiligingsupdate.

Kan ik PHP 8.1 blijven gebruiken met een backport?

Een geverifieerde backport kan deze kwetsbaarheden aanpakken. Spreek daarnaast af wie volgende beveiligingsproblemen opvolgt en wanneer je naar een ondersteunde PHP-versie overstapt. Een noodpatch verlengt de reguliere PHP-ondersteuning niet.

Moet mijn volledige toepassing onmiddellijk opnieuw worden gebouwd?

Dat kun je pas na analyse bepalen. Soms volstaan aanpassingen aan afhankelijkheden en gerichte tests. In andere gevallen is een gefaseerde migratie of herbouw beter beheersbaar. Beschrijf eerst welke functies je bedrijf nodig heeft en welke onderdelen de upgrade tegenhouden.

Maak van een geblokkeerde PHP-update een concreet plan

Blijf je op PHP 8.1, PHP 8.0 of PHP 7.4 hangen? Verzamel je huidige PHP-versie, framework, belangrijkste koppelingen, beschikbare broncode en de fouten bij een upgrade. Daarmee kan een ontwikkelaar de technische schuld en migratierisico's gericht onderzoeken.

Legacy Lab helpt Belgische bedrijven om verouderde maatsoftware te analyseren en te moderniseren. Vertel ons over je bestaande PHP-software en vraag een vrijblijvende offerte aan. Deel daarbij geen wachtwoorden of gevoelige bedrijfsgegevens.

Officiële bronnen en verdere informatie

Gecontroleerd op 21 oktober 2026. Beveiligingsadviezen kunnen worden aangevuld; controleer voor uitvoering steeds de actuele bron en de melding van je pakketleverancier.

• PHP security advisory van 21 oktober 2026.
• CVE-2026-109618: RCE via OOM corruption — PHP-project.
• CVE-2026-109619: RCE via stale global state — PHP-project.
• PHP: ondersteunde versies en einddata.
• PHP: end-of-life-versies.
• Officiële PHP-downloads.