Pluginnaam	Herstel Exit Voor WooCommerce
Type kwetsbaarheid	Remote File Inclusion
CVE-nummer	CVE-2026-9662
Urgentie	Kritisch
CVE-publicatiedatum	2026-06-09
Bron-URL	CVE-2026-9662

Remote File Inclusion (RFI) in “Herstel Exit voor WooCommerce” (≤ 1.0.3) — Wat elke site-eigenaar nu moet doen

Een diepgaande, begrijpelijke analyse en stap-voor-stap mitigatiegids voor de Remote/Local File Inclusion kwetsbaarheid (CVE‑2026‑9662) die Recover Exit Voor WooCommerce ≤ 1.0.3 beïnvloedt. Actiegerichte incidentrespons, detectie en versterkingsrichtlijnen van WP‑Firewall.

Auteur: WP-Firewall Beveiligingsteam

Trefwoorden: WordPress, WooCommerce, Kwetsbaarheid, RFI, Beveiliging, WAF, Incidentrespons

Samenvatting: Een kwetsbaarheid voor Remote/Local File Inclusion (RFI/LFI) van hoge ernst (CVE‑2026‑9662) beïnvloedt Recover Exit Voor WooCommerce versies tot en met 1.0.3. Het stelt een niet-geauthenticeerde aanvaller in staat om de server te dwingen om externe of lokale bestanden op te nemen en uit te voeren, wat leidt tot externe code-uitvoering, achterdeurtjes, datadiefstal en volledige sitecompromittering. Als je deze plugin gebruikt, volg dan onmiddellijk de onderstaande richtlijnen.

Waarom dit belangrijk is

Een Remote File Inclusion (RFI) of Local File Inclusion (LFI) kwetsbaarheid is een van de ernstigste soorten kwetsbaarheden die je kunt vinden in een WordPress-plugin. In dit geval is de kwetsbaarheid:

• Beïnvloedt Recover Exit Voor WooCommerce plugin versies ≤ 1.0.3.
• Is uitbuitbaar zonder authenticatie (een niet-geauthenticeerde aanvaller kan de voorwaarde activeren).
• Kan resulteren in externe code-uitvoering (RCE), persistente achterdeurtjes en overname van de site wanneer succesvol uitgebuit.
• Is toegewezen aan CVE‑2026‑9662 en beoordeeld als kritiek in ernst (CVSS 10 in gerapporteerd materiaal), wat betekent dat geautomatiseerde, massale uitbuiting waarschijnlijk is.

Zelfs sites met beperkte traffic kunnen worden gecompromitteerd in geautomatiseerde massale uitbuitcampagnes. Aanvallers gebruiken bots om duizenden sites elke dag te scannen en uit te buiten — dus tijd is cruciaal.

Deze post legt in praktische detail uit wat de kwetsbaarheid is, hoe aanvallers deze misbruiken, hoe je kunt detecteren of je doelwit was, en welke onmiddellijke en langere termijn stappen je moet nemen om je site te beschermen. We sluiten af met een korte opmerking over hoe WP‑Firewall je onmiddellijke mitigatie kan bieden terwijl je opruimt en upgrade.

Technisch overzicht — RFI vs LFI en waarom beide relevant zijn

Bestandsinclusie kwetsbaarheden ontstaan wanneer een applicatie een bestands pad construeert op basis van door de gebruiker aangeleverde invoer en dat pad vervolgens doorgeeft aan functies zoals opnemen, vereisen, include_once, of require_once in PHP zonder voldoende validatie.

