Kritieke PHP-fout in oktober 2026: wat betekent dit?

De bevestigde stand, zonder paniekkop

PHP heeft twee kritieke kwetsbaarheden gepubliceerd: CVE-2026-109618 en CVE-2026-109619. Ze kunnen code-uitvoering op afstand mogelijk maken zonder voorafgaande aanmelding. De officiële waarschuwing noemt PHP-installaties die webverzoeken verwerken, waaronder PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. De reparaties zijn beschikbaar. PHP, gecontroleerd 21 oktober 2026

Een leverancier kan de reparatie ook verwerken in een eigen onderhouden pakket. Controleer dan diens beveiligingsbericht en pakketversie. PHP noemt bijwerken de volledige oplossing; tijdelijke instellingen dekken niet alle aanvalspaden. Oudere reeksen vragen afzonderlijke aandacht voor ondersteuning of een aantoonbare leverancierspatch. Officiële update-informatie

De eerste fout raakt de afhandeling van geheugenuitputting. De tweede raakt interne toestand die na het vrijgeven van geheugen kan blijven bestaan. Bij mod_php is een aanval beschreven voordat de eigenlijke applicatiecode start. De details en voorwaarden verschillen per omgeving. Dat is waarom een algemeen oordeel op basis van alleen het uiterlijk van een website niet werkt. Technische melding 1, technische melding 2

Waarom het percentage in de kop niet jouw uitslag is

W3Techs rapporteert op 21 oktober 2026 een PHP-aandeel van 69,3% onder websites waarvan het de servertaal kent. Dat is een gebruiksstatistiek. Het is geen telling van gehackte websites en ook geen individuele kwetsbaarheidstest. Je kunt er niet uit afleiden of jouw omgeving al is bijgewerkt. W3Techs, peildatum 21 oktober 2026

Voor een ondernemer zijn twee vragen belangrijker dan het marktaandeel. Gebruiken wij de betreffende techniek ergens? En wat is de actuele toestand van die onderdelen? Een groot percentage kan een incident nieuwswaardig maken, maar helpt je niet kiezen tussen niets wijzigen, een beheerder laten controleren, een update laten uitvoeren of een onderdeel tijdelijk beperken.

Vergelijk het met een terugroepactie voor een onderdeel van een bedrijfsauto. Je bepaalt eerst of het onderdeel in jouw auto zit. Daarna kijk je of het al vervangen is. Het aantal verkochte auto's zegt iets over de omvang van de actie, maar niet over de toestand van jouw voertuig. Deze vergelijking is alleen bedoeld om de besluitvorming duidelijk te maken.

We gebruiken daarom geen teller met een zogenaamd aantal getroffen klanten. Daarvoor zou een echte inventaris met passende bewijsstukken nodig zijn. Een onbekend aantal is onbekend. Het wordt niet nul omdat een website nog bereikbaar is, en ook niet honderd procent omdat er een grote krantenkop staat.

Drie uitspraken die vaak door elkaar lopen

Een kwetsbaarheid is een fout waardoor misbruik mogelijk kan zijn. Blootstelling gaat over de vraag of een relevante route in jouw omgeving bereikbaar is. Een daadwerkelijk incident gaat over aanwijzingen dat iemand misbruik heeft gemaakt. In een praktisch overleg verdienen die drie onderwerpen ieder een eigen antwoord.

Een bruikbare statusregel kan bijvoorbeeld luiden: de gebruikte techniek is vastgesteld, de leverancier bevestigt de reparatie en er is nog geen afzonderlijk incidentonderzoek uitgevoerd. Dat is duidelijker dan het losse woord veilig. Het vertelt de eigenaar wat bekend is en welke vraag nog buiten de controle valt.

Andersom is de aanwezigheid van een kwetsbare versie reden voor actie, maar geen bewijs dat alle bedrijfsgegevens al zijn gestolen. Onjuiste conclusies kunnen tot verkeerde keuzes leiden: bestanden te snel verwijderen, onnodig diensten uitzetten of juist helemaal niets doen omdat de site normaal oogt.

