Twee kritieke PHP-lekken: wat het voor u betekent, en wat niet

Een veiligheidsmelding van een leverancier lees je doorgaans met één vraag in het achterhoofd: moet ik iets doen? Staat er "geen actie vereist", dan sluit men het bericht en gaat men verder. Dat is begrijpelijk, en het is ook precies de verkeerde reflex. Een melding als deze vertelt u namelijk twee dingen tegelijk: hoe het met uw leverancier gesteld is, én welke vraag u over uw eigen omgeving hoort te stellen.

Op 21 oktober 2026 kondigde de PHP Foundation herstelversies aan voor twee kritieke kwetsbaarheden. Zoho publiceerde de dag erna zijn eigen evaluatie. Beide stukken samen maken een nuchter verhaal, en het loont om ze uit elkaar te houden.

Wat er precies gedicht is

De twee lekken dragen de nummers CVE-2026-109618 en CVE-2026-109619. Het eerste maakt uitvoering van code op afstand mogelijk via geheugenbeschadiging bij geheugentekort; het tweede via achtergebleven globale toestand. Beide kregen onder CVSS v4.0 een score van 9.2 en gelden daarmee als kritiek. Ze raken installaties van PHP als webserver, en de herstelversies zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35.

Uitvoering van code op afstand is de zwaarste categorie die er bestaat: wie ze weet te misbruiken, voert zijn eigen opdrachten uit op uw server. Dat is geen lek waarbij iemand iets te veel ziet; het is een lek waarbij iemand iets kan doen. Dat verklaart de score, en het verklaart waarom de versienummers hierboven het eigenlijke nieuws zijn. Alles daaronder is kwetsbaar.

Wat Zoho nakeek, en wat dat opleverde

Na de bekendmaking hebben de veiligheidsteams van Zoho de eigen producten en infrastructuur doorgelicht. De uitkomst staat helder beschreven. De Zoho-producten zelf gebruiken geen PHP en zijn dus niet getroffen. Een aantal blogs en publieke statische pagina's draait wél op PHP-webservers; die zijn naar de herstelde versies gebracht. Gofrugal SAM gebruikt een PHP-webserver en is bijgewerkt. Enkele interne diensten draaien eveneens op PHP; die zijn niet bereikbaar vanaf het publieke internet, wat de blootstelling beperkt, maar ook zij zijn bijgewerkt.

De conclusie: er is geen gevolg vastgesteld voor klantgegevens of voor de werking van de Zoho-toepassingen, er is geen actie nodig van klanten, en er zijn geen aanwijzingen van misbruik gevonden. Vragen kunnen naar het veiligheidsteam via security@zohocorp.com. Dat is hoe een nette melding eruitziet: wat is er, wat hebben wij nagekeken, wat hebben we gevonden, en wat moet u doen. Dat laatste antwoord gaat over de omgeving van Zoho, niet over de uwe.

De vraag die bij u blijft liggen

Want PHP is in België en Nederland alomtegenwoordig. De kans is groot dat uw onderneming er minstens één installatie van heeft draaien: de bedrijfswebsite, een webshop, een klantenportaal, een oud intranet dat niemand meer aanraakt. Die laatste categorie is de gevaarlijke. Niet omdat ze belangrijker is, maar omdat niemand zich verantwoordelijk voelt voor iets wat al jaren gewoon werkt.

De drie vragen die deze melding bij u hoort op te roepen, zijn dan ook bescheiden van formaat. Welke van uw publiek bereikbare servers draaien PHP, en op welke versie? Wie werkt ze bij — uw eigen mensen, uw webbouwer of uw hostingpartij? En binnen welke termijn, wanneer het etiket "kritiek" erop staat? Wie op de eerste vraag geen antwoord heeft, hoeft de andere twee niet te stellen: die onderneming werkt niet met een termijn maar met geluk.

Praktisch gesproken is dat een lijst van een half A4: per toepassing de naam, de leverancier, de contactpersoon en de afgesproken reactietijd bij een kritieke melding. Leg die lijst aan buiten de toepassingen zelf, want precies bij een incident is dat wat u niet kunt openen. En neem de veiligheidsmeldingen van uw leveranciers op in datzelfde overzicht; ze zijn pas nuttig wanneer iemand ze leest en er een handeling aan koppelt. Hoe Zoho zijn eigen hulpinformatie en meldingen ontsluit, vindt u op help.zoho.com.

Veelgestelde vragen

Moet ik iets doen in mijn Zoho-omgeving?

Nee. Zoho stelt uitdrukkelijk dat zijn producten geen PHP gebruiken, dat er geen gevolg is vastgesteld voor klantgegevens of voor de werking van de toepassingen, en dat er geen actie nodig is van klanten. De onderdelen die wél op PHP draaien — enkele blogs, publieke pagina's en interne diensten — zijn door Zoho zelf bijgewerkt. U hoeft dus niets te installeren of te wijzigen. Wat u wél kunt doen, is deze melding noteren in uw eigen overzicht van leveranciersmeldingen, zodat u later kunt aantonen dat u ze gezien en beoordeeld hebt.

Hoe weet ik of mijn eigen website PHP gebruikt?

Meestal weet uw webbouwer of hostingpartij dat meteen, en dat is ook de snelste weg: één mail met de vraag welke PHP-versie draait en of ze naar de herstelde versies gegaan zijn. Veel courante systemen voor websites en webshops draaien op PHP, dus het antwoord is vaker ja dan nee. Vraag er meteen bij hoe u in de toekomst verwittigd wordt bij een kritieke melding en binnen welke termijn er dan bijgewerkt wordt. Dat gesprek voert u beter nu, op een rustige dag, dan tijdens het volgende lek.

Wat betekent een score van 9.2 concreet?

CVSS is de internationale maatstaf om de ernst van een kwetsbaarheid uit te drukken, op een schaal tot tien. Een 9.2 betekent kritiek: de combinatie van wat een aanvaller kan bereiken en hoe makkelijk hij erbij kan, zit aan de zware kant. Bij deze twee gaat het om uitvoering van code op afstand, de categorie waarbij iemand niet alleen gegevens ziet maar ook opdrachten uitvoert op uw server. In de praktijk is dat het verschil tussen een lek dat u deze maand inplant en een lek dat u deze week behandelt.

Wij hebben een oude toepassing die niemand nog onderhoudt. Wat nu?

Dat is het eerlijkste antwoord dat u op zo'n lijst kunt tegenkomen, en het vraagt een beslissing in plaats van een herstelversie. Drie wegen liggen open: alsnog iemand aanstellen die ze bijwerkt, ze van het publieke internet halen zodat ze enkel intern bereikbaar is, of ze uitschakelen. Zoho noemt die middelste weg zelf voor zijn interne diensten: niet bereikbaar van buitenaf, wat de blootstelling beperkt. Kiest u niets, dan kiest u in de praktijk voor de eerste optie zonder iemand aan te stellen, en dat is de duurste.

Hoe houden wij dit soort meldingen voortaan bij?

Met een overzicht dat klein genoeg is om te onderhouden. Noteer per toepassing wie de leverancier is, wie uw aanspreekpunt is, en wat de afgesproken reactietijd is bij een kritieke melding. Wijs één persoon aan die de veiligheidsmeldingen van die leveranciers leest, ook wanneer er "geen actie vereist" staat, en laat die persoon per melding noteren wat er besloten is. Voor KMO's in België en MKB-bedrijven in Nederland is dat geen zware oefening, en het is precies het soort spoor waar u bij een audit of een incident naar zoekt.