Pluginnaam	WordPress ManageWP Worker-plugin
Type kwetsbaarheid	XSS (Cross-Site Scripting)
CVE-nummer	CVE-2026-3718
Urgentie	Medium
CVE-publicatiedatum	2026-05-17
Bron-URL	CVE-2026-3718

Niet-geauthenticeerde opgeslagen XSS in ManageWP Worker (<= 4.9.31) — Wat WordPress-eigenaren nu moeten doen

Datum: 2026-05-15
Auteur: WP-Firewall Beveiligingsteam

Samenvatting: Een opgeslagen Cross-Site Scripting (XSS) kwetsbaarheid die de ManageWP Worker-plugin (versies <= 4.9.31, CVE-2026-3718) beïnvloedt, werd op 14 mei 2026 openbaar gemaakt en gepatcht in versie 4.9.32. Dit is een niet-geauthenticeerde kwetsbaarheid die een aanvaller in staat kan stellen om kwaadaardige HTML/JavaScript in te voegen die wordt uitgevoerd wanneer een administratieve of andere bevoegde gebruiker interactie heeft met de getroffen site. In deze post leggen we het risico uit, hoe het probleem op hoog niveau werkt, onmiddellijke stappen om uw site te beschermen, detectie- en opruimingsrichtlijnen, en langetermijnversterkingspraktijken. We schetsen ook hoe WP-Firewall helpt om uw WordPress-sites te mitigeren en te beschermen terwijl u patcht.

---

Inhoudsopgave

• Achtergrond en waarom dit belangrijk is
• Technisch overzicht (wat “niet-geauthenticeerde opgeslagen XSS” hier betekent)
• Impact in de echte wereld en aanvalscenario's
• Onmiddellijke acties (wat u nu moet doen)
• Detectie: hoe bewijs van exploitatie te vinden
• Incidentrespons en schoonmaak checklist
• Preventieve maatregelen en versterking voor de lange termijn
• Hoe WP-Firewall helpt tijdens en na een incident
• Begin met WP-Firewall Gratis Plan — onmiddellijke basisbescherming
• Slotopmerkingen en bronnen

---

Achtergrond en waarom dit belangrijk is

Op 14 mei 2026 werd gerapporteerd dat de ManageWP Worker-plugin een opgeslagen XSS-kwetsbaarheid (CVE-2026-3718) bevatte die versies tot en met 4.9.31 beïnvloedde. De pluginleverancier heeft een patch uitgebracht in versie 4.9.32. De kwetsbaarheid kreeg een gemiddelde ernst (CVSS 7.1) en wordt beschreven als een niet-geauthenticeerd opgeslagen cross-site scripting probleem.

Waarom site-eigenaren en beheerders zich zorgen moeten maken:

• Opgeslagen XSS stelt een aanvaller in staat om kwaadaardige scripts in te voegen die op de site blijven en worden uitgevoerd wanneer ze door andere gebruikers worden bekeken — meestal beheerders of redacteuren. Dit kan leiden tot overname van accounts, site-defacing, persistente malware-injectie of verlies van controle over uw site.
• De kwetsbaarheid is “niet-geauthenticeerd” vanuit het perspectief van de aanvaller, wat betekent dat ze de injectie kunnen activeren zonder in te loggen. Als er UI-weergaven zijn die door de aanvaller gecontroleerde inhoud aan beheerders of bevoegde gebruikers tonen, wordt het bijzonder riskant.
• Zelfs bugs van gemiddelde ernst kunnen snel worden gewapend in massale exploitatiecampagnes wanneer automatisering en scannen worden gebruikt, dus snelle actie is essentieel.

Deze post is geschreven vanuit het perspectief van een WordPress-beveiligingsteam bij WP-Firewall: praktisch, geprioriteerd en actiegericht.

---

Technisch overzicht: wat “niet-geauthenticeerde opgeslagen XSS” hier betekent

Laten we de zin ontleden:

• Niet-geverifieerd: De aanvaller heeft geen geldige inloggegevens nodig om de payload te leveren. Ze kunnen HTTP-verzoeken doen tegen eindpunten die invoer accepteren en opslaan.
• Opgeslagen XSS (persistent): De kwaadaardige payload wordt opgeslagen op de doelwebsite (database, opties tabel, postinhoud, plugininstellingen, opmerkingen, enz.). Het zal later worden aangeboden aan gebruikers of beheerders die de relevante pagina bekijken.
• Trigger: Voor deze specifieke kwetsbaarheid vereist exploitatie doorgaans een menselijke interactie ergens in het proces — bijvoorbeeld, een beheerder die een pagina bekijkt of op een zorgvuldig gemaakte link klikt die ervoor zorgt dat de payload in hun browsercontext wordt uitgevoerd.

Hoe dit meestal in de praktijk werkt:

1. Een niet-geauthenticeerde aanvaller POST of GET gegevens naar een eindpunt dat door de plugin wordt blootgesteld en dat invoer niet goed sanitiseert of encodeert.
2. Die gegevens worden opgeslagen op de site (bijv. pluginopties, aangepaste berichttypen, widgetinhoud of enige opgeslagen HTML).
3. Later, wanneer een bevoegde gebruiker (beheerder, sitebeheerder) de beheerschermen van de plugin of andere pagina's bezoekt waar de opgeslagen waarde zonder juiste escaping wordt weergegeven, voert de browser het geïnjecteerde script uit in de context van de vertrouwde site.
4. Het script kan acties uitvoeren als die gebruiker (cookies/lokale opslag lezen, gegevens exfiltreren, acties via AJAX namens de gebruiker uitvoeren, nieuwe beheerdersgebruikers aanmaken, enz.).

Belangrijke nuance: Hoewel de exploit ongeauthenticeerd wordt geïnjecteerd, vereisen de daadwerkelijke gevaarlijke acties vaak dat ten minste één bevoegde gebruiker wordt blootgesteld aan en interactie heeft met de inhoud. Dit vormt nog steeds een kritisch operationeel risico — omdat aanvallers vertrouwen op het misleiden van sitebeheerders (via phishing-e-mails, sociale engineering of het timen van hun aanvallen wanneer beheerders waarschijnlijk online zijn).

---

Impact in de echte wereld en aanvalscenario's

Hier zijn realistische scenario's die aanvallers kunnen gebruiken wanneer ze opgeslagen XSS in een WordPress-plugin vinden:

• Administratieve overname: Een script draait in de browser van een beheerder en roept WordPress admin AJAX-eindpunten aan om een beheerdersgebruiker aan te maken of het e-mailadres en wachtwoord van bestaande beheerders te wijzigen.
• Persistente achterdeur: Het geïnjecteerde script wijzigt PHP-sjablonen of plugin/thema-bestanden (via geauthenticeerde AJAX-verzoeken die in de beheersessie worden uitgevoerd) om een backdoor te planten die blijft bestaan na plugin-updates.
• Misbruik van de toeleveringsketen: Als een aanvaller controle krijgt over de UI van de plugin, kunnen ze links wijzigen, cryptomining-scripts invoegen of kwaadaardige JS in pagina's injecteren die bezoekers bedienen — wat de reputatie en zoekranking schaadt.
• Gegevensexfiltratie: Toegang tot cookies/sessie-tokens of formulieren in het beheerpaneel maakt exfiltratie van gevoelige inloggegevens of API-sleutels mogelijk.
• Phishing- en laterale aanvallen: Kwaadaardige inhoud kan worden gebruikt om valse inlogprompts weer te geven of beheerders om te leiden naar pagina's voor het verzamelen van inloggegevens.

Het gevaar van opgeslagen XSS is dat het persistent is en stealthy kan zijn. Een aanvaller kan payloads verbergen in gecodeerde vormen, deze naar pagina's met weinig verkeer sturen die beheerders zelden inspecteren, of aanvallen ketenen: opgeslagen XSS gebruiken om een robuustere backdoor te implementeren.

---

Onmiddellijke acties — checklist voor site-eigenaren en beheerders

Als je WordPress-sites beheert die ManageWP Worker (of een andere plugin met een onthulde kwetsbaarheid) gebruiken, volg dan onmiddellijk deze geprioriteerde checklist:

1. Upgrade de plugin onmiddellijk naar de gepatchte versie (4.9.32)
   • De leverancier heeft een oplossing uitgebracht in 4.9.32. Upgraden is de belangrijkste stap.
   • Als meerdere sites worden beheerd, automatiseer de update via je beheersworkflow of WP-CLI.