Onze voorgestelde werkwijze is een klein beslisdocument met vier velden: vastgestelde situatie, onderbouwing, genomen maatregel en resterende vraag. Dat document kan kort zijn. De waarde zit in de koppeling tussen uitspraak en bewijs, niet in de hoeveelheid technische termen.

Wat je als eigenaar vandaag kunt laten vaststellen

Begin met de onderdelen die klanten gebruiken. Noteer je hoofdwebsite, formulieren, eventuele boekingspagina, winkel, klantomgeving en de systemen waar die onderdelen op aansluiten. Denk ook aan een oude testwebsite die nog op een subdomein staat. Zet bij ieder onderdeel wie het technisch beheert.

Je hoeft hiervoor geen wachtwoorden te verzamelen in een spreadsheet. De vraag is wie verantwoordelijk is en welk systeem het betreft. Een eigenaar kan bijvoorbeeld weten dat het contactformulier naar een andere applicatie verstuurt, zonder toegang tot de volledige code te hebben. Die afhankelijkheid hoort wel op de lijst.

Vraag de beheerder daarna om een concrete, gedateerde terugkoppeling. Niet alleen of er updates zijn uitgevoerd, maar op welk onderdeel en op basis van welke leveranciersinformatie. Een hoster en een websitebouwer kunnen allebei werk hebben gedaan terwijl een oude omgeving buiten hun controle bleef. Dat ontdek je eerder met een afgebakende lijst.

Onze vragen voor je webbureau helpen om dat gesprek te voeren. Wil je eerst de verschillende onderhoudslagen begrijpen, lees dan het verschil tussen WordPress, PHP en plug-ins. Daarmee kun je gerichter vragen stellen zonder zelf systeembeheerder te worden.

Een bruikbaar bewijskaartje per onderdeel

Een bewijskaartje is een redactioneel hulpmiddel dat wij voorstellen, geen officieel keurmerk. Het voorkomt dat een team dagen later opnieuw moet uitzoeken waarop een status was gebaseerd. Je kunt het gebruiken in een ticket, projectdocument of eenvoudig klantoverzicht.

Een fictief voorbeeld: een installatiebedrijf heeft een informatieve website en een aparte offerteapplicatie. De websitebouwer bevestigt dat de publieke pagina's zonder PHP worden geleverd. Over de offerteapplicatie ontbreekt nog informatie. De juiste status is dan niet dat het hele bedrijf buiten schot staat. De publieke site en de offerteapplicatie krijgen afzonderlijke regels.

In een tweede fictief voorbeeld heeft een bureau een update ingepland maar nog geen bevestiging van de hoster ontvangen. Gepland is dan de status, niet opgelost. Pas wanneer de maatregel en de relevante werking zijn gecontroleerd, kan de regel veranderen. Dat voorkomt dat een goede intentie ongemerkt als afgerond werk wordt doorverteld.

Bewaar het kaartje op een plek die later terug te vinden is. Zet geen herstelcodes, geheime sleutels of persoonlijke klantinhoud in het document. Een bewijsverwijzing kan voldoende zijn; niet iedereen die de status leest hoeft toegang te hebben tot het onderliggende systeem.

Wie moet welk antwoord geven?

Veel vertraging ontstaat doordat iedereen denkt dat een andere partij de onderliggende software beheert. De ondernemer ziet één website. Achter die website kunnen een bouwer, hoster, externe formulierdienst en softwareleverancier zitten. Spreek daarom af wie de vragen bundelt en wie de eindstatus aan jou terugkoppelt.

De websitebouwer kan doorgaans het applicatieoverzicht toelichten. De hoster kan informatie hebben over de serveromgeving. De leverancier van een losse dienst kan alleen zijn eigen product bevestigen. Dat zijn verschillende verantwoordelijkheden. Het is niet zinvol om van iedere partij een verklaring over het hele landschap te verlangen.