• Lokale Bestandsinclusie (LFI) — aanvaller dwingt de applicatie om lokale bestanden van het serverbestandssysteem op te nemen (bijvoorbeeld /etc/passwd, wp-config.php, of een applicatielogboek met inloggegevens). LFI kan leiden tot gegevensonthulling en soms tot externe code-uitvoering door logbestanden te vergiftigen (logvergiftiging) en deze op te nemen.
• Remote File Inclusion (RFI) — aanvaller vertelt de applicatie om een extern bestand op te nemen (bijv., http://attacker.example/shell.txt). Als PHP is geconfigureerd om externe inclusies toe te staan (allow_url_include = Aan), wordt die externe code uitgevoerd in de context van de webservergebruiker.

Belangrijke opmerking: RFI vereist dat bepaalde PHP-serveropties zijn ingeschakeld (allow_url_include). Veel moderne omgevingen hebben dit standaard uitgeschakeld, maar je kunt daar niet op vertrouwen — sommige hosts of oudere PHP-configuraties kunnen onveilige instellingen hebben. Bovendien, als LFI aanwezig is, kunnen aanvallers nog steeds RCE bereiken via logvergiftiging, uploadmisbruik of andere gekoppelde technieken. Omdat de kwetsbaarheid in Recover Exit For WooCommerce niet geverifieerd is en een include-operatie toestaat, is het risico hoog, ongeacht de serverinstellingen.

Hoe een aanvaller deze kwetsbaarheid kan misbruiken (hoog niveau)

Hoewel we geen exploitcode zullen geven, hier is een abstracte stapvolgorde die aanvallers gebruiken:

1. Aanvaller vindt een parameter of eindpunt in de plugin dat een pad of bestandsnaam accepteert (bijvoorbeeld ?file=..., ?template=..., enz.).
2. De plugin gebruikt die parameter in een include/require-operatie zonder deze te saniteren of te beperken.
3. Als de aanvaller een extern URL doorgeeft en de server externe inclusies toestaat (allow_url_include=Aan), wordt het externe bestand opgehaald en uitgevoerd. Dit resulteert in onmiddellijke RCE.
4. Als externe inclusies niet zijn toegestaan, probeert de aanvaller lokale bestands paden (../../../../wp-config.php) of gebruikt logvergiftiging en neemt vervolgens het vergiftigde log op om RCE te bereiken.
5. Zodra de code wordt uitgevoerd, uploadt de aanvaller een persistente backdoor, creëert een admin-gebruiker, wijzigt thema/plugin-bestanden of injecteert kwaadaardige JavaScript in skimmer afrekenpagina's.

Omdat deze kwetsbaarheid niet geverifieerd is en kan worden gecombineerd met typische servermisconfiguraties, moet deze als een noodsituatie worden behandeld.

Onmiddellijke stappen (0–2 uur) — stop de bloeding

Als je een site host die Recover Exit For WooCommerce (≤ 1.0.3) gebruikt, neem dan nu deze onmiddellijke stappen:

1. Zet de site in onderhoudsmodus (verminder blootstelling).
2. Als u niet onmiddellijk kunt patchen:
   • Deactiveer de plugin vanuit het WordPress admin Plugins-scherm.
   • Als je niet kunt deactiveren via admin (vanwege compromittering), hernoem de pluginmap via SFTP/SSH (wp‑content/plugins/recoverexit-for-woocommerce → recoverexit-for-woocommerce.disabled). Dit voorkomt dat de plugin wordt geladen.
3. Maak een volledige back-up (bestanden + database) voordat je verdere wijzigingen aanbrengt. Bewaar deze offline.
4. Als je server snapshots hebt, maak er dan onmiddellijk een.
5. Controleer de toegang logs van de webserver op verdachte verzoeken (zie detectiegedeelte hieronder).
6. Als je een Web Application Firewall (WAF) draait, schakel dan een blokkeringregel in voor patronen die in het detectiegedeelte worden beschreven (we geven later praktische regels).
7. Draai inloggegevens: WordPress admin-accounts, SFTP, hosting controlepaneel, database gebruikerswachtwoorden — vooral als je compromittering vermoedt.
8. Als je kunt, werk PHP bij naar een ondersteunde en veilige versie, en zorg ervoor dat “allow_url_include” is ingesteld op Uit (zie verharding hieronder).

Het onmiddellijk deactiveren of verwijderen van de plugin is de meest betrouwbare noodmaatregel als er nog geen vaste pluginversie beschikbaar is.

Detectie — hoe te vertellen of je het doelwit was of gecompromitteerd

Aanvallers gebruiken zeer luidruchtige scan- en exploitatiepatronen. Controleer deze indicatoren:

– Houd een incidentlog bij van de stappen die je hebt genomen, de tijdstempels en bewijs voor toekomstig forensisch werk.

• Verzoeken die verdachte parameters bevatten die verwijzen naar externe bronnen of inclusief traversiepatronen:
  • Queryparameters die bevatten http://, https://, php://, gegevens:, expect://
  • Waarden die bevatten .., ../, %00 (null byte pogingen), of herhaalde ../ sequenties
  • Verzoeken naar plugin-eindpunten met ongebruikelijke querystrings of POST-lichamen (controleer tijdstempels en IP-adressen)
• Verzoeken van nieuwe of herhaalde IP-adressen die proberen paden op te nemen (grote aantallen 404's voorafgaand aan een succesvolle opname).
• Onverwachte POST-upload naar plugin-eindpunten of admin‑ajax die overeenkomen met de bestandsnamen van de plugin.
• Onverwachte admin-acties van onbekende IP's (inloganomalieën, nieuwe admin-gebruikers).

Bestandsysteem- en applicatie-indicatoren:

• Nieuwe PHP-bestanden of bestanden met abnormale wijzigingstijden in wp‑content, wp‑uploads, en plugin/thema mappen.
• Bestanden met onzinnige variabelenamen of lange base64-blobs; veelvoorkomende webshells bevatten functies zoals eval(), systeem(), shell_exec(), base64_decoderen().
• Wijzigingen in wp-config.php of de creatie van aanvullende configuratiebestanden.
• Nieuwe admin-gebruikers aangemaakt in wp_gebruikers met de rol van administrator.
• Onverwachte geplande taken (cron-jobs) in wp_opties opties zoals cron invoer.
• Gewijzigde themasjablonen, pluginbestanden, of index.php bestanden in uploadmappen.

Database-indicatoren:

• Onverwachte inhoud in de wp_opties tabel, vooral automatisch geladen opties.
• Verdachte inhoud in berichten of widgets (kwaadaardige JS of iframes).
• Onbekende geregistreerde OAuth-clients of API-sleutels opgeslagen in de database.

Geautomatiseerde scans:

• Voer een gerenommeerde malware-scanner uit (bestand en DB-scanning). WP‑Firewall bevat een malware-scanner als onderdeel van zijn beschermingspakket en kan veelvoorkomende backdoors en shell-handtekeningen identificeren.
• Gebruik server-side antivirus of malware-detectie (ClamAV of gelijkwaardig) als tweede mening.

Als een van deze indicatoren aanwezig is, behandel de site dan als gecompromitteerd en volg de onderstaande stappen voor incidentrespons.

Incidentrespons — opruimen en herstel

Als je tekenen van compromittering detecteert, volg dan deze volgorde:

1. Isoleren:
   • Zet de site in onderhouds-/alleen-lezen modus.
   • Haal het, indien mogelijk, offline totdat je containment hebt.
2. Bewijs bewaren:
   • Maak onmiddellijk volledige bestands- en databaseback-ups voor latere forensische analyse.
   • Archiveer webserverlogs (toegang- en foutlogs) en databasewijzigingslogs (indien beschikbaar).
3. Beperk:
   • Verwijder of hernoem de kwetsbare plugin (zie onmiddellijke stappen).
   • Stop alle geplande cron-taken die kwaadaardig lijken.
   • Verwijder webshells en verdachte bestanden alleen nadat je bewijs hebt bewaard of een forensisch plan hebt.
4. Onderzoek:
   • Identificeer de aanvalsvector en lijst gewijzigde of toegevoegde bestanden op.
   • Controleer bestands-tijdstempels voor de vroegste indicator van compromittering.
   • Zoek naar webshell-handtekeningen (evaluatie, preg_replace met /e, base64_decode met lange payloads, systeem/exec gebruik).
5. Schoonmaken:
   • Als de site kleine wijzigingen heeft die je met vertrouwen kunt verwijderen, verwijder dan kwaadaardige bestanden en herstel gewijzigde bestanden vanuit een schone back-up of originele plugin/thema tarballs.
   • Reset WordPress-zouten (in wp-config.php) en roteer alle admin-, gebruikers-, SFTP- en databasewachtwoorden.
   • Verwijder kwaadaardige admin-gebruikers en controleer gebruikersrollen.
   • Herinstalleer de getroffen plugins en thema's vanuit vertrouwde bronnen (gebruik geen gewijzigde pakketten).
6. Herbouwen (indien onzeker):
   • Als je niet met vertrouwen een schone staat kunt garanderen, herbouw dan vanaf een schone back-up die voor de inbreuk is gemaakt.
   • Herinstalleer plugins en thema's vanuit hun officiële repositories of downloads van vertrouwde leveranciers.
7. Verstevigen:
   • Pas de onderstaande verhardings- en preventieaanbevelingen toe.
8. Monitor:
   • Verhoog logging en monitoring. Let op de heroptreden van indicatoren van compromittering.
   • Overweeg periodieke monitoring van de bestandintegriteit (vergelijk bestands-hashes met bekende goede versies).

Verharding & langetermijnmaatregelen

Zelfs na het schoonmaken en verwijderen van de plugin, verhard je site en server om toekomstige risico's te verminderen.

PHP- en serverconfiguratie:

• Schakel uit allow_url_include (php.ini): allow_url_include = Uit.
• Schakel uit allow_url_fopen waar niet vereist: allow_url_fopen = Uit (dit voorkomt veel externe bestandophalingen via bestandsfuncties).
• Voer de nieuwste ondersteunde PHP-versie uit (beveiligingsfixes zijn belangrijk).
• Gebruik bestandspermissies met de minste privileges: bestanden 644, mappen 755 (vermijd 777).
• Verhard SSH- en SFTP-toegang (sleutelgebaseerde authenticatie, schakel wachtwoord SSH uit indien mogelijk).

WordPress-niveau:

• Houd de WordPress-kern, plugins en thema's up-to-date.
• Verwijder ongebruikte plugins en thema's — ongebruikte code is een aanvalsvlak.
• Schakel de bestandseditor uit: voeg toe define('DISALLOW_FILE_EDIT', true); naar wp-config.php.
• Schakel installatie van plugins en thema's uit als deze door anderen worden beheerd of als dit niet nodig is: define('DISALLOW_FILE_MODS', true); maar alleen in onderhoudsscenario's en wanneer je een beheerd updateproces hebt.
• Gebruik sterke, unieke wachtwoorden en schakel tweefactorauthenticatie (2FA) in voor admin-accounts.

Bescherming van bestanden en uploads:

Dien uploads aan via X-Content-Type-opties en voorkom PHP-uitvoering in uploads:

# wp-content/uploads/.htaccess

Voor nginx, voeg toe:

locatie ~* /wp-content/uploads/.*\.(php|phtml|php3|php4|php5|phps)$ {

WAF & verzoekfiltering:

• Implementeer een WAF die virtuele patching en aangepaste regels ondersteunt om exploitatiepogingen te blokkeren (zie volgende sectie voor voorbeeldregels).
• Blokkeer verzoeken die verdachte include-patronen bevatten.

Logging & monitoring:

• Implementeer bestandsintegriteitsmonitoring (FIM).
• Schakel logging in en bewaar logs gedurende ten minste 30 dagen.
• Houd toezicht op nieuwe admin-gebruikers, onverwachte geplande taken en gewijzigde bestanden.

Back-ups:

• Onderhoud regelmatige versleutelde back-ups en houd ze offsite.
• Valideer back-ups (hersteltests) periodiek.

Praktische detectie- en WAF (virtuele patching) regels

Hieronder staan veilige, praktische regelideeën om exploitatiepogingen op het webserver/WAF-niveau te blokkeren. Deze zijn bedoeld voor snelle mitigatie en vervangen niet het patchen of verwijderen van de kwetsbare plugin.

Opmerking: test regels eerst op een staging-site om valse positieven te vermijden.

1. Blokkeer verzoeken die externe wrappers in querystrings of POST-lichamen bevatten:

ModSecurity (voorbeeld):

SecRule ARGS|REQUEST_BODY "@rx (?:php://|data:|expect:|ssh2://|tcp://|dict://|ftp://|sftp://|http://|https://)" \n  "id:100001,phase:2,deny,log,status:403,msg:'Blokkeerde verdachte wrapper in verzoek - mogelijke RFI-poging',severity:2"

Nginx (basis, gebruik makend van map + if — test zorgvuldig):

als ($query_string ~* "(php://|data:|http://|https://|expect:)") {

2. Blokkeer directory traversal-sequenties en null byte-pogingen:

ModSecurity:

SecRule ARGS|REQUEST_URI "@rx \.\./|\\/|\x00" \n "id:100002,phase:2,deny,log,status:403,msg:'Blocked directory traversal or null byte in request',severity:2"

3. Blokkeer verdachte parameter namen die vaak worden gebruikt voor include-paden (als je ze in je logs identificeert):

Generiek voorbeeld: als er een opnameparameter met de naam bestand, pad, sjabloon, overweeg dan om te blokkeren of te valideren:

SecRule ARGS:file|ARGS:path|ARGS:template "@rx .*" \n  "id:100003,phase:2,pass,log,ctl:ruleEngine=DetectOnly,msg:'Monitor inclusie-achtige parameter'"

4. Blokkeer bekende payload-leveringspatronen (base64 blobs, eval+base64_decode combinaties):

SecRule ARGS|REQUEST_BODY "@rx (base64_decode\(|eval\(|assert\(|preg_replace\(.+e')" \n  "id:100005,phase:2,deny,log,status:403,msg:'Geblokkeerde aanvalspayloadpatronen'"

Deze regels zijn defensief en bedoeld om veelvoorkomende exploit-payloads en gedrag te blokkeren. Ze zijn geen vervanging voor het verwijderen van de kwetsbare plugin.

Hoe logs te doorzoeken naar bewijs (Sysadmin snelle commando's)

Voorbeeldcommando's voor veelvoorkomende serverconfiguraties. Pas paden aan om overeen te komen met jouw omgeving.

• Zoek toeganglogs naar verzoeken die bevatten php:// / gegevens: / externe URL-indicatoren:

grep -Ei "php://|data:|http://|https://" /var/log/apache2/*access*.log

• Vind verzoeken met directory traversal:

grep -Ei "\.\./|" /var/log/nginx/*access*.log

• Zoek naar verzoeken naar de map van de plugin:

grep -i "recoverexit-for-woocommerce" /var/log/*/*access*.log

• Vind recent gewijzigde PHP-bestanden (laatste 7 dagen):

find /var/www/html -type f -mtime -7 -name '*.php' -ls

• Identificeer nieuw aangemaakte bestanden in wp-content/uploads:

find /var/www/html/wp-content/uploads -type f -mtime -7 -ls

FAQ's en veelvoorkomende zorgen

Q: Mijn host zegt dat exploit vereist dat allow_url_include is ingeschakeld, dus ik ben veilig.

A: Niet noodzakelijk. Zelfs wanneer allow_url_include is uitgeschakeld, kunnen lokale bestandinclusie of logvervuiling chaining technieken nog steeds leiden tot code-executie. Behandel de plugin als kwetsbaar en verwijder of deactiveer deze totdat deze is opgelost.

Q: Er is nog geen officiële patch — moet ik wachten?

A: Nee. Als er geen patch beschikbaar is, verwijder/deactiveer dan de plugin of implementeer onmiddellijk robuuste WAF-blokken en serververharding. Het actief laten is riskant.

Q: Kan ik de pluginmap eenvoudig hernoemen?

A: Ja — het hernoemen van de pluginmap (bijv. “.disabled” toevoegen) voorkomt dat WordPress deze laadt. Dit is een veilige noodmaatregel als je niet kunt deactiveren vanuit wp-admin.

Q: Zal het verwijderen van de plugin het gedrag van de WooCommerce-afrekenpagina verstoren?

A: Mogelijk. Test in een staging-omgeving. Als de plugin essentieel is, raadpleeg dan de plugin-auteur of zoek een veilige, onderhouden alternatieve oplossing. Op de korte termijn is preventieve verwijdering veiliger dan een mogelijke compromittering.

Preventieve beveiligingschecklist (uitvoerbaar)

• Identificeer alle sites die Recover Exit For WooCommerce gebruiken en neem ze offline of deactiveer de plugin.
• Als de plugin actief is, deactiveer of hernoem dan onmiddellijk de pluginmap.
• Maak een back-up van bestanden en database, archiveer logs.
• Scan op indicatoren van compromittering (bestanden, nieuwe gebruikers, geplande taken).
• Draai alle inloggegevens (WP admin, DB, SFTP, hosting controlepaneel) om.
• Pas serververharding toe (schakel allow_url_include uit, schakel allow_url_fopen uit waar mogelijk).
• Implementeer WAF-regels (virtuele patching) en monitoring.
• Verwijder alle kwaadaardige bestanden of overweeg een volledige reconstructie vanaf een back-up vóór de compromittering.
• Houd 30+ dagen toezicht op het opnieuw verschijnen van kwaadaardige patronen.
• Houd WP-kern, thema's en plugins up-to-date; verwijder ongebruikte items.

Hoe WP-Firewall helpt (praktische waarde)

Bij WP-Firewall bieden we gelaagde bescherming die onmiddellijk kan worden toegepast terwijl je door het opruimproces werkt:

• Beheerde firewallregels die snel kunnen worden ingezet om RFI/LFI-pogingen en verdachte wrappers (php://, data:, http/https) te blokkeren.
• Virtuele patching: regels die specifiek zijn ontworpen om bekende plugin-kwulnerabiliteiten te mitigeren terwijl je wacht op een officiële oplossing of totdat je de plugin veilig kunt verwijderen.
• Malware-scanning om achterdeurtjes, geïnjecteerde code en webshells die door aanvallers zijn achtergelaten te detecteren.
• Continue monitoring om te letten op heroptredens van aanvalspatronen en verdachte admin-activiteit.
• Richtlijnen en herstelwerkstromen op maat voor WordPress/WooCommerce-omgevingen.

Een firewall/WAF is geen vervanging voor patching, maar met niet-geauthenticeerde kwetsbaarheden van hoge ernst is het vaak de snelste manier om grootschalige exploitatie te voorkomen.

---

Bescherm je site nu — Begin met het WP‑Firewall Gratis Plan

Als je onmiddellijke, geautomatiseerde bescherming wilt terwijl je dit probleem evalueert en herstelt, overweeg dan om te beginnen met het gratis plan van WP-Firewall. Het biedt essentiële bescherming zonder kosten en kan in enkele minuten worden ingesteld:

• Basis (gratis): Essentiële bescherming — beheerde firewall, onbeperkte bandbreedte, WAF, malware-scanner en mitigatie voor OWASP Top 10-risico's.
• Standaard ($50/jaar): Voegt automatische malwareverwijdering toe en de mogelijkheid om tot 20 IP's op de zwarte/witte lijst te zetten.
• Pro ($299/jaar): Voegt maandelijkse beveiligingsrapporten, automatische kwetsbaarheid virtuele patching en premium add-ons zoals een Dedicated Account Manager en Managed Security Service toe.

Begin hier met het gratis plan: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Dit stelt je in staat om exploitatiepogingen onmiddellijk te blokkeren, malware te scannen en je site te stabiliseren terwijl je de volledige opruiming uitvoert. Meld je aan en activeer basisbescherming — je hebt een tastbare verdedigingslaag tegen geautomatiseerde exploitcampagnes.

---

Aanbevolen langetermijnstrategie voor site-eigenaren en bureaus

1. Voorraad en prioriteren: Ken elke plugin en thema op elke site die je beheert. Geef prioriteit aan het verwijderen of vervangen van plugins die niet worden onderhouden of zelden worden bijgewerkt.
2. Centraliseer updates: gebruik een beheerd updateproces of staging-omgeving om updates te testen voordat je ze naar productie duwt.
3. Verdediging in de diepte: combineer sterke platformverharding, een WAF met virtuele patching-capaciteit, veilige hosting en monitoring/waarschuwing.
4. Regelmatige audit en pentest: ten minste jaarlijkse audits voor drukbezochte e-commerce sites, met periodieke gerichte pentests na grote wijzigingen.
5. Incidentenhandleiding: heb een vooraf geschreven incidentresponsplan en test het periodiek met tabletop-oefeningen.

Laatste opmerkingen — behandel niet-geauthenticeerde kwetsbaarheden van hoge ernst als noodgevallen

Niet-geauthenticeerde RFI/LFI-kwetsbaarheden zijn extreem gevaarlijk. Zelfs als je omgeving momenteel niet in een “risicovolle” PHP-configuratie verkeert, blijft het aanvalsvlak bestaan omdat aanvallers meerdere technieken aan elkaar koppelen. Verwijder of deactiveer kwetsbare plugins onmiddellijk, beveilig en patch je serverinstellingen, en gebruik een WAF om virtuele patching te bieden terwijl je herstelt.

Als je praktische hulp nodig hebt bij het opruimen van een gecompromitteerde site, het uitvoeren van forensisch onderzoek of het implementeren van virtuele patches en monitoring, kan het team van WP-Firewall je helpen om je WordPress/WooCommerce-omgeving snel te stabiliseren en te verhardingen.

Blijf veilig, houd back-ups actueel en behandel verdachte indicatoren onmiddellijk — hoe sneller je handelt, hoe lager je schade en herstelkosten.