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 →

Webshop gehackt? IT-beveiliging voor webwinkeliers

Een webshop is kassa, klantenbestand en visitekaartje tegelijk. Wij laten zien wat bij een aanval op PHP-webshops eerst moet gebeuren en wie waarvoor verantwoordelijk is.

Stand 4 min. leestijdSectoren

Kort gezegd: Is uw webshop gehackt of draait hij op een ongepatchte PHP-versie, dan gaat het om drie dingen tegelijk: klantgegevens, de checkout en uw omzet. Zet de webshop gecontroleerd in de onderhoudsmodus, bewaar logs vanaf 20 oktober 2026 en stel vast wie PHP op uw server bijwerkt en herstart.

Wat er in een webshop op het spel staat

Een webshop is meer dan een website. Hij beheert klantaccounts met wachtwoordhashes, lever- en factuuradressen, bestelgeschiedenissen, tegoedbonnen en vaak ook koppelingen met voorraadbeheer, vervoerders en marktplaatsen. Wie code op de server kan uitvoeren, komt doorgaans bij de database en bij de daar opgeslagen API-sleutels.

Kaartgegevens staan meestal niet bij u, maar bij de betaaldienstverlener. Dat stelt maar ten dele gerust: een aanvaller kan JavaScript in het bestelproces inbrengen dat invoer in de browser meeleest. Zulke skimmingscripts vallen in de dagelijkse praktijk nauwelijks op, omdat bestellingen gewoon doorlopen.

Daar komen de koppelingen bij. Een webshop die bestellingen doorgeeft aan voorraadbeheer, vervoerders en marktplaatsen, bewaart de toegangssleutels daarvoor meestal in configuratiebestanden op de server. Wie ze kopieert, kan namens de webwinkelier verzendlabels aanmaken, voorraden wijzigen of marktplaatsaccounts misbruiken.

Gangbare webshopsystemen en waarom PHP2Shell ze treft

De gangbare webshopsystemen in het Europese mkb draaien op PHP: Shopware 6, WooCommerce, Magento, OXID, PrestaShop en veel oudere Shopware 5-installaties. PHP2Shell (CVE-2026-109618 en CVE-2026-109619, elk CVSS 9.2) zit in PHP zelf. Aanvallers hebben geen klantaccount en geen beheerderstoegang nodig.

Voor webwinkeliers betekent dat: de nieuwste webshopupdate beschermt niet. Beslissend is of PHP op de server op 8.5.12, 8.4.27, 8.3.36 of 8.2.35 staat of dat de hostingprovider een backport heeft doorgevoerd, en of daarna alle PHP-processen zijn herstart. Bij oude webshops op PHP 8.1 of ouder zijn er geen officiële updates meer van het PHP-project. Dan komt naast het noodgeval een migratie op u af, die u niet onder tijdsdruk in het hoogseizoen wilt uitvoeren.

Webshop gehackt: wat een incident concreet betekent

Een gecompromitteerde webshop veroorzaakt schade op meerdere niveaus, die elkaar versterken:

  • Omzet: Elk uur onderhoudsmodus kost bestellingen. Een webshop die ongemerkt doordraait, kan echter aanzienlijk duurder uitpakken.
  • Klantgegevens: Weggelekte adressen en bestellingen worden gebruikt voor gerichte phishingmails die echt overkomen, omdat ze echte bestellingen noemen.
  • Zichtbaarheid: Herkent Google schadelijke code, dan verschijnt een waarschuwing in de zoekresultaten. Hoe u die weer kwijtraakt, staat in de gids Google-waarschuwing verwijderen.
  • Partners: Betaaldienstverleners en marktplaatsen hebben eigen voorschriften voor beveiligingsincidenten. Wie te laat meldt, riskeert gedoe bij de afrekening.

Wie is verantwoordelijk: bureau, hostingprovider of webwinkelier?

In veel webshops valt de vraag over PHP tussen wal en schip. Het bureau heeft de webshop gebouwd en onderhoudt plug-ins, de hostingprovider beheert de server en de webwinkelier gaat ervan uit dat een van de twee het oppakt. Bij managed hosting patcht meestal de hostingprovider, bij een eigen vServer doet dat niemand automatisch.

