Actuele situatie: PHP2Shell. Twee kritieke PHP-kwetsbaarheden (CVSS 9.2) maken schadelijke code zonder inloggen mogelijk. Patches sinds 21-10-2026.Wat u nu moet doen →

PHP2Shell: 15 vragen van hostingklanten

Staat uw website bij een hostingprovider en wilt u weten wat u bij PHP2Shell zelf moet doen? Hier de 15 meest gestelde vragen met korte antwoorden.

Stand 5 min. leestijdSituatie en duiding

Kort gezegd: Wat te doen als hostingklant bij het PHP-lek PHP2Shell? De PHP-update hoeft u meestal niet zelf in te spelen, dat doet bij shared hosting de hostingprovider. Uw taken zijn andere: een schriftelijke bevestiging van de patchstatus opvragen, in het klantenmenu een ondersteunde PHP-versie kiezen en uw website op bijzonderheden controleren. De 15 meest gestelde vragen daarover beantwoordt deze bijdrage kort en op volgorde.

PHP-lek als hostingklant: ben ik getroffen, wat te doen?

Sinds 21 oktober 2026 krijgen wij veel vragen van bedrijven wier website bij een hostingprovider staat. De meeste draaien om dezelfde punten. Wie de verantwoordelijkheden uitgebreider wil nalezen, vindt ze onder Shared hosting: wat de hostingprovider doet en wat u moet doen.

1. Is mijn website eigenlijk getroffen?

Als uw website draait met WordPress, Shopware, TYPO3, Joomla, Contao of een ander PHP-systeem, is de server eronder mogelijk getroffen. Pure HTML-pagina's zonder PHP zijn dat niet. In geval van twijfel helpt een blik in het klantenmenu: is daar een instelling voor de PHP-versie, dan gebruikt u PHP.

2. Wat is het verschil tussen shared hosting en een eigen server?

Bij shared hosting deelt u een door de hostingprovider beheerde server met andere klanten; de hostingprovider onderhoudt PHP. Bij een eigen rootserver of vServer bent u zelf verantwoordelijk. Bij een managed server regelt het contract wie updates inspeelt.

3. Mijn hostingprovider heeft een rondmail gestuurd. Moet ik nog iets doen?

Lees nauwkeurig wat erin staat. Een rondmail bevestigt vaak alleen dat de hostingprovider „aan het onderwerp werkt”. U hebt een uitspraak over uw pakket nodig: PHP-tak, patchstatus, tijdstip en herstart.

Verantwoordelijkheid en update

4. Speelt de hostingprovider de update automatisch in?

In de regel wel, voor de PHP-versies die hij op zijn servers aanbiedt. Of dat al is gebeurd en of ook oudere versies zijn gedekt, verschilt per hostingprovider. Vraag het na.

5. Mijn klantenmenu toont een oud versienummer. Ben ik onbeschermd?

Niet per se. Veel hostingproviders bouwen correcties als backport in, het nummer blijft dan gelijk. Plesk kan bijvoorbeeld nog steeds 8.2.34 tonen, hoewel de fout is verholpen. Doorslaggevend is de bevestiging van de hostingprovider.

6. Ik gebruik nog PHP 7.4 of 8.1. Wat nu?

Deze takken krijgen van het PHP-project geen officiële updates meer. Sommige hostingproviders leveren eigen correcties, andere niet. Regel dat schriftelijk en plan de overstap naar een ondersteunde tak. Controleer vooraf in de systeemvereisten van uw CMS welke PHP-versies het ondersteunt.

7. Kan ik de PHP-versie zelf omzetten?

Bij de meeste hostingproviders wel, in het klantenmenu. Hoe dat gaat en waar u vooraf op moet letten, beschrijft de bijdrage PHP-versie wijzigen in het klantenmenu van de hosting. Maak vooraf een back-up.

8. Helpt het WordPress of plug-ins bij te werken?

Tegen PHP2Shell niet, want het lek zit in PHP. CMS-updates zijn toch zinvol, omdat ze andere lekken dichten.

Controleren en aantonen

9. Hoe krijg ik een bewijs van de hostingprovider?

Met een schriftelijk verzoek dat concrete gegevens vraagt: pakketstatus per PHP-tak, datum van installatie, herstart van alle PHP-processen. Een sjabloon om te kopiëren biedt de gids PHP-updatebevestiging van de hostingprovider opvragen.

10. Kan ik tussentijdse maatregelen via .user.ini instellen?

Nee. php.net raadt uitdrukkelijk af de tussentijdse instellingen via ini_set() of .user.ini te zetten. Ze horen in de serverconfiguratie, en die beheert bij shared hosting de hostingprovider.