2. Als je niet meteen kunt upgraden, pas dan een WAF/virtuele patch toe.
   • Pas regels toe die veelvoorkomende XSS-payloads blokkeren of blokkeer verzoeken naar de plugin-eindpunten die niet-gezuiverde invoer accepteren.
   • WP-Firewall-klanten kunnen tijdelijke virtuele patches toepassen die verzoeken filteren en zuiveren die gericht zijn op de kwetsbare vectoren totdat je kunt updaten.
3. Dwing uitloggen van actieve admin-sessies
   • Draai alle beheerdersreferenties (wachtwoorden) en maak sessies ongeldig.
   • Je kunt uitloggen forceren door de WordPress-zouten (wp-config.php) opnieuw in te stellen of door een sessiebeheerplugin/-functie te gebruiken om sessies te laten vervallen.
4. Controleer op tekenen van actieve exploitatie (zie volgende sectie)
   • Zoek naar verdachte nieuwe admin-gebruikers, onverwachte wijzigingen in plugin/thema-bestanden en onbekende geplande taken (WP-Cron).
5. Maak een back-up voordat je grote wijzigingen aanbrengt
   • Maak onmiddellijk een volledige back-up (bestanden + database) voor forensisch onderzoek. Bewaar deze offline.
6. Als je bewijs van compromittering vindt, neem de site offline of activeer de onderhoudsmodus terwijl je deze schoonmaakt.
7. Meld belanghebbenden en, als je gebruikersgegevens host, overweeg juridische/regulerende meldingsvereisten.

Waarom updaten prioriteit heeft: Patches sluiten de kwetsbaarheid zodat deze niet opnieuw kan worden geëxploiteerd; alle andere verdedigingen zijn aanvullend.

---

Detectietechnieken — waar je op moet scannen en hoe

Opgeslagen XSS laat sporen achter in de database en in logs. Hier zijn praktische stappen die je kunt nemen om bewijs van injectie of exploitatie te detecteren.