Taak Doorgaans verantwoordelijk Controleer
PHP-pakket bijwerken Hostingprovider of serverbeheerder Schriftelijke bevestiging met pakketstatus
PHP-processen herstarten Wie de server beheert Tijdstip van de herstart
Webshop en plug-ins Bureau Onderhoudscontract en toegangen
Betaaldienstverlener informeren Webwinkelier Contractuele meldplichten
Belangrijk

Een PHP-patch bewijst niet dat er daarvoor niets is gebeurd. Is de webshop aangevallen tussen 17 oktober en het moment van de patch, dan kan ingebrachte code blijven draaien. Laat dat controleren voordat u alles veilig verklaart.

De eerste uren: volgorde voor webwinkeliers

  1. Zet de webshop in de onderhoudsmodus of, als dat niet kan, haal hem tijdelijk van het netwerk.
  2. Zet webserver-, PHP- en webshoplogs vanaf 20 oktober 2026 veilig voordat rotatie ze wist.
  3. Laat bij de hostingprovider de PHP-pakketstatus en de herstart schriftelijk bevestigen.
  4. Vernieuw beheerderswachtwoorden, API-sleutels voor betaling, verzending en marktplaatsen en databasetoegangen, en wel pas na de opschoning.
  5. Controleer checkout, betaal-plug-ins en ingesloten scripts op wijzigingen.

Zijn er aanwijzingen voor een datalek, dan loopt de termijn van 72 uur volgens de AVG. De juridische beoordeling maakt u met uw functionaris voor gegevensbescherming en eventueel uw advocaat.

Hoe helpt PHP SOS concreet?

  • Wij controleren op afstand de werkelijke PHP-pakketstatus, de uitvoeringsmodus (bijvoorbeeld mod_php of PHP-FPM) en of alle workers zijn herstart.
  • Wij onderzoeken webshopbestanden, database en checkout op webshells, skimmingcode en nieuwe beheerdersaccounts en verwijderen gevonden schadelijke software.
  • Wij stemmen af met uw bureau en uw hostingprovider, zodat webshoponderhoud en serverbeheer niet langs elkaar heen lopen.
  • Wij documenteren bevindingen en maatregelen zo dat u ze kunt voorleggen aan betaaldienstverlener, verzekeraar en functionaris voor gegevensbescherming.
  • Daarna beveiligen we de server en nemen op verzoek de doorlopende bewaking over.

Veelgestelde vragen

Moet ik mijn webshop vanwege PHP2Shell offline halen?

Het BSI (de Duitse federale dienst voor informatiebeveiliging) adviseert webservers tijdelijk van het netwerk te halen als de PHP-update niet direct mogelijk is. Voor een webshop is een onderhoudsmodus met informatiepagina vaak een betere weg dan een foutmelding. Zodra PHP is gepatcht en alle processen zijn herstart, kan de webshop weer open.

Lopen creditcardgegevens in mijn webshop gevaar?

In de meeste webshops staan kaartgegevens niet op de eigen server maar bij de betaaldienstverlener. Gevaarlijk is wel gemanipuleerde code in de checkout, die invoer onderschept voordat die de aanbieder bereikt. Daarom hoort de checkout bij elke controle na een aanval.

Is het voldoende om Shopware of WooCommerce bij te werken?

Nee. PHP2Shell treft PHP zelf, niet het webshopsysteem. Een webshopupdate sluit het lek niet, en een PHP-patch verwijdert geen reeds ingebrachte schadelijke code.

Wie moet ik informeren na een datalek?

Bij persoonsgegevens komt een melding aan de toezichthouder voor gegevensbescherming binnen 72 uur in aanmerking, afhankelijk van het risico ook de informatie aan de betrokkenen. Daar komen contractuele verplichtingen jegens betaaldienstverlener en verzekeraar bij. De beoordeling in het concrete geval maakt u met uw functionaris voor gegevensbescherming en een advocaat.

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