PHP-beveiligingslek: is uw WordPress-website getroffen?

De afgelopen twee dagen stond "PHP" overal in het nieuws. In Nederland waren DigiD en MijnOverheid tijdelijk onbereikbaar. In Finland gingen sommige overheidssites uit voorzorg offline. In de VS riepen de FBI en NSA organisaties op hun servers offline te halen als ze niet kunnen patchen. In Turkije startte het Directoraat Cyberveiligheid van het presidentschap een landelijke scan.

In dit artikel leggen we uit wat er is gebeurd, zonder u te overspoelen met techniek. Daarna lopen we stap voor stap door hoe u als touraanbieder nagaat of uw website getroffen is, wat u vandaag moet doen en hoe u de volgende keer beter voorbereid bent.

Eerst de basis: wat is PHP?

PHP is een programmeertaal die achter de schermen van veel websites draait. Als een bezoeker uw site opent, is de code die de pagina opbouwt, uw contactformulier omzet in een e-mail of een boeking in de database opslaat, heel vaak in PHP geschreven.

Ook als u er nooit van gehoord hebt, gebruikt u het waarschijnlijk ergens. WordPress, WooCommerce, Joomla, Drupal en veel kant-en-klare boekingsplug-ins draaien op PHP. Volgens de FBI gebruikt zo'n 70% van de websites wereldwijd PHP.

Wat is er gebeurd?

Op 20 en 21 oktober 2026 bracht het PHP-team noodupdates uit voor twee kritieke beveiligingslekken. Ze heten CVE-2026-109618 en CVE-2026-109619 en staan samen bekend als "PHP2Shell". Beide kregen een ernstscore van 9,2 op 10.

Waarom dit ernstig is: onder bepaalde omstandigheden kan een aanvaller via internet elke gewenste code op uw server uitvoeren, zonder gebruikersnaam of wachtwoord. In beveiligingstermen heet dat remote code execution (RCE). Simpel gezegd: iemand kan door uw voordeur zonder de sleutel nodig te hebben.

Volgens Qualys ontstaat het ene lek wanneer gegevens half af blijven doordat de server geen geheugen meer heeft, en het andere wanneer na een fout het verzoek van de volgende bezoeker al vrijgegeven geheugen opnieuw leest. Onderzoekers lieten ook zien dat gegevens zoals wachtwoorden, sessie-informatie en API-sleutels uit het servergeheugen kunnen lekken.

Persbureau Anadolu meldt dat de lekken in augustus zijn gevonden door een beveiligingsbedrijf genaamd Calif, met hulp van AI. De oplossingen werden ongeveer twee maanden in stilte voorbereid, maar het nieuws lekte een dag voor de patches uit naar de pers.

Waarom is dit zo groot?

• De schaal is enorm: Palo Alto Networks vond meer dan 22,6 miljoen via internet bereikbare systemen die mogelijk kwetsbaar zijn.
• Oude versies zijn overal: volgens Qualys draait 71% van de PHP-installaties met een bekende versie op versies die niet meer ondersteund worden en geen reguliere patches krijgen.
• De aanvallen zijn begonnen: Cloudflare meldde aanvalsverkeer op deze lekken, en code om ze te misbruiken circuleert al.
• Er wordt traag gepatcht: in de eerste 12 uur waren slechts zo'n 199.000 van de 167 miljoen installaties die Qualys volgt bijgewerkt.

Daarom haalden overheden sites offline. Zolang een systeem niet gepatcht is, is het veiligst om de deur te sluiten waardoor een aanvaller binnen kan komen. In Turkije stuurde het Directoraat Cyberveiligheid dringende meldingen naar overheidsinstellingen en riep het bedrijven op hun PHP-systemen te controleren. Volgens het directoraat zijn er geen problemen gevonden die de diensten van e-Devlet, het nationale overheidsportaal, raken.

Wat kan dit betekenen voor een touraanbieder?

