Pluginnaam	WP-Chatbot voor Messenger
Type kwetsbaarheid	Gebroken toegangscontrole
CVE-nummer	CVE-2026-3506
Urgentie	Laag
CVE-publicatiedatum	2026-03-22
Bron-URL	CVE-2026-3506

WP-Chatbot <= 4.9 — Gebroken Toegangscontrole (CVE-2026-3506): Wat WordPress Site-eigenaren Nu Moeten Doen

Auteur: WP-Firewall Beveiligingsteam
Datum: 2026-03-22
Trefwoorden: WordPress, kwetsbaarheid, WAF, wp-chatbot, beveiliging

Samenvatting: Een kwetsbaarheid in gebroken toegangscontrole (CVE-2026-3506) die WP-Chatbot voor Messenger (versies ≤ 4.9) beïnvloedt, stelt niet-geauthenticeerde aanvallers in staat om de chatbotconfiguratie te wijzigen. Het directe risico voor een site is laag (CVSS 5.4), maar de gevolgen in de echte wereld — gestolen berichtenreferenties, phishingvectoren, privacyschendingen en reputatieschade — kunnen aanzienlijk zijn. Deze post legt het risico uit, hoe aanvallers het kunnen misbruiken, detectiestappen, kortetermijnmaatregelen die je onmiddellijk kunt toepassen, en langetermijnversterking — van pluginoplossingen tot WAF-gebaseerde virtuele patches.

Inhoudsopgave

• Wat is er gebeurd (snel overzicht)
• Waarom dit belangrijk is voor jouw WordPress-site
• Hoe deze kwetsbaarheid werkt (technische samenvatting)
• Realistische exploitatie-scenario's en impact
• Hoe te detecteren of je site het doelwit was of gecompromitteerd is
• Onmiddellijke stappen om schade te beperken (voor beheerders en hosts)
• Praktische mitigaties (pluginoplossingen, code-oplossingen en WAF-regels)
• Checklist voor incidentrespons (stap voor stap)
• Langetermijnbeveiligingsaanbevelingen voor chatintegraties
• Bescherm je site vandaag — Begin met het WP-Firewall Gratis Plan
• Slotopmerkingen en verdere lectuur

---

Wat is er gebeurd (snel overzicht)

Beveiligingsonderzoekers ontdekten dat WP-Chatbot voor Messenger (versies tot en met 4.9) functionaliteit blootlegt die niet-geauthenticeerde verzoeken toestaat om de chatbotconfiguratie te wijzigen. Kortom: een aanvaller kan zorgvuldig samengestelde verzoeken indienen en kritieke chatbotinstellingen wijzigen — zoals paginatokens, webhookdoelen, antwoordgedrag of andere integratieparameters — zonder geauthenticeerd of geautoriseerd te zijn.

Het probleem is geclassificeerd als Gebroken Toegangscontrole en toegewezen aan CVE-2026-3506. Patchauteurs hebben een lage prioriteit toegewezen (CVSS 5.4) omdat deze kwetsbaarheid geen onmiddellijke volledige overname van de site mogelijk maakt; echter, het vertegenwoordigt een serieus privacy- en bedrijfsrisico, vooral voor sites die afhankelijk zijn van Messenger-chatstromen voor klantinteracties, leads of authenticatie/validatie.

Waarom dit belangrijk is voor jouw WordPress-site

Op het eerste gezicht lijkt een wijziging in de chatbotconfiguratie triviaal in vergelijking met code-executie of SQL-injectie. Maar overweeg wat een aanvaller kan bereiken door de chatconfiguratie te wijzigen:

• Vervang de toegangstoken van de Facebook-pagina van je bot en webhookinstellingen, waardoor alle inkomende berichten naar aanvallers worden omgeleid.
• Onderbreek klantcommunicatie en verzamel gevoelige informatie (facturering, PII).
• Stuur phishingberichten naar gebruikers die eerder met je chatbot hebben gecommuniceerd, waardoor de kans op succesvolle fraude toeneemt.
• Injecteer kwaadaardige URL's in chatbotantwoorden, waardoor bezoekers naar pagina's voor het verzamelen van referenties worden geleid.
• Bezoedel je merk door beledigende of frauduleuze antwoorden te sturen vanuit wat lijkt op een officieel kanaal.