11. Mijn website was kort offline. Ben ik gehackt?

Niet noodzakelijk. Sommige hostingproviders hebben websites preventief uitgeschakeld of servers herstart. Vraag naar de reden voordat u conclusies trekt.

12. Waaraan herken ik dat mijn website is aangevallen?

Mogelijke aanwijzingen zijn onbekende beheerdersaccounts, nieuwe PHP-bestanden in de uploadmap, doorverwijzingen naar andere sites, vreemde pagina's in de Google-index of waarschuwingen in de Search Console. Vraag de hostingprovider toegangslogs vanaf 20 oktober te bewaren.

Als er iets niet klopt

13. De hostingprovider antwoordt niet of ontwijkend. Wat te doen?

Vraag schriftelijk na en stel een redelijke termijn. Blijft het antwoord uit, behandel de server dan als ongecontroleerd en overweeg de website tijdelijk om te zetten naar een statische noodpagina.

14. Moet ik van hostingprovider wisselen?

Een overstap midden in de situatie schept eigen risico's. Zinvol is hij als de hostingprovider blijvend geen informatie geeft of oude PHP-versies zonder correctie blijft draaien. Waar u dan op moet letten, beschrijft Van hostingprovider wisselen na een incident.

15. Moet ik iets melden?

Als er aanwijzingen zijn voor een aanval en persoonsgegevens getroffen kunnen zijn, kan er een meldplicht volgens de AVG bestaan, in de regel binnen 72 uur. Bespreek dat met uw functionaris voor gegevensbescherming of een advocaat. Dit is geen juridisch advies.

Uw korte controlelijst

  1. Hostingprovider schriftelijk vragen naar patchstatus en herstart.
  2. PHP-versie in het klantenmenu controleren, verouderde takken vervangen.
  3. Beheerdersaccounts en uploadmap doorlopen.
  4. Search Console op waarschuwingen controleren.
  5. Bij bijzonderheden hulp zoeken voordat u bestanden verwijdert.

Hoe helpt PHP SOS concreet?

  • Afstemming met de hostingprovider: Wij formuleren het verzoek of voeren het gesprek en beoordelen het antwoord.
  • Controle van de website: Wij zoeken naar sporen in bestanden, database en accounts, voor zover het hostingpakket dat toelaat.
  • Opschoning: Vinden wij schadelijke code, dan verwijderen wij die en vervangen alle toegangen.
  • Documentatie: U ontvangt de stand schriftelijk.

Bij een concreet vermoeden helpt de noodhulp bij gehackte websites.

Conclusie

Als hostingklant draagt u bij PHP2Shell niet de last van de update, maar wel de verantwoordelijkheid voor uw website. De meeste vragen zijn af te handelen met een duidelijk schriftelijk antwoord van uw hostingprovider. Wat daarna rest, is de blik op de eigen website: accounts, bestanden, Google-meldingen. Wie beide heeft gedaan, heeft zijn deel gedaan en kan zo nodig aantonen dat hij zorgvuldig heeft gehandeld.

Veelgestelde vragen

Wie is bij webhosting verantwoordelijk voor de PHP-update?

Bij shared hosting in de regel de hostingprovider, want die beheert de server en de PHP-installatie. U bent verantwoordelijk voor uw website, uw toegangen en de keuze van de PHP-versie in het klantenmenu. Bij managed servers regelt het contract de verdeling.

Waarom toont mijn hostingprovider een oude PHP-versie?

Veel hostingproviders en distributies bouwen de correctie als backport in de bestaande versie in. Het nummer blijft dan gelijk, hoewel het lek is gedicht. Vertrouw daarom op een schriftelijke bevestiging van de hostingprovider, niet op de weergave.

Wat kan ik als hostingklant zelf controleren?

U kunt de ingestelde PHP-versie in het klantenmenu controleren, de beheerdersaccounts van uw CMS doorlopen, zoeken naar onbekende bestanden in de uploadmap en de Search Console op waarschuwingen controleren. De patchstatus van de server zelf kan alleen de hostingprovider aantonen.

Helpt een firewall-instelling in het hostingpakket?

Firewallregels van de hostingprovider of van een voorgeschakelde dienst kunnen het risico verlagen. Ze vervangen de PHP-update op de server echter niet. Vraag daarom altijd eerst naar de update.

Bronnen

Direct contact

Elk uur telt. Schrijf ons nu.

Beschrijf kort het systeem, de PHP-versie en wat u opmerkt. Wij nemen contact op, brengen de situatie in kaart en werken op afstand tot het incident is afgerond en gedocumenteerd.

Directe hulp