Wat een aanvaller binnen kan doen, hangt af van wat uw website bewaart. De meest waarschijnlijke scenario's:

• Lekken van klantgegevens: namen, telefoonnummers, e-mailadressen en paspoortgegevens uit boekingsformulieren. Afhankelijk van waar u en uw gasten zijn, kan de AVG u verplichten dit te melden.
• Gestolen wachtwoorden en sleutels: uw databasewachtwoord en de API-sleutels van uw betaalprovider, channel manager of e-maildienst.
• Schadelijke inhoud op uw site: verborgen spampagina's of code die bezoekers doorstuurt. Merkt Google dat, dan kan uw site met een waarschuwing verschijnen en kan maandenlang SEO-werk schade lijden.
• Uw server misbruikt voor andere dingen: cryptomining, spam versturen of andere sites aanvallen.
• Gemiste omzet: moet u de site uit voorzorg offline halen, dan kunt u geen boekingen aannemen, zelfs niet in het hoogseizoen.

Is uw website getroffen? Controleer eerst de versie

De eerste stap is uitzoeken of uw website op PHP draait en op welke versie. In WordPress gaat u in het beheer naar Gereedschap → Sitestatus → Informatie → Server. Ook uw hostingpaneel (cPanel, Plesk enz.) toont het meestal onder "PHP-versie".

Dit zijn de versies die de lekken dichten:

• Op PHP 8.5: 8.5.12 of nieuwer
• Op PHP 8.4: 8.4.27 of nieuwer
• Op PHP 8.3: 8.3.36 of nieuwer
• Op PHP 8.2: 8.2.35 of nieuwer
• Op PHP 8.1 of ouder: er komt geen reguliere officiële update. Tenzij uw hostingpartij een speciale patch heeft toegepast, moet u naar een nieuwere versie.

Een kanttekening: sommige Linux-distributies leveren de oplossing met behoud van het oude versienummer. Een lager nummer betekent dus niet altijd dat uw site zeker kwetsbaar is. Daarom is het het betrouwbaarst om het direct aan uw hostingpartij te vragen.

Wat u vandaag moet doen

• Mail uw hostingpartij en vraag: "Is PHP op mijn server bijgewerkt tegen PHP2Shell (CVE-2026-109618 en CVE-2026-109619)?" Het antwoord "We hebben een firewallregel toegevoegd" is op zich niet genoeg. Laat bevestigen dat PHP zelf is bijgewerkt.
• Weet dat een WordPress-update dit niet oplost: het lek zit niet in WordPress, maar in de PHP eronder. Updates van plug-ins of thema's, beveiligingsplug-ins en de onderhoudsmodus beschermen niet, want de aanval kan draaien voordat WordPress zelfs maar laadt.
• Hebt u een eigen server (VPS): werk de PHP-pakketten bij en herstart daarna PHP-FPM of Apache. Een server die niet herstart is, blijft de oude, kwetsbare code draaien. Bij Docker haalt u de nieuwe image op en maakt u de containers opnieuw aan.
• Gebruikt u een oude versie: maak een volledige back-up buiten de server en stap daarna over op PHP 8.3 of 8.4. Test vervolgens één voor één de homepage, tourpagina's, het contactformulier en de boekingsstappen.
• Kunt u niet meteen patchen: uw site achter een firewall zoals Cloudflare zetten geeft tijdelijke bescherming. Hebt u een technisch team, dan kan het de tijdelijke instellingen toepassen die PHP aanbeveelt (bijvoorbeeld session.upload_progress.enabled=0). Dat is geen volledige oplossing, het koopt alleen tijd.

Is er al iemand binnen geweest? Signalen om te controleren

Na het patchen is het verstandig te controleren of iemand binnenkwam voordat het lek gedicht was:

