Pluginnaam	WP Voorwaarden Popup
Type kwetsbaarheid	Toegangscontrole Kw vulnerability
CVE-nummer	CVE-2026-32495
Urgentie	Hoog
CVE-publicatiedatum	2026-03-22
Bron-URL	CVE-2026-32495

Gebroken Toegangscontrole in WP Terms Popup (CVE-2026-32495): Wat WordPress Site-eigenaren Moeten Weten en Hoe Ze Zichzelf Kunnen Beschermen

Kortom

• Een kwetsbaarheid in gebroken toegangscontrole die WP Terms Popup versies <= 2.10.0 (CVE-2026-32495) beïnvloedt, werd openbaar gemaakt in maart 2026.
• De ontwikkelaar heeft versie 2.11.0 uitgebracht met een patch.
• Aanvallers kunnen mogelijk acties met hogere privileges van de plugin activeren zonder de juiste authenticatie/autorisatiecontroles.
• Onmiddellijke actie: update naar 2.11.0 of later. Als je niet onmiddellijk kunt updaten, implementeer dan virtuele patches / WAF-regels, verstevig REST/AJAX-eindpunten en monitor logs.
• Dit artikel legt de technische achtergrond, risicoscenario's, detectie aanwijzingen en verdedigingsstappen uit die je kunt implementeren als site-eigenaar of administrator.

Waarom dit belangrijk is (en waarom je dit zou moeten lezen)

Als WordPress site-eigenaren beheren we een divers ecosysteem van plugins. Veel plugins bieden gemak door admin-acties bloot te stellen via AJAX-eindpunten of REST API-routes. Als die acties geen juiste authenticatie hebben (nonce-controles, capaciteitscontroles of correcte gebruikerssessie-validatie), kunnen ze worden geactiveerd door niet-geauthenticeerde actoren - een klassiek geval van gebroken toegangscontrole.

Dit specifieke probleem in WP Terms Popup werd gevonden door een beveiligingsonderzoeker en kreeg CVE-2026-32495 toegewezen. Hoewel de openbare waarschuwing aangeeft dat de kwetsbaarheid een beperkte impact heeft in veelvoorkomende scenario's, is het aanvalspatroon (niet-geauthenticeerde toegang tot functies die een hoger privilege veronderstellen) precies het soort fout dat wordt uitgebuit door geautomatiseerde massascanningcampagnes. Dus zelfs “lage” of “matige” ernst bugs kunnen leiden tot echte compromittering op grote schaal.

Deze post is geschreven vanuit het perspectief van een WordPress-firewall en beveiligingsprovider die deze vectoren dagelijks ziet. Mijn doel is om je een duidelijk, actiegericht plan te geven: snelle mitigaties, detectie-instructies en langdurige versteviging.

Wat we weten (samenvatting van de waarschuwing)

• Beïnvloede plugin: WP Terms Popup (WordPress-plugin)
• Kwetsbare versies: alle versies tot en met 2.10.0
• Gepatcht in: 2.11.0
• Kwetsbaarheidstype: Gebroken Toegangscontrole (OWASP A01)
• CVE: CVE-2026-32495
• Gerapporteerd door: beveiligingsonderzoeker (gepubliceerd maart 2026)
• Vereiste privilege: Niet-geauthenticeerd (wat betekent dat aanvallers zonder geldige inlogsessies kunnen proberen te exploiteren)
• Patch/mitigatie: plugin-update naar 2.11.0; virtuele patches via WAF ook effectief totdat de update is toegepast

Opmerkingen:
De adviesranking geeft de prioriteit aan als “Laag” in de prioritering van de leverancier, maar de CVSS-vector die in de openbare vermelding wordt gebruikt, resulteert in een score van bijna 7,5. Dat verschil benadrukt een veelvoorkomende realiteit: numerieke scores alleen vertellen niet het hele verhaal voor WordPress-sites. Context is belangrijk: welke actie kan worden bereikt door het kwetsbare eindpunt, en hoe vaak wordt die actie gebruikt door plugins op een site.

Wat “Gebroken Toegangscontrole” in de praktijk eigenlijk betekent

Gebroken toegangscontrole is een verzamelterm die ontbrekende of inadequate controles dekt die voorkomen dat ongeautoriseerde gebruikers acties uitvoeren die voor hogere privilege-niveaus zijn gereserveerd. In WordPress-plugins neemt dit meestal een van de weinige vormen aan:

