PHP2Shell was voor veel PHP-websites aanleiding voor een dringende beveiligingscontrole. Voor een bedrijf draait het om de afhankelijkheid van een servercomponent waarop de openbare dienst steunt. Een goed thema of vertrouwde plug-ins beschermen niet tegen een kwetsbaarheid in de onderliggende runtime. Stel eerst vast welke omgeving daadwerkelijk actief is. Beslis over een migratie zodra het directe risico is beperkt.
Wat is bevestigd?
PHP publiceerde op 21 oktober 2026 een officieel beveiligingsadvies over CVE-2026-109618 en CVE-2026-109619. Deze kwetsbaarheden kunnen uitvoering van code op afstand zonder authenticatie mogelijk maken. Oplossingen verschenen voor de versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Dit is de stand van zaken op het moment waarop dit artikel is gecontroleerd. Het is geen blijvend advies om precies deze builds te installeren: controleer vóór werkzaamheden de actuele meldingen en pakketten van uw leverancier.
Op 23 oktober volgde een aanvullend PHP-advies over de voortgang van sessie-uploads en een ongebruikelijke combinatie van instellingen voor sessieserialisatie. Alleen de eerste oplossing installeren is dus niet genoeg; lees ook latere adviezen. Ondersteunde distributies kunnen oplossingen terugporteren. Beoordeel daarom de pakketversie samen met de meldingen van de leverancier. De conclusie geldt voor één specifieke server: vergelijkbare versienummers bewijzen niet dat iedere installatie veilig is.
Waarom een WordPress-update niet genoeg is
WordPress is een applicatie die PHP gebruikt. Het CMS en de PHP-interpreter worden op verschillende lagen bijgewerkt. Een actuele WordPress-versie in het dashboard zegt niet of het PHP-pakket op de server veilig is. Vraag de beheerder of hostingprovider welke omgeving productieaanvragen verwerkt, welke oplossing is geïnstalleerd en of de betrokken processen opnieuw zijn gestart. Controleer bij containers of het bijgewerkte image daadwerkelijk draait en niet alleen is gebouwd.
| Wat controleren | Wat de eigenaar nodig heeft |
|---|---|
| Productieomgeving | Bevestigde versie en pakketleverancier |
| Beveiligingsadviezen | Toepasselijke aanbevelingen uitgevoerd |
| Actieve processen | Bevestiging van update in productie |
| Mogelijke inbraak | Gedocumenteerde beoordeling van beschikbaar bewijs |
Eerste stappen zonder paniek
Stel vast wie de infrastructuur beheert en welke diensten geraakt kunnen zijn. Eén domein kan meerdere applicaties bevatten; beheeromgevingen kunnen op andere adressen staan. Laat updates uitvoeren en controleer daarna de belangrijkste functies. Is direct herstel niet mogelijk, bespreek dan met de verantwoordelijke beheerder of publieke toegang tijdelijk beperkt moet worden. Toets eventuele tussenmaatregelen aan officiële adviezen. Reclame voor een beschermingsfilter bewijst niet dat de kwetsbaarheid in de runtime is verholpen.
Bij aanwijzingen voor een inbraak is bijwerken niet het einde van de aanpak. Bewaar beschikbare logs en snapshots, beperk toegang en breng de omvang van het incident in kaart. Controleer inloggegevens waarmee de website is verbonden met e-mail, databases en externe diensten. Vervang sleutels in een vertrouwde omgeving nadat de oorzaak is ingedamd. Het ontbreken van een duidelijk kwaadaardig bestand bewijst niet dat er geen gegevens zijn buitgemaakt.
Wat dit betekent voor het bedrijf
Ook een voorzorgsmaatregel kan aanvragen en verkopen stilleggen. De klantenservice krijgt vragen, betaalde advertenties blijven lopen en medewerkers moeten handmatig werken. Een mogelijke blootstelling van persoonsgegevens vereist een afzonderlijke beoordeling van de gevolgen en toepasselijke verplichtingen. Alleen het gebruik van PHP leidt niet automatisch tot een boete. Leg feiten vast, wijs verantwoordelijkheden toe en volg de juiste besluitvorming. Benoem daarbij wat nog onzeker is.
- Afhankelijkheid van PHP vastgesteld → Adviezen en omgeving controleren
- Adviezen en omgeving controleren → Aanwijzingen voor een inbraak?
- Aanwijzingen voor een inbraak? → Incident indammen en bewijs bewaren (Ja)
- Aanwijzingen voor een inbraak? → Probleem oplossen en werking controleren (Nee)
- Incident indammen en bewijs bewaren → Probleem oplossen en werking controleren
- Probleem oplossen en werking controleren → Nieuwe architectuur plannen
Wanneer een overstap naar een andere stack helpt
Een migratie kan zinvol zijn wanneer het incident structurele problemen blootlegt: een verlaten plug-in blokkeert updates, niemand kent de infrastructuur goed genoeg of herstel is nooit getest. Bij een overstap kunt u de benodigde functies opnieuw vastleggen en de verouderde omgeving buiten gebruik stellen. Ook de nieuwe omgeving vraagt om updates en toegangscontroles. Het doel is een systeem dat beheersbaar blijft.
Bij een contentsite kunnen redactie en publicatie worden gescheiden en kunnen onveranderlijke pagina’s statisch worden aangeboden. De serverlogica van een winkel of dienst met accounts kan naar Go of Node.js verhuizen, met behoud van de overeengekomen functies. Formulieren en integraties moeten goed te volgen zijn. Wijs voor elk onderdeel een verantwoordelijke aan; anders kan de nieuwe stack dezelfde onduidelijkheid en afhankelijkheid van opdrachtnemers opnieuw creëren.
Zo krijgt u een bruikbaar antwoord van uw hostingprovider
Vraag bevestiging voor de specifieke domeinnaam en productieomgeving. Een bruikbaar antwoord vermeldt welke oplossing is toegepast, van welke pakketleverancier die komt en welke dienst nu draait. Een algemene mededeling dat alle klanten beschermd zijn zegt weinig over een extra container of subdomein. Beheert u de server zelf, vraag dan ook of updates bij de dienstverlening zijn inbegrepen: een virtuele machine leveren betekent niet automatisch dat de daarop geïnstalleerde software wordt beheerd.
Bewaar het antwoord en de controledatum bij uw dienstenoverzicht. Delen meerdere opdrachtnemers de verantwoordelijkheid, wijs dan een coördinator aan die de afronding bevestigt. Zo neemt niet iedereen aan dat iemand anders het systeem heeft bijgewerkt. Controleer daarna formulieren, authenticatie en integraties opnieuw en leg de resultaten en verantwoordelijke vast.
De directe reactie en de keuze voor een nieuwe architectuur hebben verschillende afrondingscriteria. U moet kunnen aantonen dat de bijgewerkte omgeving daadwerkelijk bezoekers bedient. Ook moet de migratie de afgesproken legacy-afhankelijkheden aantoonbaar verwijderen. Een nieuw image in een register of een aantrekkelijke preview bewijst geen van beide. Vraag om bevestiging voor de actieve dienst en noteer openstaande vragen, vooral wanneer ontwikkelaar, beheerder en hostingprovider de verantwoordelijkheid delen.
Hoe kan ik hulp aanvragen?
Stuur ons het websiteadres, de hostinggegevens en een beschrijving van de symptomen, maar geen wachtwoorden of persoonsgegevens. We scheiden direct herstel van een latere migratie en bepalen per fase een controleerbaar resultaat. Een eenvoudige, duidelijk afgebakende website kan vanaf drie uur worden gemigreerd; een beoordeeld project kan tot twee dagen duren. Incidentonderzoek en grote infrastructuur vragen om een eigen planning.
Het resultaat moet te controleren zijn: een herstelde omgeving, duidelijke openstaande punten en een afgesproken volgende stap. Een volledige overstap van PHP omvat ook oude interpreters in publieke en achtergrondprocessen. Vergeten beheersites, cron-taken of back-upsubdomeinen kunnen de afhankelijkheid laten bestaan. Daarom beoordelen we bij oplevering de hele omgeving en niet alleen de homepage.
Bronnen
PHP: officiële beveiligingsadviezen uit 2026. The PHP Foundation: beveiligingsrelease van 21 oktober. Gecontroleerd op 26 oktober 2026. Migratieaanpak, voorbeelden, prijzen en leveringsvoorwaarden beschrijven de voorgestelde dienst van het project.