• Zijn er in WordPress beheerdersaccounts die u niet herkent?
• Staat er een plug-in die u niet zelf hebt geïnstalleerd?
• Staan er .php-bestanden in wp-content/uploads, de map met uw afbeeldingen? Daar horen geen PHP-bestanden te staan.
• Ziet u bij de Google-zoekopdracht site:uwdomein.nl pagina's die u nooit hebt geschreven?
• Staat er een waarschuwing onder "Beveiligingsproblemen" in Google Search Console?
• Heeft uw hostingpartij waarschuwingen gestuurd over malware, spam of ongebruikelijk resourcegebruik?

Ziet u een van deze signalen, vraag uw hostingpartij dan de server te scannen en een schone back-up van vóór de verdachte activiteit terug te zetten. Wijzig daarna alle wachtwoorden en API-sleutels: WordPress, hosting, database, e-mail en betaal- of kanaalkoppelingen. Kunnen klantgegevens gelekt zijn, overleg dan met een juridisch adviseur over uw verplichtingen.

Vooruitkijken: blijvende voorzorgsmaatregelen

PHP2Shell zal niet het laatste lek zijn. De echte vraag is hoe goed u de volgende keer voorbereid bent. Deze gewoonten raden we aan:

• Blijf op een ondersteunde versie: software zonder ondersteuning krijgt geen patches. Vandaag is PHP 8.3 of 8.4 een goede keuze.
• Maak iemand verantwoordelijk voor updates: wie werkt uw site bij, en hoe vaak? Daar moet een duidelijk antwoord op zijn. Managed hosting of een onderhoudscontract legt dat eenvoudig vast.
• Weet wat u hebt: uw hoofdsite, oude campagnepagina's, testinstallaties, vergeten subdomeinen… Houd een lijst bij met de server en versie van elk. Aanvallers zijn dol op vergeten sites.
• Verwijder wat u niet nodig hebt: ruim ongebruikte plug-ins, thema's en oude sites op. Elk extra onderdeel is weer een deur die een lek kan openen.
• Zet uw site achter een firewall: een dienst als Cloudflare is uw eerste verdedigingslinie wanneer een nieuw lek bekend wordt, tot u kunt patchen.
• Houd wachtwoorden en sleutels gescheiden: zet API-sleutels niet in de code, geef elke dienst alleen de toegang die nodig is en wissel sleutels regelmatig.
• Bewaar back-ups buiten de server en test het terugzetten: een back-up die nooit is teruggezet, is er een waarvan u niet weet of hij werkt.
• Houd uw site in de gaten: uptime-monitoring, meldingen van Search Console en waarschuwingen bij bestandswijzigingen laten u een probleem zien voordat uw gasten het merken.
• Schrijf een kort incidentplan: bepaal vooraf wie u belt, hoe u de site tijdelijk offline haalt en hoe u klanten informeert als er iets misgaat.

Het grotere plaatje: lekken worden sneller gevonden

Het opvallendste aan dit verhaal is dat de lekken met hulp van AI zijn gevonden. Dezelfde hulpmiddelen zijn ook beschikbaar voor mensen met kwade bedoelingen. Vanaf nu worden lekken sneller gevonden, en ook sneller misbruikt.

Dat betekent dat de tijd van "we updaten wel als we eraan toekomen" voorbij is. Voor een touraanbieder is de website niet meer alleen een etalage. Het is een zakelijk hulpmiddel dat boekingen aanneemt en klantgegevens bewaart, dus de beveiliging ervan hoort bij het draaiende houden van uw bedrijf.

Bij Monotim bouwen we websites op een moderne basis die niet direct geraakt wordt door dit soort lek in een servertaal. Maar geen enkele technologie blijft voor altijd veilig. Het echte verschil zit in de site goed in de gaten houden en snel kunnen handelen als er iets misgaat.

Weet u niet zeker of uw website door PHP2Shell getroffen is, of heeft uw hostingpartij geen duidelijk antwoord gegeven, dan kunnen we er samen naar kijken.