Een praktisch bericht aan je vaste aanspreekpunt kan zo kort zijn: hebben jullie vastgesteld welke van onze webonderdelen onder de PHP-waarschuwing vallen, welke maatregel is genomen en welk bewijs hoort daarbij? Laat het antwoord per onderdeel geven. Vraag ook expliciet wie opvolgt wanneer een andere leverancier nog niet heeft gereageerd.

Dit is een voorstel voor goede samenwerking, geen contractuitleg. Welke dienstverlening precies is afgesproken staat in jouw overeenkomst. Als onderhoud en hosting los zijn ingekocht, bespreek dan de aansluiting tussen die afspraken. Een gunstige maandprijs helpt weinig wanneer onduidelijk is wie een belangrijke melding oppakt.

Tijdelijk afschermen is een afweging, geen standaardknop

CERT-EU adviseert getroffen onderdelen onmiddellijk bij te werken. Als direct herstel niet haalbaar is, noemt het tijdelijk isoleren van internetgerichte applicaties als een te overwegen maatregel. Dat is een beveiligingsadvies, geen algemene opdracht om iedere website uit te schakelen. CERT-EU, bijgewerkt advies 2026-018 van 21 oktober 2026

Voor jouw besluitvorming is het nuttig vooraf te weten welke functie kritisch is. Een openbare brochurepagina heeft een andere bedrijfsrol dan een omgeving waarin klanten betalen of documenten ophalen. Laat de technische beheerder uitleggen welke maatregel bij het betreffende onderdeel past en wat bezoekers daarvan merken.

Maak ook de communicatie concreet. Als een functie tijdelijk niet beschikbaar is, geef bezoekers een passend alternatief. Denk aan een telefoonnummer, een veilige contactroute of een duidelijke melding dat een aanvraag later kan worden gedaan. Beloof geen hersteltijd die nog niemand heeft bevestigd.

De maatregel en het alternatief horen bij elkaar. Een functie uitzetten zonder rekening te houden met de klantreis kan een tweede probleem creëren. Tegelijk is commerciële hinder geen reden om een technische waarschuwing te negeren. Leg de afweging vast en laat de verantwoordelijke beheerder de uitvoering bepalen.

Een website die zonder PHP draait

Wanneer een gecontroleerd onderdeel geen PHP uitvoert, ontbreekt daar de betreffende PHP-runtime waarop deze fouten betrekking hebben. Dat is een afbakening van dit specifieke incident. Het is geen uitspraak dat het onderdeel nooit een ander beveiligingsprobleem kan krijgen.

Een visuele indruk geeft hierover geen uitsluitsel. Een moderne voorkant kan data ophalen uit een ouder systeem. Een statisch gebouwde pagina kan een extern formulier gebruiken. Daarom kijken we bij de architectuurvraag naar de onderdelen en verbindingen, niet naar het design of een technologielogo in de footer.

Wil je weten wanneer een lichtere technische opzet bij je bedrijf past, begin dan bij een website zonder PHP. Daar vergelijken we keuzes vanuit onderhoud, publicatie en bedrijfsfuncties. Een acute veiligheidsmelding is geen goede reden om haastig een complete migratie te starten zonder eerst het bestaande probleem te behandelen.

Voor een nieuwe site kan eenvoud wel een nuttig ontwerpdoel zijn. Minder onderdelen die je niet nodig hebt, minder beheerconstructies die niemand begrijpt en duidelijkere grenzen tussen publieke informatie en privégegevens. Dat zijn keuzes die je vooraf kunt bespreken, zonder een algemene veiligheidsbelofte te doen.

Wat je na een ingreep wilt controleren

Een afgeronde technische wijziging moet ook passen bij de gebruikersreis. Maak daarom vooraf een korte lijst met wat een bezoeker echt moet kunnen doen. Voor een dienstverlener kan dat lezen, bellen en een aanvraag versturen zijn. Voor een webshop komt daar een ander pakket functies bij.