• Ontbrekende nonce-verificatie voor AJAX/REST-acties. Nonces helpen beschermen tegen CSRF en geven aan dat de actie is geactiveerd door een legitieme verzoekstroom.
• Ontbrekende capaciteitscontroles (bijv. niet verifiëren of current_user_can(‘manage_options’)) — waardoor niet-geauthenticeerde of laaggeprivilegieerde gebruikers admin-niveau acties kunnen uitvoeren.
• Aannames dat een verzoek dat een admin-eindpunt bereikt alleen van ingelogde gebruikers kan komen; in de praktijk zijn veel eindpunten bereikbaar vanaf het openbare web.
• Onjuist blootgestelde REST API-routes die zijn verklaard met openbare toegang maar beperkt zouden moeten zijn.

Wanneer een aanvaller een actie kan aanroepen die configuratie wijzigt, inhoud schrijft of gedrag verandert, kan hij dit gebruiken als een opstapje voor compromittering. Zelfs als een aanvaller slechts een beperkte wijziging kan aanbrengen, kan dit worden gekoppeld aan andere zwakheden (zwakke inloggegevens, verouderde kern of andere plugins) om te escaleren.

Plausibele aanvalscenario's voor CVE-2026-32495

Het advies publiceert geen exploitcode; dat is een verantwoordelijke openbaarmakingspraktijk. Op basis van de classificatie (Gebroken Toegangscontrole, niet-geauthenticeerd), zijn hier realistische scenario's die aanvallers kunnen proberen:

1. Geautomatiseerde massascans: bots onderzoeken bekende plugin-eindpunten en proberen veelvoorkomende actienamen of parameters. Als het eindpunt een admin-operatie uitvoert zonder controles, slaagt de bot en compromitteert de massascankampagne duizenden sites.
2. UX/phishing-stijl manipulaties: als de plugin inhoud opslaat of weergeeft (bijvoorbeeld, voorwaarden of pop-ups die links/scripts bevatten), kan een niet-geauthenticeerde wijziging kwaadaardige JavaScript of omleidingslinks invoegen.
3. Configuratie-tampering: de aanvaller verandert het gedrag van pop-ups om gegevens te exfiltreren (bijv. het vastleggen van e-mailadressen) of om formulieren in te voegen die inloggegevens doorsturen.
4. Pivoteren: wijzig plugin-instellingen om debug/log-lekken in te schakelen, of maak een nieuwe admin-gebruiker aan als het eindpunt gebruikerscreatie toestaat, en neem dan de site over.
5. Gecombineerde aanvallen: aanvallers combineren de gebroken toegangscontrole met zwakke admin-inloggegevens, bestandspermissieproblemen of andere plugin-kwetsbaarheden om een site volledig te compromitteren.

Zelfs als een site-eigenaar denkt dat de pluginfunctie niet kritisch is, is de aanwezigheid van een niet-geauthenticeerd toegangspunt waardevol voor aanvallers.

Detectie — waar te zoeken in logs en dashboards

Het detecteren van pogingen tot exploitatie is belangrijk. Hier zijn praktische indicatoren om te monitoren:

• Onverwachte POST/GET-verzoeken naar admin-gerelateerde eindpunten van externe IP's (bijv. verzoeken naar /wp-admin/admin-ajax.php of naar plugin-specifieke eindpunten).
• Verzoeken die ongebruikelijke actieparameters bevatten (bijvoorbeeld, verdachte strings in het ‘action’ POST-veld of REST-eindpunt-URL's die naar de plugin verwijzen).
• Snelle herhaalde verzoeken naar dezelfde plugin-eindpunt vanaf hetzelfde IP of een klein bereik (automatische scanner gedrag).
• Plotselinge veranderingen in plugin-instellingen of popup-inhoud (tijdstempels en inhoudsverschillen).
• Nieuwe of gewijzigde bestanden in mappen waar de plugin middelen of sjablonen opslaat.
• Toename van 4xx/5xx reacties van wp-admin/admin-ajax.php of REST-eindpunten — aanvallers die eindpunten onderzoeken krijgen vaak deze voordat ze een omweg vinden.
• Anomalieën in gebruikerscreatie-evenementen, vooral van niet-geauthenticeerde of API-bronnen.

Als je een beveiligings/logoplossing (WAF, serverlogs, externe logging) gebruikt, zoek dan naar POST-verzoeken naar eindpunten of de aanwezigheid van bekende indicatoren (bijv. specifieke parameter namen indien beschikbaar). Als je geen gecentraliseerde logging hebt, schakel dan toegangslogging in en exporteer logs voor analyse.

Onmiddellijke mitigaties — wat nu te doen (geordend op prioriteit)

1. Update de plugin naar versie 2.11.0 of later — doe dit eerst. De ontwikkelaar heeft een patch gepubliceerd; dit is de meest betrouwbare oplossing.
2. Als je niet onmiddellijk kunt updaten (compatibiliteit, stagingbehoeften), pas virtuele patches toe:
   • Blokkeer openbare toegang tot alle plugin-eindpunten die alleen nodig zijn voor admingebruik.
   • Blokkeer verdachte POST-verzoeken met specifieke actienamen die aan de plugin zijn gekoppeld.
   • Handhaaf rate limiting voor verzoeken naar plugin-eindpunten.
   • Beperk REST API-eindpunten of admin-ajax-acties tot specifieke geauthenticeerde sessies of IP-bereiken.
3. Controleer op indicatoren van compromittering (zie Detectie). Als je bewijs van exploitatie vindt, isoleer de site: maak back-ups, draai admin-wachtwoorden en controleer gebruikersaccounts.
4. Versterk de WordPress-installatie:
   • Zorg ervoor dat er alleen vertrouwde admin-gebruikers zijn en controleer gebruikersrollen/mogelijkheden.
   • Schakel bestandsbewerking via WP uit (define(‘DISALLOW_FILE_EDIT’, true)).
   • Controleer plugins/thema's en deactiveer ongebruikte plugins.
5. Herstel vanaf een schone back-up als je kwaadaardige wijzigingen detecteert die niet schoon kunnen worden hersteld.
6. Implementeer een WAF-regel om de aanvalsvectoren te blokkeren terwijl je bijwerkt (voorbeeldregels hieronder inbegrepen).

Voorbeeld mitigatie: PHP-niveau controles (voor plugin auteurs / ontwikkelaars)

Als je de code onderhoudt (of tijdelijke mu-plugin bescherming wilt bieden), hier zijn veilige voorbeelden van hoe eindpunten verzoeken moeten valideren. Dit zijn generieke best-practice controles — ze onthullen geen exploit details.

Voorbeeld: Controleer nonce en bevoegdheid voor een actiehandler

// Voorbeeld: Bescherm een admin-post of admin-ajax handler

Als de problematische actie ontbreekt aan nonce verificatie of bevoegdheid controles, zal het toevoegen hiervan het risico verminderen. Je moet echter alleen codewijzigingen toepassen als je je comfortabel voelt met PHP en een getest staging-omgeving hebt. De aanbevolen oplossing blijft het bijwerken naar de door de leverancier geleverde 2.11.0.

Voorbeeld WAF-regels en virtuele patches (patronen die je kunt implementeren in WP-Firewall of server firewall)

Hieronder staan voorgestelde regelvoorbeelden die verdachte verzoeken blokkeren of monitoren. Ze zijn in leesbare termen uitgedrukt; je WAF/admin-interface accepteert doorgaans equivalente voorwaarden.

1. Blokkeer niet-geauthenticeerde POST-verzoeken naar admin-ajax.php met verdachte actieparameter
   • Als het verzoekpad gelijk is aan /wp-admin/admin-ajax.php EN de methode POST is EN het verzoek geen geldige ingelogde cookie bevat EN de verzoekparameter “action” gelijk is aan een van [wp_terms_popup_save, wp_terms_popup_update, …] (vervang door waargenomen actienamen), blokkeer dan/403.
2. Blokkeer directe toegang tot de AJAX of REST eindpunten van de plugin vanuit het publiek:
   • Als het verzoekpad overeenkomt met /wp-content/plugins/wp-terms-popup/*/ajax of /wp-json/wp-terms-popup/* en het verzoek geen geldige authenticatie/nonce headers bevat, blokkeer dan.
3. Beperk of daag herhaalde verzoeken uit
   • Als hetzelfde IP admin-ajax.php of de plugin eindpunten meer dan N keer in 60 seconden opvraagt, leg dan CAPTCHA of tijdelijke blokkade op.
4. Blokkeer verdachte gebruikersagenten en bekende scannerhandtekeningen
   • Stel regels in om niet-browser gebruikersagenten die door massascanners worden gebruikt te blokkeren.
5. Geo-gebaseerde of reputatie-gebaseerde weigering voor hoog-risico IP's
   • Als je een weigeringlijst of IP-reputatiefeed onderhoudt, blokkeer of daag tijdelijk binnenkomende verzoeken uit van nieuw waargenomen hoog-risico bereiken.

Praktisch voorbeeld (pseudo-modsec regel ter referentie):

SecRule REQUEST_URI "@rx /wp-admin/admin-ajax\.php" \"

Opmerkingen:

• Implementeer geen te brede regels die legitiem verkeer blokkeren. Test altijd in de monitoringsmodus voordat je overschakelt naar de blokkermodus.
• Houd een tijdelijke whitelist bij voor bekende admin-IP's indien nodig tijdens het implementeren van regels.

Checklist na de update (wat te doen nadat je hebt gepatcht)

1. Update naar WP Terms Popup 2.11.0 (of later). Controleer de pluginversie in het WordPress-dashboard.
2. Wis caches (serverzijde, CDN, objectcache) om ervoor te zorgen dat de gepatchte code wordt geleverd.
3. Scan je site opnieuw met een malware-scanner en controleer de bestandsintegriteit. Focus op pluginmappen en wp-content/uploads.
4. Controleer gebruikersaccounts en reset wachtwoorden voor administratieve accounts als je enige reden hebt om aan te nemen dat ze zijn gecompromitteerd.
5. Bekijk de WordPress-debuglogs en toegangslogs van de afgelopen 30 dagen op tekenen van exploitatie (zie sectie Detectie).
6. Schakel monitoring en waarschuwingen in/bevestig voor toegang tot plugin-eindpunten en verdachte wijzigingen.
7. Implementeer automatische updates voor plugins met een gecontroleerd beleid, of abonneer je op beheerde automatische updatesystemen als je meer controle nodig hebt.

Waarom de CVSS-score versus “echte wereld” prioriteit kan verschillen

Je kunt een numerieke CVSS-score zien (de openbare vermelding toont 7.5 in sommige contexten), maar tegelijkertijd wordt de kwetsbaarheid door een ontdekkingsteam als “lage prioriteit” vermeld. Er zijn goede redenen waarom deze discrepantie optreedt:

• CVSS kijkt naar technische parameters (aanvalsvector, aanvalcomplexiteit, vereiste privileges, gebruikersinteractie, enz.). Het meet niet altijd de werkelijke gevolgen in de zakelijke context van je site.
• De exploitabiliteit in de echte wereld van een bepaald eindpunt hangt af van wat de actie daadwerkelijk doet. Als een gebroken toegangscontrole het mogelijk maakt om een niet-gevoelige UI-string te wijzigen, is dat technisch gezien een kwetsbaarheid, maar met een lagere zakelijke impact dan eentje die een admin-gebruiker toevoegt, willekeurige code uitvoert of kerninstellingen wijzigt.
• WordPress-sites verschillen sterk: wat op de ene site een lage impact heeft (een wijziging in een marketingpopup) kan op een andere site een hoge impact hebben (als de popup wordt gebruikt om betalingen of leads vast te leggen).

Neem als site-eigenaar het slechtste aan, tenzij je kunt bevestigen dat de daadwerkelijke actie onschadelijk is.

Praktische stappen voor incidentrespons als je bewijs van compromittering vindt

Als je een daadwerkelijke compromittering detecteert (gewijzigde pluginbestanden, kwaadaardige popups die aan bezoekers worden getoond, nieuwe admin-gebruikers):

1. Neem de site offline voor bezoekers (onderhoudsmodus) indien nodig om verdere schade te voorkomen.
2. Maak een snapshot en bewaar logs en back-ups — ze zijn cruciaal voor forensische analyse.
3. Wijzig alle administratieve wachtwoorden (WordPress-gebruikers, hosting, database) en roteer API-sleutels.
4. Werk de kern, plugins en thema's bij naar gepatchte versies in de omgeving.
5. Vervang gewijzigde bestanden vanuit een schone back-up of herinstalleer de plugin/thema vanuit officiële bronnen.
6. Zoek naar en verwijder kwaadaardige code (backdoors in uploads, gewijzigde thema's, enz.). Als je twijfelt, schakel dan ervaren incident responders in.
7. Beoordeel de serverconfiguratie op onverwachte cron-taken, geplande taken of nieuwe admin-accounts.
8. Communiceer met belanghebbenden en, indien nodig, regelgevende autoriteiten (afhankelijk van gegevensblootstelling).

Aanbevelingen voor langdurige verharding (defense-in-depth)

1. WAF + virtuele patches: Implementeer een goed onderhouden Web Application Firewall die snel virtuele patches kan toepassen. Dit koopt tijd voor het testen en implementeren van door de leverancier geleverde patches.
2. Minimale privileges: Controleer regelmatig gebruikersrollen en mogelijkheden. Geef alleen ‘administrator’ wanneer absoluut noodzakelijk.
3. Beheer van de levenscyclus van plugins:
   • Verwijder ongebruikte plugins en thema's.
   • Houd een inventaris bij van plugins en hun update-cyclestatus.
   • Test updates in staging voordat je ze in productie neemt waar praktisch mogelijk.
4. Logging & monitoring:
   • Gecentraliseerde logging van webverzoeken en admin-acties.
   • Meldingen voor ongebruikelijke pieken in verkeer naar admin-eindpunten.
   • Periodieke controles van de bestandintegriteit.
5. Back-ups:
   • Houd regelmatige, externe back-ups met versiebeheer.
   • Test regelmatig herstelprocedures.
6. Automatisering & updates:
   • Gebruik een beheerde strategie voor automatische updates (gestapeld of selectief) om ervoor te zorgen dat kritieke beveiligingsfixes snel worden toegepast.
7. Veilige configuratie:
   • Schakel bestandsbewerking in het dashboard uit.
   • Gebruik veilige bestandsmachtigingen.
   • Versterk PHP (deactiveer exec/system waar niet nodig).
   • Zorg ervoor dat de hostingomgeving (OS, webserver) is gepatcht.
8. Incidentrespons-handboek:
   • Heb een gedocumenteerde procedure voor het omgaan met compromissen (wie te bellen, hoe te herstellen, communicatietemplates).

Hoe een WordPress-firewall helpt in deze situatie

Uit onze ervaring met het beschermen van WordPress-sites op grote schaal, is de meest effectieve kortetermijnmaatregel wanneer een plugin-kwetsbaarheid wordt onthuld, het combineren van onmiddellijke plugin-updates met gerichte WAF-regels. Een WAF kan:

• Aanvalspogingen blokkeren die gericht zijn op de kwetsbare eindpunten of actienamen voordat ze WordPress bereiken.
• Virtuele patching toepassen voor sites die niet onmiddellijk kunnen updaten.
• Rate-limit geautomatiseerde scanners en bots die op zoek zijn naar kwetsbare plugins.
• Site-eigenaren waarschuwen wanneer gewapende patronen worden waargenomen (zodat je kunt onderzoeken).
• Logs en forensische gegevens verstrekken om te helpen bepalen of er pogingen succesvol waren.

Vergeet niet: een WAF is geen vervanging voor het toepassen van vendor-patches. Het is een laag die het risico vermindert terwijl je update.

Aanbevolen detectiequeries (voor logs / SIEM / WAF)

Gebruik deze voorbeeldzoekopdrachten om verdachte activiteiten met betrekking tot deze plugin-kwetsbaarheid te controleren:

1. Webserverlogs (nginx/apache):
   • Zoek naar verzoeken waarbij de URI “wp-terms-popup” bevat of verzoeken naar admin-ajax.php met verdachte actie-waarden in de afgelopen 30 dagen.
2. WAF-logboeken:
   • Filter evenementen waarbij de regel overeenkwam met admin-ajax POST met actieparameter of waar REST-eindpunten onder /wp-json plugin-specifieke paden bevatten.
3. WordPress-activiteitslogboeken:
   • Zoek naar ongeautoriseerde optie-updates of inhoudswijzigingen die verband houden met de plugin.
4. Bestandssysteem:
   • Lijst recent gewijzigde bestanden onder wp-content/plugins/wp-terms-popup en wp-content/uploads.

Veelgestelde vragen

Q: Ik gebruik WP Terms Popup, maar ik stel geen gevoelige gegevens bloot in mijn popup. Is dit nog steeds een probleem?
A: Ja. Zelfs als de inhoud van de popup zelf laaggevoelig is, biedt de mogelijkheid om plugininstellingen of inhoud zonder authenticatie te wijzigen aanvallers een kans. Het kan worden gebruikt om bezoekers te phishing, malware te leveren of naar andere kwetsbaarheden te schakelen.

Q: Ik heb geüpdatet naar 2.11.0 — ben ik veilig?
A: Updaten naar 2.11.0 is de belangrijkste oplossing en lost het specifieke probleem met gebroken toegangscontrole op. Bevestig na de update dat er geen tekenen van eerdere exploitatie zijn (scan, controleer logs, verifieer inhoud). Volg de checklist na de update in dit artikel.

Q: Ik kan niet updaten vanwege een compatibiliteitsprobleem. Wat nu?
A: Pas virtuele patches toe via je firewall (blokkeer specifieke eindpunten en acties), beperk de toegang via .htaccess of serverregels tot admin IP's, en plan een gecontroleerd updatepad (testen in staging en dan productie). Overweeg een beheerde beveiligingsprovider te gebruiken als je hulp nodig hebt.

Begin vandaag nog met het beschermen van je site — Gratis Plan

Als je een eenvoudige manier wilt om je WordPress-sites te beschermen tegen kwetsbaarheden zoals CVE-2026-32495, overweeg dan te beginnen met het WP‑Firewall Basic (Gratis) plan. Het biedt essentiële bescherming — een beheerde firewall, WAF-regels, malware-scanning en mitigatie van OWASP Top 10-risico's — en kan onmiddellijke virtuele patchdekking bieden terwijl je pluginupdates plant. Voor veel site-eigenaren vermindert deze eerste verdedigingslaag het risico drastisch zonder enige voorafgaande kosten. Leer meer en meld je aan op:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Opmerking: betaalde niveaus breiden de bescherming uit — automatische malwareverwijdering, IP-blacklisting, maandelijkse beveiligingsrapporten, automatische virtuele patching en premium ondersteuning — die nuttig zijn naarmate je site en risicoprofiel groeien.

Praktische checklist die je kunt kopiëren en gebruiken

1. Update WP Terms Popup naar v2.11.0 (of later).
2. Wis alle caches en CDN-caches.
3. Scan op indicatoren van compromittering (bestanden, inhoud, gebruikers).
4. Als u niet onmiddellijk kunt updaten:
   • Blokkeer plugin-eindpunten in WAF.
   • Beperk aanvragen naar admin-ajax.php en plugin REST-routes.
   • Beperk de toegang per IP tot adminpagina's waar mogelijk.
5. Beoordeel gebruikersaccounts en reset adminwachtwoorden.
6. Schakel offsite back-ups in/bevestig en test herstel.
7. Implementeer logging en waarschuwingen voor admin-eindpuntactiviteit.
8. Overweeg een beheerde firewall of virtuele patchoplossing terwijl je updates toepast.

Laatste woorden — beschouw elke openbaarmaking als een kans om de beveiliging te verbeteren

Kwetsbaarheden zoals CVE-2026-32495 versterken een eenvoudige waarheid: beveiliging is een doorlopend proces. De onmiddellijke oplossing is bijna altijd om te updaten. De strategische oplossing is om lagen op te bouwen — goede operationele hygiëne, tijdige patching, logging en waarschuwingen, en beschermende controles zoals een WAF.

Als je meerdere WordPress-sites beheert of klantomgevingen beheert, verwerk deze stappen in je operationele handboek: inventariseer plugins, houd toezicht op openbaarmakingen, test patches in staging en houd een snelle mitigatieroute gereed (virtuele patches) zodat je sites onmiddellijk kunt beschermen wanneer er een openbaarmaking plaatsvindt.

Als je hulp nodig hebt bij het implementeren van de hierboven beschreven mitigaties of assistentie wilt bij het beoordelen of je site het doelwit was, neem dan contact op met een vertrouwde beveiligingsprovider of je hostingteam. In de onmiddellijke termijn, werk WP Terms Popup bij naar 2.11.0 — en overweeg een beschermende WAF-laag toe te voegen om risico's te mitigeren terwijl je normaal onderhoud uitvoert.

Let op je veiligheid,
WP-Firewall Beveiligingsteam