1. Zoek naar verdachte HTML/JavaScript in blijvende gegevens
   • Kijk in wp_posts.post_content, wp_postmeta, wp_opties, wp_comments.comment_content, en eventuele plugin-specifieke tabellen.
   • Zoek naar <script> tags, onmouseover/onerror attributen, eval(, atob(, document.cookie, innerHTML, of verdachte base64-strings.
   • Voorbeeld (veilig, alleen-lezen) SQL-patronen:
     • SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
     • SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';
     • SELECT * FROM wp_comments WHERE comment_content LIKE '%onerror=%' OF comment_content LIKE '%<script%';
   • Opmerking: Sommige legitieme inhoud kan scriptfragmenten bevatten (bijv. embeds), dus verifieer de resultaten voordat je actie onderneemt.
2. Controleer gebruikersaccounts en rollen
   • Lijst alle gebruikers met administrator- of redacteurrollen. Zoek naar recente accounts die zijn aangemaakt rond de openbaarmakingsdatum.
   • WP-CLI: wp user list --role=administrator --format=table
3. Controleer recente bestandswijzigingen
   • Zoek op de server naar recent gewijzigde bestanden. Voorbeeld:

     find /path/to/site -type f -mtime -7 -ls

   • Vergelijk checksums met een bekende goede back-up of een verse download van de thema's/plugins van je site.
4. Inspecteer geplande taken
   • WP-Cron-taken kunnen persistentie verbergen. Gebruik queries of WP-CLI om geplande evenementen te lijst.
5. Scan webserverlogs
   • Zoek naar verzoeken naar plugin-eindpunten of verzoeken die verdachte payloads bevatten (script-tags, gecodeerde payloads). Noteer de IP's, tijdstempels en gebruikersagenten.
6. Gebruik malware-scanners en inhoudscanners
   • Voer een site-scanner uit om naar bekende kwaadaardige patronen te zoeken, maar wees je ervan bewust dat scanners valse positieven kunnen genereren en mogelijk slimme obfuscatie niet detecteren.
7. Gebruik browsergebaseerde inspectie voor verdachte pagina's
   • Laad adminpagina's terwijl je netwerkoproepen (DevTools) monitort om te zien of onverwachte scripts worden geladen of netwerk-POSTs worden gemaakt.
8. Monitor uitgaande netwerkoproepen
   • Als je site externe domeinen aanroept (beacons, analytics), controleer dan op recente wijzigingen of onbekende eindpunten.

---

Incidentrespons en schoonmaak checklist

Als je exploitatie detecteert, volg dan een georganiseerd responsplan:

1. Isoleren en bewijs bewaren
   • Maak een back-up (bestanden + DB) en sla deze buiten de server op.
   • Bewaar serverlogs (webserver, PHP-FPM, syslog) en exporteer relevante databasequerylogs.
2. Bevatten
   • Als het mogelijk is, zet de site in onderhoudsmodus of schakel tijdelijk de openbare toegang uit terwijl je schoonmaakt.
   • Reset adminwachtwoorden en roteer alle API-sleutels en tokens die door de site worden gebruikt (derde-partij API's, CDN, externe beheersaccounts).
3. Verwijder de payload
   • Verwijder handmatig geïnjecteerde script-tags of kwaadaardige HTML uit de databaseregels waar gevonden.
   • Als de injectie kern-/plugin-/thema-bestanden heeft gewijzigd, vervang ze dan door schone kopieën van de leverancier/bron en pas alleen gevalideerde aanpassingen opnieuw toe.
4. Herinstalleer of herstel schone pluginversies
   • Verwijder de getroffen plugin volledig en installeer de gepatchte versie 4.9.32 van de officiële bron opnieuw.
   • Verwijder ter veiligheid de pluginmap en upload een nieuwe kopie in plaats van ter plaatse te patchen.
5. Controleer op secundaire persistentie
   • Aanvallers creëren vaak achterdeurtjes. Zoek naar PHP-bestanden buiten de gebruikelijke plugin/thema-structuur, gewijzigde functies.php bestanden, en bestanden in wp-inhoud/uploads met .php verlenging.
6. Herbevestig en test
   • Zodra alles is schoongemaakt en gepatcht, test de adminflows, inloggen en bekende functionaliteit.
   • Voer verschillende malware-scans uit en inspecteer de database opnieuw op eventuele resterende verdachte inhoud.
7. Herstel diensten en monitor
   • Breng de site weer online en houd de logs nauwlettend in de gaten voor herhaalde exploitpogingen.
   • Verhoog de logging-granulariteit voor een periode om eventuele resten van kwaadaardige activiteit vast te leggen.
8. Maatregelen na het incident
   • Beoordeel en verbeter het wijzigingsbeheer en de pluginbeoordelingsprocessen.
   • Overweeg het implementeren van een beperkt admingebied (IP-beperkingen, MFA) om het risico op toekomstige aanvallen te verminderen.

Als je niet de interne capaciteit hebt om een grondige schoonmaak uit te voeren, schakel dan een beveiligingsprofessional in. Schoonmaken na een aanhoudende, goed uitgevoerde compromittering is lastig en vereist vaak ervaring om ervoor te zorgen dat alle sporen worden verwijderd.

---

Preventieve maatregelen en langdurige verharding

Het oplossen van het onmiddellijke probleem is slechts de helft van de taak. Versterk je algehele WordPress-houding zodat je beter voorbereid bent op toekomstige onthullingen.

1. Houd alles up-to-date
   • Thema's, plugins en de WordPress-kern moeten up-to-date worden gehouden. Geef prioriteit aan beveiligingspatches en kritieke fixes.
   • Gebruik een staging site om updates te valideren voordat ze in productie gaan als je complexe aanpassingen hebt.
2. Gebruik virtuele patching / WAF
   • Een Web Application Firewall kan exploitatiepogingen blokkeren voordat ze de site bereiken en kan tijdelijke bescherming bieden wanneer onmiddellijke plugin-updates niet mogelijk zijn.
   • Zorg ervoor dat WAF-regels veelvoorkomende XSS-vectoren dekken en snel kunnen worden toegepast als reactie op openbaarmakingen.
3. Beginsel van de minste privileges
   • Beperk het aantal beheerdersaccounts. Geef gebruikers alleen de privileges die ze nodig hebben.
   • Overweeg om gedelegeerde rollen en aparte accounts te gebruiken voor inhoudsredacteuren versus technische beheerders.
4. Sterke authenticatie
   • Handhaaf sterke wachtwoorden en implementeer 2FA/MFA voor alle admin- en ontwikkelaarsaccounts.
   • Gebruik gecentraliseerde authenticatie of SSO waar praktisch.
5. Versteviging en serverniveau-bescherming
   • Schakel PHP-uitvoering uit in uploadmappen.
   • Beperk de toegang tot wp-admin per IP waar mogelijk.
   • Gebruik veilige bestandsmachtigingen en isoleer sites per gebruiker op gedeelde hosts.
6. Continue monitoring
   • Log en monitor admin-acties, bestandswijzigingen en gebruikerscreatie-evenementen.
   • Configureer waarschuwingen voor verdachte admin-activiteit.
7. Veilige ontwikkelingspraktijken
   • Voor plugin- en thema-ontwikkelaars: valideer en escape alle output, gebruik voorbereide statements voor DB-query's en pas context-geschikte escaping toe (esc_html, esc_attr, wp_kses bij het toestaan van HTML).
   • Vertrouw nooit op gebruikersinvoer — sanitize, valideer en escape.
8. Back-up en herstel
   • Houd regelmatig back-ups bij (bestanden + DB), sla ze off-site op en test regelmatig herstel. Back-ups zijn je laatste redmiddel bij ernstige compromissen.
9. Beoordeling van afhankelijkheden en pluginrisico's
   • Voer periodiek een audit uit van geïnstalleerde plugins en verwijder ongebruikte of niet-onderhouden plugins.
   • Geef de voorkeur aan plugins met een goede beveiligingshistorie en actieve onderhoud.
10. Test en oefen
    • Voer geplande scans uit, periodieke penetratietests en oefen tabletop-oefeningen voor incidentrespons met je team.

---

Hoe WP-Firewall helpt tijdens en na deze openbaarmaking

Bij WP-Firewall zien we dit soort openbaarmakingen regelmatig en ontwerpen we onze diensten om site-eigenaren te helpen de blootstelling te verminderen en snel te reageren. Hier is hoe we helpen:

• Virtueel patchen (WAF-regels): We publiceren noodregels binnen enkele uren na geverifieerde openbaarmakingen. Die regels blokkeren bekende aanvalssignaturen en aanvraagpatronen die worden gebruikt om opgeslagen XSS te exploiteren zonder dat de site-eigenaar onmiddellijk hoeft bij te werken.
• Beheerde scanning: Onze geplande en on-demand scanners detecteren tekenen van opgeslagen XSS-payloads in berichten, opties, opmerkingen en aangepaste tabellen, zodat je geïnjecteerde inhoud vroeg kunt vinden en oplossen.
• Bedreigingsinformatie en waarschuwingen: We monitoren pogingen om publiek bekende kwetsbaarheden te exploiteren en bieden realtime waarschuwingen wanneer je site wordt doelwit.
• Forensische begeleiding en opruimwerkstromen: Wanneer een site indicatoren van compromittering vertoont, bieden we stapsgewijze herstelbegeleiding en kunnen we helpen om indien nodig over te schakelen naar handmatige opruimondersteuning.
• Beschermingslagen: We raden aan en helpen met multi-laag verdedigingen — van serververhardingsrichtlijnen tot applicatieniveau regels en administratieve controles.

Als je verantwoordelijk bent voor een vloot van WordPress-sites, vermindert een combinatie van automatische patching waar veilig, virtuele patching en continue scanning je gemiddelde tijd tot mitigatie en beperkt het venster van blootstelling.

---

Krijg onmiddellijke basisbescherming — Begin met het WP-Firewall Gratis Plan

Profiteer nu van praktische basisbescherming op je sites. Het Basis (Gratis) plan van WP-Firewall omvat essentiële beheerde firewalldekking die is ontworpen om de blootstelling aan kwetsbaarheidsopenbaarmakingen te verminderen:

• Essentiële bescherming inclusief een beheerde firewall met een bewezen Web Application Firewall (WAF)
• Onbeperkte bandbreedte (geen beperking bij verkeerspieken)
• Malware-scanner die bestanden en inhoud inspecteert op verdachte payloads
• Mitigatie van de OWASP Top 10 risico's om te helpen verdedigen tegen veelvoorkomende injectie- en XSS-vectoren

Als je klaar bent om deze basisbescherming aan je site toe te voegen, start hier een gratis WP-Firewall Basisplan: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Voor teams die meer geautomatiseerde herstelmaatregelen en uitgebreide controles willen, bieden onze Standaard en Pro plannen automatische malwareverwijdering, IP-toestaan/weigeren controles, virtuele patching van kwetsbaarheden, maandelijkse beveiligingsrapporten en premium add-ons om ondersteuning over meerdere sites te schalen.

---

Praktische aanbevelingen specifiek voor deze openbaarmaking

• Update ManageWP Worker onmiddellijk naar 4.9.32 op alle getroffen sites.
• Geef prioriteit aan patching op sites met hoge privileges (bijv. sites met meerdere beheerders, e-commerce winkels, klantensites).
• Zoek na het patchen in uw database en plugin-instellingen naar onverwachte HTML- of scriptfragmenten die vóór de update zijn ingevoegd.
• Schakel multi-factor authenticatie in voor alle admin-logins en wijzig admin-wachtwoorden na herstel.
• Als u klantensites beheert, informeer dan klanten dat er een update is toegepast en of er herstelmaatregelen nodig waren.

Als u niet onmiddellijk alle sites kunt updaten, schakel dan virtuele patchregels aan de rand (WAF) in en beperk de toegang tot wp-admin als tijdelijke maatregel.

---

Hoe veilig te zoeken naar opgeslagen XSS zonder de site te breken (stapsgewijs)

1. Maak een offline kopie van uw database (exporteer met phpMyAdmin, WP-CLI of andere tools).
2. Gebruik alleen-lezen queries om verdachte patronen te vinden:
   • berichten: SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' OR post_content LIKE '%onerror=%';
   • opties: SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%' LIMIT 100;
   • opmerkingen: SELECT comment_ID, comment_author_email FROM wp_comments WHERE comment_content LIKE '%<script%' LIMIT 100;
3. Valideer bevindingen handmatig — soms zullen legitieme embeds overeenkomen met zoekpatronen.
4. Verwijder waar mogelijk alleen de exacte kwaadaardige fragmenten in plaats van bulkverwijderingen uit te voeren.
5. Als u twijfelt, exporteer dan de verdachte rijen en laat een beveiligingsexpert deze beoordelen voordat u wijzigingen aanbrengt.

Belangrijk: voer nooit blinde destructieve queries uit zonder een back-up.

---

// sla de gesaniteerde URL op

Na opschoning en patching:

• Houd verhoogde monitoring gedurende 30 dagen: controleer admin-gebruikerslogins, bestandsintegriteit en foutlogboeken.
• Beoordeel wekelijks de geplande taken en cron-invoer gedurende een maand.
• Gebruik een oplossing voor bestandsintegriteitsbewaking (FIM) om te waarschuwen voor wijzigingen in kernplugin/thema-bestanden.
• Documenteer het incident: oorzaak, herstelstappen en eventuele hiaten in processen.

---

Laatste woorden — tijdige actie voorkomt hoofdpijn

Openbaarmakingen zoals de ManageWP Worker opgeslagen XSS herinneren ons eraan dat zelfs vertrouwde plugins af en toe kwetsbaarheden kunnen bevatten. De beste verdediging is een georganiseerde combinatie van snelle patches, gelaagde bescherming (virtuele patching/WAF), continue monitoring en een goed geoefend incidentresponsplan.

Als je verantwoordelijk bent voor één of meerdere WordPress-sites, behandel beveiliging dan als een doorlopende operationele taak — niet als een eenmalige installatie. Een snelle update of een tijdelijke virtuele patch kan het verschil maken tussen een klein incident en een algehele compromittering van de site.

Blijf veilig, blijf up-to-date, en als je hulp nodig hebt bij het beschermen van je sites terwijl je patcht, kan WP-Firewall je helpen om blootstelling te verminderen en herstel te versnellen.

— WP-Firewall Beveiligingsteam

---

Referenties en verder lezen (technische bronnen)

• Controleer het changelog van de plugin en de leveranciersadviezen voor de release-opmerkingen van versie 4.9.32.
• Zoek je site naar opgeslagen script-tags en gebeurtenisattributen (onerror, onmouseover).
• Als je professionele incidentrespons nodig hebt, verzamel dan logboeken en een back-upkopie voordat je externe hulp inschakelt.

(Einde van bericht)