Onze voorgestelde controle begint niet met alle mogelijke pagina's tegelijk. Kies de belangrijkste ingang, de primaire actie en de ontvangst van het resultaat. Als een aanvraagformulier alleen een succesmelding laat zien, weet je nog niet of de aanvraag op de bedoelde plek is aangekomen. Test het einde van de handeling.

Gebruik daarvoor afgesproken testgegevens. Stuur geen echte klantdossiers rond om te zien of een formulier werkt. Leg vast wat je hebt geprobeerd en wie de uitkomst heeft gezien. Dat maakt het mogelijk later onderscheid te maken tussen een mislukte test, een oude foutmelding en een nieuwe klacht.

De precieze beheerprocedure staat in PHP bijwerken en werking controleren. Voor herstelbaarheid is er een afzonderlijke uitleg over back-ups en hersteltests. Die twee taken ondersteunen elkaar, maar leveren niet hetzelfde bewijs op.

Wat wij wel en niet uit de AI-kop afleiden

In nieuwsberichten rond dit incident wordt AI genoemd. Voor dit artikel hebben we geen zelfstandig bevestigde primaire onderzoekerspublicatie waarmee we de precieze modelkeuze of de mate van autonomie kunnen vaststellen. We vullen die details daarom niet in. De technische waarschuwingen zijn op zichzelf voldoende aanleiding om de omgeving te laten controleren.

Voor ondernemers is de praktische vraag breder: hoe voorkom je dat snelheid ten koste gaat van verantwoordelijkheid? Een hulpmiddel dat code voorstelt kan nuttig zijn. Iemand moet nog bepalen welke wijziging passend is, wat deze raakt en welk resultaat gecontroleerd moet worden. Dat blijft belangrijk bij handgeschreven én met AI gemaakte wijzigingen.

Dat principe geldt ook voor dit artikel. We verwijzen bij incidentfeiten naar primaire bronnen en maken onze eigen adviezen herkenbaar als werkwijze. Een bronverwijzing is geen certificaat. Het is een manier om de lezer te laten controleren waar een specifieke bewering vandaan komt.

Meer hierover lees je in AI en websitebeveiliging. Daar gaat het om rechten, controle en praktisch gebruik. Het is geen lijst met spectaculaire aanvalsmethoden en ook geen belofte dat AI alle beveiligingsproblemen automatisch oplost.

Een besluit voor vandaag en een besluit voor later

Houd de onmiddellijke veiligheidsvraag gescheiden van de websitekeuze voor het komende jaar. Vandaag wil je weten of een relevant onderdeel aandacht vraagt en wie die aandacht uitvoert. Later kun je beoordelen of de technische inrichting nog past bij je bedrijf. Door beide gesprekken te scheiden voorkom je een overhaaste aankoop.

Een bruikbaar besluit voor vandaag bevat een verantwoordelijke, de nog ontbrekende informatie en de eerstvolgende controle. Een besluit voor later kan gaan over het verminderen van losse systemen, betere documentatie, duidelijker onderhoud of een nieuwe site. Die tweede lijst hoeft de eerste niet tegen te houden.

Bij een overstap horen eigen voorwaarden: behoud van pagina's, formulieren, vindbaarheid en toegang. Onze migratiechecklist gaat daar dieper op in. Wie alleen een rustiger en betaalbaarder websitebeheer zoekt, kan ook kijken naar een website voor 75 euro per maand.

Goed beheer hoeft niet onbegrijpelijk te zijn. Een eigenaar moet kunnen zien wat er is afgesproken, welk werk is gedaan en waar nog een keuze nodig is. Dat is het uitgangspunt dat wij belangrijk vinden bij websitebouw en technische SEO. De concrete invulling bespreek je voordat je een opdracht geeft.

Zo lees je een statusbericht kritisch

