Kort gezegd: Bij een PHP-beveiligingslek zoals PHP2Shell is bij webhosting de hostingprovider verantwoordelijk voor de PHP-update, niet u. Uw taak is een schriftelijke bevestiging op te vragen, in het klantmenu een ondersteunde PHP-versie te kiezen en uw website op sporen van een aanval te controleren. Een patch van de hostingprovider verwijdert geen schadelijke software die eerder op uw website is beland.
De situatie in eenvoudige woorden
PHP is de programmeertaal waarmee de meeste websites, webwinkels en CMS'en zoals WordPress draaien. PHP2Shell staat voor twee kritieke fouten in PHP zelf (CVE-2026-109618 en CVE-2026-109619). Aanvallers kunnen daarmee zonder wachtwoord eigen code op de server uitvoeren. Het BSI (de Duitse federale dienst voor informatiebeveiliging) heeft waarschuwingsniveau 3 (oranje) afgekondigd en adviseert een onmiddellijke update.
Bij shared hosting delen veel klanten één server. De techniek eronder, dus besturingssysteem, webserver en PHP, wordt beheerd door de hostingprovider. U beheert zelf alleen uw website, database en toegangen. Daarom kunt u de PHP-update niet zelf doorvoeren en hoeft dat ook niet.
Webhosting en PHP-beveiligingslek: wie is waarvoor verantwoordelijk?
De verdeling volgt uit uw contract. In de meeste abonnementen geldt ruwweg de volgende verdeling:
| Taak | Hostingprovider | U als klant |
|---|---|---|
| PHP-pakketten bijwerken | ja | nee |
| PHP-processen herstarten | ja | nee |
| Serverbrede overbruggingswaarden instellen | ja | nee |
| PHP-versie van uw website kiezen | biedt aan | kiest |
| CMS, plug-ins, thema's bijwerken | nee | ja |
| Toegangsgegevens en beheerdersaccounts | nee | ja |
| Website op schadelijke code controleren | gedeeltelijk | ja |
| Beoordeling vanuit de gegevensbescherming | nee | ja |
Belangrijk is de laatste regel: komt het op uw website tot een incident met persoonsgegevens, dan bent in de regel u als exploitant verantwoordelijk, niet de hostingprovider. Meer daarover onder Meldplicht AVG.
Wat u nu zelf moet doen
1. Bevestiging opvragen. Vraag uw hostingprovider schriftelijk of de PHP-versies in uw pakket tegen beide CVE's zijn beveiligd, sinds wanneer, en of alle PHP-processen zijn herstart. Een kant-en-klaar sjabloon vindt u onder Hostingprovider naar de patchstatus vragen. Wees niet verbaasd als in het klantmenu nog een oudere versie zoals 8.2.34 staat: sommige aanbieders leveren correcties als backport, zonder dat het nummer wijzigt.
2. PHP-versie controleren. Kijk in het klantmenu welke PHP-versie uw website gebruikt. PHP 8.1 en ouder krijgen van het PHP-project geen officiële updates meer. PHP 8.2 bereikt op 31-12-2026 het einde van de ondersteuning. Of uw CMS een nieuwere versie aankan, controleert u aan de hand van de systeemvereisten van de fabrikant, bijvoorbeeld op wordpress.org.
3. Website controleren. Let op onbekende beheerdersaccounts, onverwachte doorverwijzingen, vreemde bestanden in de FTP-toegang en waarschuwingen in Google Search Console. Een lijst met typische signalen vindt u onder Ben ik al gecompromitteerd?.
4. Back-up maken. Download een actuele back-up van bestanden en database en bewaar die gescheiden. Vraag de hostingprovider bovendien de toegangslogs van uw pakket vanaf 20-10-2026 te bewaren.
Wijzig na de bevestiging van de hostingprovider preventief de wachtwoorden voor klantmenu, FTP/SFTP, database en CMS-beheerders en activeer waar mogelijk tweefactorauthenticatie.
Wat u bij shared hosting niet zelf kunt oplossen
De door php.net aanbevolen overbruggingsmaatregelen, zoals session.upload_progress.enabled=0, werken alleen als ze in de serverconfiguratie worden ingesteld. Een vermelding in .user.ini of via ini_set() in de code volstaat volgens php.net niet. Ook geheugengrenzen op cgroup-niveau en de herstart van de PHP-processen liggen bij de hostingprovider.
Reageert uw hostingprovider niet of ontwijkend, dan hebt u drie mogelijkheden: natrekken en een termijn stellen, de website tijdelijk in onderhoudsmodus zetten of overstappen naar een aanbieder met een duidelijke verklaring. Het BSI adviseert webservers tijdelijk van het net te halen als een update niet meteen mogelijk is.
Controleer bovendien of uw abonnement nog actueel is. Pakketten die al jaren ongewijzigd draaien, staan soms op oudere servergeneraties met oudere PHP-versies die de hostingprovider nog maar beperkt onderhoudt. Een overstap naar een actueel abonnement van dezelfde aanbieder kost vaak weinig moeite en brengt nieuwere PHP-versies mee. Vraag ernaar als het antwoord over de patchstatus onbevredigend uitvalt.
Als de website al opvalt
Een patch bij de hostingprovider sluit de kwetsbaarheid voor de toekomst. Hij verwijdert echter geen achterdeur die aanvallers eerder hebben ingebouwd en bewijst niet dat er daarvoor niets is gebeurd. Vindt u opvallende zaken, verwijder dan niet lukraak bestanden. Leg eerst de toestand vast, zodat de oorzaak later te achterhalen blijft.
Hoe helpt PHP SOS concreet?
- Wij formuleren samen met u de vraag aan de hostingprovider en beoordelen het antwoord technisch.
- Wij controleren uw website op webshells, vreemde accounts en gemanipuleerde bestanden en ruimen ze bij een bevinding op via onze verwijdering van malware.
- Bij acuut vermoeden nemen we de noodhulp voor gehackte websites over, inclusief bewijsveiligstelling.
- Wij helpen bij de keuze van een passende PHP-versie en testen de website daarna.
Veelgestelde vragen
Moet ik als hostingklant PHP zelf bijwerken?
In de regel niet, want PHP is bij shared hosting onderdeel van het platform van de hostingprovider. U kunt in het klantmenu vaak wel de PHP-versie kiezen. Staat daar een versie zonder officiële updates, schakel dan over of vraag de hostingprovider hoe die wordt beveiligd.
Mijn website is offline. Ben ik gehackt?
Niet per se. Sommige aanbieders hebben websites preventief van het net gehaald om de kwetsbaarheid te sluiten. Vraag de hostingprovider naar de reden en laat bevestigen of er aanwijzingen zijn voor een aanval op uw pakket.
Kan ik de overbruggingsmaatregelen zelf in .user.ini instellen?
Voor session.upload_progress.enabled vermeldt php.net uitdrukkelijk dat .user.ini en ini_set() niet volstaan. Deze instelling moet de hostingprovider in de serverconfiguratie aanbrengen.
Wat moet ik schriftelijk van de hostingprovider hebben?
Een bevestiging dat de PHP-versies van uw pakket zijn beveiligd tegen CVE-2026-109618 en CVE-2026-109619, vanaf wanneer dat geldt en dat de PHP-processen zijn herstart. Bewaar dit antwoord bij uw documenten.