Omdat messenger/chatinteracties door gebruikers worden vertrouwd, kunnen aanvallers die de chatstroom controleren zeer effectieve social engineering-aanvallen uitvoeren. Voor e-commerce en ondersteuningsgerichte sites kan de zakelijke impact ernstig zijn, zelfs wanneer deze kwetsbaarheid alleen niet leidt tot volledige servercompromittering.

Hoe deze kwetsbaarheid werkt (technische samenvatting)

De oorzaak is het ontbreken van autorisatiecontroles op ten minste één functie of eindpunt dat de plugin blootlegt. Voorbeelden van typische patronen in soortgelijke problemen:

• Een AJAX-actie behandeld via admin-ajax.php zonder capaciteitscontrole (geen current_user_can / check_ajax_referer).
• Een REST API-route geregistreerd zonder een geschikte permission_callback.
• Een direct plugin PHP-bestand dat POST-gegevens verwerkt en opties bijwerkt zonder authenticatie, nonces of mogelijkheden te verifiëren.

De plugin accepteert configuratievelden (bijv. toegangstokens, pagina-ID's, webhook-URL's). Wanneer het eindpunt van de plugin een verzoek verwerkt, schrijft het die waarden in de WordPress-database (wp_options of aangepaste tabellen) en de plugin gebruikt ze om verbinding te maken met Messenger/Facebook.

Omdat het eindpunt niet verifieert of de oproeper een geauthenticeerde beheerder is of geen nonce valideert, kan elke externe aanvaller verzoeken verzenden om de chatbot-configuratie bij te werken.

Opmerking: de precieze eindpuntnamen en parameter-sleutels kunnen variëren met de implementatie van de plugin. De relevante indicatoren om op te letten zijn HTTP POST-verzoeken die parameters bevatten die eruitzien als toegangstokens, pagina-ID's of webhook-URL's en die plugin-gerelateerde acties aanroepen.

Realistische exploitatie-scenario's en impact

1. Passieve diefstal van inloggegevens en monitoring
   Aanvallers werken het toegangstoken en de webhook bij naar hun eigen FB-app of server, en loggen vervolgens alle berichten die naar uw bot zijn verzonden. Dit geeft aanvallers toegang tot privéberichten van klanten en leadgegevens.
2. Actieve phishing en fraude
   Na het omleiden van berichten, antwoorden aanvallers gebruikers met links naar gekloonde betaalpagina's of malware. Omdat de antwoorden afkomstig zijn van de bot die gebruikers vertrouwden, zijn de doorklik- en conversieratio's voor aanvallen veel hoger.
3. Reputatie en verstoring van het bedrijf
   Bot-antwoorden kunnen worden ingesteld om spam, beledigende berichten of misleidende marketingaanbiedingen te verzenden. Merken en zoekreputatie kunnen lijden; u kunt ook de beleidsregels van derden (Facebook) schenden, wat leidt tot schorsing van het account.
4. Overstappen naar aanvallen met een hogere waarde
   Informatie verzameld via chatinteracties (e-mailadressen, telefoonnummers, verificatiecodes) kan worden gebruikt voor gerichte overname van accounts of credential-stuffing.

Hoe te detecteren of je site het doelwit was of gecompromitteerd is

Begin met de meest waarschijnlijke artefacten die een aanvaller zou produceren of wijzigen:

1. Pluginversiecontrole
   Bevestig de versie van de WP-Chatbot-plugin. Als deze ≤ 4.9 is, neem dan aan dat u kwetsbaar bent totdat deze is gepatcht of verholpen.
2. Configuratie wijzigingen
   Controleer uw chatbot-plugininstellingen in de WordPress-admin. Zoek naar onverwachte waarden:
   • Onverwachte toegangstokens, app-ID's, pagina-ID's
   • Webhook-URL's die naar onbekende domeinen of IP's wijzen
   • Instellingen die aan/uit zijn gezet (bijv. automatische antwoorden, inschakelen/uitschakelen)
3. Databasecontroles
   Kijk in wp_options (of plugin-specifieke tabellen). Veelvoorkomende optienamen kunnen “chatbot”, “wp_chatbot”, “fb”, “messenger”, “access_token” of “page_id” bevatten. Onverklaarde recente wijzigingen zijn verdacht.