Vraag bij het woord gecontroleerd altijd wat de controle omvatte. Een bezoek aan de homepage is een andere controle dan een bevestiging van de hostingomgeving. Een automatische melding is een ander soort bewijs dan een geslaagde handeling door een gebruiker. Beide kunnen nuttig zijn, zolang de betekenis duidelijk blijft.

Let vervolgens op de datum. Een screenshot van vorige week kan laten zien hoe de omgeving toen stond. Het zegt niet vanzelf wat er vandaag is gewijzigd. Andersom hoeft een oudere pakketnaam niet zonder meer te betekenen dat een leverancierspatch ontbreekt. Laat de beheerder het verband tussen pakket en beveiligingsmelding uitleggen.

Kijk ten slotte naar de grens van de conclusie. De uitspraak dat een specifieke fout is verholpen kan goed onderbouwd zijn. De uitspraak dat daarmee alle toekomstige aanvallen onmogelijk zijn, gaat veel verder. Voor je eigen besluit heb je vooral de eerste nodig, plus duidelijke afspraken voor het vervolg.

Deze manier van lezen helpt ook buiten dit incident. Ze maakt je minder afhankelijk van grote beloften en ingewikkeld jargon. Je hoeft niet te weten hoe elk onderdeel is gebouwd om wel te kunnen vragen: wat hebben jullie vastgesteld, waarop is dat gebaseerd en wat gebeurt er als er opnieuw iets verandert?

Een ingevuld voorbeeld van een eigenaarsoverleg

Neem een fictief bedrijf met een brochurewebsite, een aanvraagformulier en een apart klantportaal. De eigenaar vraagt zijn vaste contactpersoon om de situatie te verzamelen. Die contactpersoon legt drie regels vast, één per onderdeel. Het portaal wordt door een andere leverancier beheerd en krijgt daarom een eigen verantwoordelijke in plaats van een gok over de technische toestand.

Het overleg begint met wat bekend is. Voor de website is de gebruikte uitvoeromgeving bevestigd. Voor het formulier is nog onduidelijk welke dienst het verzoek verwerkt. Voor het portaal wacht het team op de leveranciersinformatie. Vervolgens krijgt iedere open vraag een eigenaar. Dat voorkomt dat vijf mensen hetzelfde verzoek sturen terwijl één onderdeel vergeten blijft.

Na de antwoorden volgt een tweede gesprekspunt: wat is er veranderd voor de gebruiker? Het bedrijf laat een testaanvraag uitvoeren en de ontvangst controleren. Het portaal krijgt een afzonderlijke acceptatiecontrole volgens de gemaakte afspraak. Geen van die tests gebruikt vertrouwelijke klantinhoud. De uitkomsten worden bij de juiste regel geplaatst.

Het resultaat van dit voorbeeld is geen groen vinkje voor het hele internet. Het is een begrijpelijk overzicht waarmee de eigenaar weet welke onderdelen zijn beoordeeld en welk werk nog loopt. Juist die bescheiden omvang maakt de status bruikbaar. Een volgende medewerker kan zien waarop de conclusie rustte, zonder eerst een lange chatgeschiedenis te reconstrueren.

Je kunt hetzelfde principe toepassen wanneer je website veel eenvoudiger is. Soms bestaat het overzicht uit één pagina en één contactfunctie. Dan is het gesprek korter, maar de vragen blijven nuttig: wie beheert het, wat is vastgesteld, wat is gedaan en wat is daarna gecontroleerd? Dat is genoeg om gericht verder te werken.

Veelgestelde vragen

Verder met de vraag die bij jou speelt

Voor het praktische gesprek kun je een afspraak plannen. Wil je eerst oriënteren, bekijk onze werkwijze en achtergrond en het prijzenoverzicht. De kennisbank verzamelt uitleg over websites, zichtbaarheid en AI.

Binnen deze reeks vind je ook WordPress-onderhoud, Cloudflare en de achterliggende server en de vragenlijst voor je bureau. Kies de vervolgstap die een open vraag oplost. Je hoeft niet eerst tien artikelen uit te lezen om je beheerder om een concrete status te vragen.