4. HTTP-logs
   Zoek in de webserverlogs (access_log, error_log) naar POST-verzoeken naar:
   • /wp-admin/admin-ajax.php met plugin-gerelateerde actieparameters
   • /wp-json/* eindpunten geregistreerd door de plugin
   • Directe plugin PHP-bestanden (bijv., /wp-content/plugins/wp-chatbot/… .php)

   Zoek naar niet-geauthenticeerde verzoeken van enkele IP's, vooral POST's die toegangstokenparameters of webhook-URL's bevatten.

5. Uitgaande activiteit
   Controleer op ongebruikelijke uitgaande verbindingen (van webserver naar externe IP's/domeinen), vooral naar Facebook-gerelateerde eindpunten die zijn geïnitieerd met onverwachte tokens.
6. Messenger/Facebook-activiteit
   Heeft je Facebook-pagina onverwachte webhook-gebeurtenissen getoond? Zijn er herconfiguratie-logboeken in je Facebook-app? Soms zijn tx's zichtbaar in de Facebook-ontwikkelaarsconsole als je de app beheert.

Onmiddellijke stappen om schade te beperken (voor beheerders en hosts)

Als je ontdekt dat je kwetsbaar bent of vermoedt dat er misbruik is, handel dan snel:

1. Deactiveer tijdelijk de WP-Chatbot-plugin
   Deactiveer de plugin vanuit wp-admin of via WP-CLI:

   wp plugin deactiveren wp-chatbot

   Dit voorkomt verdere configuratie-updates en stopt de bot met het gebruik van mogelijk kwaadaardige inloggegevens.

2. Referenties roteren
   Draai alle Messenger/Facebook-tokens die je beheert en controleer de app-machtigingen. Intrek bestaande tokens en genereer nieuwe alleen na herstel en verificatie.
3. Herclaim webhooks / herautoriseer
   Herstel webhook-URL's en app-configuraties met de juiste eindpunten zodra de site is beveiligd.
4. Forensische gegevens bewaren
   Maak voordat je destructieve wijzigingen aanbrengt, back-ups van de site, database en serverlogs voor forensische analyse. Als je kwaadaardige vermeldingen moet verwijderen, exporteer dan eerst kopieën.
5. Belanghebbenden op de hoogte stellen
   Informeer interne teams en eventuele externe partners die mogelijk zijn getroffen (ondersteuning, marketing). Als gebruikersgegevens mogelijk zijn blootgesteld, volg dan de lokale wetten en interne beleidslijnen voor inbreukmelding.

Praktische mitigaties (pluginoplossingen, code-oplossingen en WAF-regels)

Korte termijn mitigaties zijn cruciaal terwijl je wacht op een officiële patch (als deze nog niet beschikbaar is).

A. Plugin-update (beste optie)

Als de auteur van de plugin een gefixte versie uitbrengt, werk dan onmiddellijk bij. Dit is de enige echte oplossing voor een pluginfout.

B. Als er geen patch beschikbaar is: pas een tijdelijke code-niveau beveiliging toe

Gebruik een kleine must-use (mu-plugin) snippet om niet-geauthenticeerde verzoeken naar bekende pluginacties te blokkeren. Deze snippet is omkeerbaar en bevindt zich buiten de pluginmap (veiliger wanneer plugins mogelijk worden gewijzigd).

Voorbeeld mu-plugin (plaats als een bestand in wp-content/mu-plugins/deny-wp-chatbot-unauth.php):

<?php;

Opmerkingen:

• Dit is een defensieve stopgap: het weigert niet-geauthenticeerde AJAX en REST verzoeken die lijken te behoren tot de plugin.
• Pas actienamen en REST route strings aan om overeen te komen met wat de plugin gebruikt als je ze kunt bevestigen in code of logs.

C. .htaccess regels (Apache)

Als je de voorkeur geeft aan blokkeren op de webserverlaag, voeg dan regels toe om POST's naar specifieke pluginbestanden of admin-ajax acties voor anonieme gebruikers te weigeren.

Voorbeeld (plaats binnen de root van de site .htaccess vóór de WordPress regels):

# Blokkeer verzoeken naar admin-ajax.php met pluginactie of wp-chatbot eindpunten van niet-lokale/niet-geauthenticeerde clients

D. WAF regels (aanbevolen voor hosts of degenen met WAF)

Als je een Web Application Firewall (WAF) beheert — inclusief plugin-gebaseerde of server-niveau WAF — kun je onmiddellijk virtuele patches implementeren:

• Blokkeer/uitdaag POST's naar admin-ajax.php die verdachte actieparameters bevatten (bijv., action=wp_chatbot_*), tenzij het verzoek afkomstig is van een geauthenticeerde sessie of van een toegestane interne IP.
• Blokkeer/uitdaag verzoeken naar REST-routes die overeenkomen met /wp-json/wp-chatbot/* wanneer het verzoek geen authenticatieheaders of geldige nonce-waarden bevat.
• Maak handtekeningen voor parameter namen die vaak worden gebruikt voor chatconfiguratie (bijv., fb_access_token, page_id, app_secret, webhook_url) en weiger verzoeken die proberen deze in te stellen vanuit niet-geauthenticeerde bronnen.
• Voor inkomende verzoeken met JSON-lichaam, zoek naar patronen die sleutels bevatten zoals “page_id” of lange strings die lijken op toegangstokens en blokkeer wanneer er geen geldige sessiecookie of X-WP-Nonce is.

Voorbeeld generieke ModSecurity regel (illustratief; pas aan voor jouw omgeving):

SecRule REQUEST_METHOD "POST" "chain,phase:2,deny,status:403,id:100500,msg:'Blokkeer niet-geauthenticeerde WP-Chatbot configuratiewijziging'"

E. Beperk pluginbestanden via bestandsmachtigingen en IP-toelatingslijsten

Als uw team IP's van de webserver beheert voor onderhoud, overweeg dan om de toegang tot plugin-beheer-eindpunten tijdelijk te beperken op IP waar mogelijk.

F. Versterk WordPress nonces en inlogbeveiligingen

Zorg ervoor dat geldige nonces en capaciteitscontroles worden afgedwongen op aangepaste eindpunten. Schakel waar mogelijk 2FA in voor beheerdersaccounts en beperk het aantal beheerdersgebruikers.

Checklist voor incidentrespons (stap voor stap)

Als u bevestigt dat er misbruik is, volg dan deze volgorde:

1. Isoleren
   Deactiveer de plugin onmiddellijk of pas de mu-plugin / WAF-regels hierboven toe om verdere wijzigingen te blokkeren.
2. Bewijsmateriaal bewaren
   Kopieer webserverlogs, database-exporten en pluginbestanden naar een veilige locatie voor forensisch onderzoek.
3. Draai geheimen en tokens.
   Intrek en genereer opnieuw eventuele Facebook/App-tokens, webhook-geheimen, API-sleutels die mogelijk zijn gewijzigd of blootgesteld.
4. Scan op secundaire compromittering
   Voer een malware-scan op serverniveau en WordPress-niveau uit. Zoek naar ongeautoriseerde beheerdersaccounts, verdachte geplande taken (cron), gewijzigde thema/plugin-bestanden of backdoor PHP-bestanden.
5. Herstel configuratietampering
   Herstel chatbotinstellingen vanuit een bekende goede back-up of reconfigureer met nieuwe inloggegevens.
6. Beoordeel gebruikersinteracties
   Als een aanvaller phishingberichten via uw bot heeft verzonden, identificeer dan de getroffen gebruikers. Bereid communicatie voor volgens de privacywetten en het interne beleid.
7. Herbeoordeel en sluit aanvalsvectoren
   Zodra het is schoongemaakt, pas patches en versterkingen toe:
   • Werk plugins, thema's en de WordPress-kern bij.
   • Houd WAF-regels in stand totdat de officiële patch is geïnstalleerd.
   • Monitor logs nauwlettend gedurende ten minste 30 dagen.

Langetermijnbeveiligingsaanbevelingen voor chatintegraties

Chatintegraties zijn krachtig, maar vergroten uw aanvalsvlak. Volg deze richtlijnen:

• Minimaliseer machtigingen: Geef uw Facebook-app of -pagina alleen de minimale machtigingen die nodig zijn.
• Isoleren van tokens: Bewaar tokens in veilige opslag (niet in platte tekst) en roteer ze regelmatig.
• Monitoren van berichtpatronen: Gebruik logging om pieken in uitgaande berichten of plotselinge veranderingen in gedrag te detecteren.
• Toegangscontroles op eindpunten: Zorg ervoor dat elk plugin-eindpunt een permission_callback of capability check heeft en nonces valideert.
• Gebruik gescheiden accounts: Vermijd het delen van beheerdersreferenties tussen marketing- en IT-teams. Gebruik rolgebaseerde toegangscontrole.
• Pas verdediging in diepte toe: WAF, monitoring van bestandsintegriteit (FIM), periodieke kwetsbaarheidsscans en automatische back-ups.
• Incidentenhandleiding: Onderhoud en test periodiek een incidentrespons-handleiding voor integraties van derden.

Bescherm je site vandaag — Begin met het WP-Firewall Gratis Plan

Titel: Begin nu met het beschermen van uw chatintegraties — meld u aan voor het WP-Firewall Gratis Plan

Als u WordPress gebruikt, zal een defensieve WAF en continue monitoring de blootstellingsperiode voor integratiefouten zoals deze verkleinen. Het Basis (Gratis) plan van WP-Firewall biedt essentiële bescherming die u binnen enkele minuten kunt inschakelen:

• Beheerde firewallregels afgestemd op WordPress en veelvoorkomende plugin-eindpunten
• Onbeperkte bandbreedte voor scannen en mitigatie
• WAF-bescherming en virtuele patching-handtekeningen om niet-geauthenticeerde configuratie-updates te blokkeren
• Regelmatige malware-scans en mitigatie tegen de OWASP Top 10

Als u een extra laag van automatisering en snelle remediering wilt, voegen onze betaalde plannen automatische malwareverwijdering, IP-blacklisting/witlisting, maandelijkse rapportage en automatische virtuele patching toe. Leer meer of meld u hier aan voor het gratis plan:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Waarom dit nuttig is: terwijl u wacht op plugin-ontwikkelaars om fixes uit te brengen, kan een WAF met virtuele patching kwaadaardige verzoeken onderscheppen, waardoor u cruciale tijd krijgt om referenties te roteren, te onderzoeken en te verhelpen zonder onmiddellijk de kernfunctionaliteit te hoeven opgeven.

Voorbeelden van WAF-strategieën die we toepassen voor deze klasse kwetsbaarheid

• Virtuele patching: maak gerichte handtekeningen om POST-verzoeken te blokkeren die proberen configuratiesleutels te schrijven (fb_access_token, page_id, webhook).
• Sessievalidatiecontroles: vereisen dat verzoeken die configuratie wijzigen een geauthenticeerde sessiecookie of geldige nonce bevatten.
• Gedragsgebaseerde blokkering: blokkeer clients die herhaaldelijk POST-verzoeken naar configuratie-eindpunten indienen maar geen geldige auth-indicatoren verstrekken.
• Logging + waarschuwingen: genereer waarschuwingen met hoge prioriteit voor elke poging om chatconfiguratiewaarden te wijzigen, zodat een beheerder snel kan onderzoeken.
• Noodstopknop: mogelijkheid om onmiddellijk al het plugin-gerelateerde inkomende wijzigingverkeer te weigeren terwijl het alleen-lezen chatgedrag voor gebruikers behouden blijft.

Praktische forensische controles en zoekopdrachten

Om je te helpen bij het zoeken naar bewijs van manipulatie, hier zijn praktische dingen om naar te zoeken in logs en de database:

• Webserverlogs: zoek naar strings in verzoeken:
  • “wp_chatbot”, “wp-chatbot”, “/wp-json/wp-chatbot/”, “chatbot”, “messenger”, “fb_access_token”, “page_id”, “webhook”
• Databank:
  • SELECT option_name, option_value FROM wp_options WHERE option_name LIKE ‘%chat%’ OF option_value LIKE ‘_access_token%’ LIMIT 100;
  • Zoek in plugin-specifieke tabellen naar recente wijzigingen
• WordPress debug log:
  • Schakel WP_DEBUG_LOG in om pluginwaarschuwingen of -fouten vast te leggen.
• Mail/log waarschuwingen:
  • Zoek naar adminmeldingen over tokenwijzigingen of herregistraties van webhooks.

Communicatie en naleving

Als je bevestigt dat gegevens die aan een gebruiker of klant zijn gekoppeld mogelijk zijn blootgesteld (namen, e-mails, betalingsgerelateerde informatie die tijdens chatsessies is ingevoerd), volg dan je wettelijke verplichtingen voor meldingen van datalekken. Zelfs als de kwetsbaarheid “lage ernst” lijkt, kan gegevenslekken uit chatinteracties gevoelig zijn.

Beste praktijk is transparantie: informeer de getroffen gebruikers met duidelijke stappen die ze moeten nemen (bijv. negeer berichten die om betaling vragen, wijzig wachtwoorden als inloggegevens zijn gegeven, let op phishingpogingen) en de herstelstappen die je hebt ondernomen.

Waarom een laag CVSS-nummer niet betekent “negeer het”

CVSS is een nuttige basislijn, maar context is belangrijk. CVSS 5.4 weerspiegelt dat de kwetsbaarheid geen authenticatie vereist, maar geeft niet direct toegang tot externe code-uitvoering. Echter:

• Het beschikbare aanvalsurface (chatbots) behandelt vaak PII en interacties met hoge vertrouwensniveaus.
• Aanvallers maken gebruik van vertrouwensrelaties om een onevenredige impact te produceren van ogenschijnlijk lage-ernst bugs.
• Snelle herstelmaatregelen verminderen de kans op reputatie- of regelgevingsschade, wat vaak kostbaarder is dan een codefix.

Daarom, neem een risicogebaseerde aanpak aan: prioriteer kwetsbaarheden die direct invloed hebben op klantvertrouwen en gegevensstroom — niet alleen die welke een aanvaller toegang tot de shell geven.

Een korte checklist voor drukke site-eigenaren (uitvoerbaar)

• Controleer de pluginversie: als WP-Chatbot ≤ 4.9, beschouw als kwetsbaar.
• Als kwetsbaar en niet gepatcht: deactiveer de plugin of pas onmiddellijk een mu-plugin/WAF-blok toe.
• Draai alle messenger/app-tokens en webhook-geheimen.
• Inspecteer botantwoorden en recente uitgaande berichten op verdachte inhoud.
• Maak WAF-regels om niet-geauthenticeerde configuratie-updates te blokkeren (zie voorbeelden hierboven).
• Houd logs en back-ups veilig voor analyse na een incident.
• Test en handhaaf de versterking van het admin-account en 2FA.

Slotopmerkingen van het WP-Firewall beveiligingsteam

Derde-partij integraties zoals chatbots breiden de functionaliteit uit, maar vergroten ook uw aanvalsvlak. De kwetsbaarheid van gebroken toegangscontrole in WP-Chatbot is een belangrijke herinnering: toegangscontrole moet op elk toegangspunt worden gevalideerd. Als u een WordPress-site beheert die chatintegraties gebruikt, neem deze kwetsbaarheid serieus — zelfs als het geen directe weg naar volledige overname van de site is.

Als je hulp nodig hebt:

• Begin met de snelle mitigaties die hierboven zijn beschreven (deactiveer de plugin of pas de mu-plugin toe).
• Gebruik een WAF om virtueel te patchen terwijl u wacht op een pluginfix.
• Draai externe tokens en webhooks onmiddellijk.

Het beschermen van het vertrouwen van gebruikers is net zo belangrijk als het beschermen van de infrastructuur. Een paar minuten mitigatie nu kan een kostbaar incident later voorkomen.

Verdere lectuur en bronnen

(Dit zijn algemene onderwerpen om te verkennen — zoek naar gezaghebbende ontwikkelaar- en platformdocumentatie over veilige webhookverwerking, REST API-permissiecallbacks en veilige tokenopslag.)

• WordPress ontwikkelaarsdocumentatie: REST API permission_callback en best practices voor admin-ajax
• Platformdocumentatie: Facebook Developer-documentatie over app-tokens, webhooks en best practices voor tokenbeveiliging
• Webserver/WAF-documentatie: Hoe ModSecurity-regels en virtuele patches te schrijven
• Incidentresponsframeworks: behoud van logs, bewijsbehoud en meldingsworkflows

Als u de voorkeur geeft aan een praktische benadering en snelle mitigatie wilt met een beheerde WAF, malware-scanning en virtueel patchen dat bescherming biedt voor plugin-eindpunten, overweeg dan om u aan te melden voor het WP-Firewall Free Plan om onmiddellijk essentiële dekking te krijgen: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Blijf veilig en houd uw integraties strak,
Het WP-Firewall-beveiligingsteam