Pluginnaam	Zang
Type kwetsbaarheid	Toegangscontrole
CVE-nummer	CVE-2026-6441
Urgentie	Laag
CVE-publicatiedatum	2026-04-17
Bron-URL	CVE-2026-6441

Gebroken Toegangscontrole in de Canto WordPress Plugin (CVE-2026-6441) — Wat Site-eigenaren Nu Moeten Doen

Auteur: WP-Firewall Beveiligingsteam

Datum: 2026-04-18

Samenvatting: Een kwetsbaarheid in de gebroken toegangscontrole (CVE-2026-6441) die de Canto WordPress-plugin (versies ≤ 3.1.1) beïnvloedt, stelt geauthenticeerde gebruikers met Subscriber-rechten in staat om willekeurige plugin-instellingen te wijzigen. Deze post legt het risico uit, hoe aanvallers het kunnen misbruiken, onmiddellijke mitigatiestappen, langetermijnoplossingen voor ontwikkelaars, detectie- en incidentresponsrichtlijnen, en hoe WP-Firewall uw site kan beschermen — inclusief een gratis beschermingsoptie die u direct kunt inschakelen.

Inhoudsopgave

• Wat er is gebeurd (hoog niveau)
• Waarom dit belangrijk is voor WordPress-site-eigenaren
• Technisch overzicht van de kwetsbaarheid (niet-exploitatief)
• Realistische aanvalsscenario's en impact
• Onmiddellijke acties voor site-eigenaren (stapsgewijs)
• Hoe te detecteren of je het doelwit bent geweest of gecompromitteerd
• Versterking en ontwikkelingsoplossingen (voor plugin-auteurs en integrators)
• Aanbevolen WAF-regels en richtlijnen voor virtuele patching
• Checklist voor incidentrespons
• Hoe WP-Firewall uw site beschermt (en een optie om gratis te beginnen)
• Laatste opmerkingen en bronnen

---

Wat er is gebeurd (hoog niveau)

Een kwetsbaarheid in de gebroken toegangscontrole werd onthuld voor de Canto WordPress-plugin die versies tot en met 3.1.1 beïnvloedt. Vanwege ontbrekende autorisatiecontroles in een of meer server-side functies kan een geauthenticeerde gebruiker met alleen Subscriber-rechten verzoeken indienen die plugin-instellingen wijzigen. Hoewel Subscribers als laagprivilege-accounts in WordPress worden beschouwd, staan veel sites gebruikersregistratie toe of interageren ze met externe authenticatiestromen — wat deze soort fout interessant maakt voor aanvallers. Het probleem is toegewezen aan CVE-2026-6441 en beoordeeld als lage ernst in het CVSS-systeem; echter, “laag” betekent niet “negeren.” Toegangscontroleproblemen worden vaak gebruikt als opstapjes in grotere compromitteringsketens.

Waarom dit belangrijk is voor WordPress-site-eigenaren

WordPress-sites hebben vaak gebruikers met toegang op Subscriber-niveau (commentatoren, ingelogde klanten, geregistreerde leden). Site-eigenaren onderschatten vaak wat die accounts kunnen doen als een plugin per ongeluk binnenkomende verzoeken vertrouwt. Zelfs wanneer een kwetsbaarheid een laagprivilege-gebruiker de mogelijkheid geeft om de configuratie van een plugin te wijzigen, kunnen de gevolgen aanzienlijk zijn:

• Plugin-instellingen kunnen functies inschakelen die een aanvaller misbruikt om inhoud in te voegen, bezoekers om te leiden of gegevens bloot te stellen.
• Kwaadaardige wijzigingen kunnen persistente achterdeurtjes creëren of andere beveiligingsbeschermingen verzwakken.
• Aanvallers kunnen laagprivilege-accounts gebruiken als draaipunten voor privilege-escalatie of sociale engineering.
• In multi-site of lidmaatschapscontexten kunnen instellingenwijzigingen veel gebruikers beïnvloeden.

Omdat deze kwetsbaarheid willekeurige instellingwijzigingen toestaat, moet deze snel worden aangepakt, zelfs als de onmiddellijke impact beperkt lijkt.

Technisch overzicht (niet-exploitatief)

Ik zal geen exploitcode of stapsgewijze instructies publiceren om de aanval te reproduceren. In plaats daarvan is hier een veilige, technische beschrijving zodat beheerders en ontwikkelaars de oorzaak en mitigatie kunnen begrijpen:

• Oorzaak: Ontbrekende autorisatiecontroles in een server-side handler die verzoeken accepteert om pluginopties bij te werken. De handler verifieerde niet of de huidige gebruiker over een voldoende capaciteit beschikt (bijv., beheeropties) of valideerde geen nonce/token of adequate permissiecallback wanneer deze via REST/AJAX werd blootgesteld.
• Betrokken onderdeel: Een instellingen-update-eindpunt (HTTP POST) dat pluginopties wijzigt.
• Uitbuitbaar door: Elke geauthenticeerde gebruiker die de rol Subscriber is toegewezen (of een rol die kan inloggen maar geen administratieve mogelijkheden heeft).
• Resultaat: Aanvallers kunnen willekeurige door de plugin gecontroleerde instellingen wijzigen (die API-sleutels, URL's, functie-instellingen of andere door de plugin gecontroleerde opties kunnen omvatten).

Omdat deze fout fundamenteel een omissie in de autorisatiecontrole is, draaien de juiste oplossingen om het afdwingen van capaciteitscontroles, nonce-validatie en juiste machtigingscallback op alle eindpunten die persistente configuratie wijzigen.

Realistische aanvalscenario's en potentiële impact

Hoewel een Subscriber-account laaggeprivilegieerd is, zijn hier realistische manieren waarop een aanvaller deze kwetsbaarheid zou kunnen misbruiken en wat ze zouden kunnen bereiken:

1. Wapenen van instellingen om inclusie van externe inhoud mogelijk te maken
   • De plugin kan instellingen hebben die externe eindpunten of inhoudsbronnen definiëren. Deze wijzigen naar door de aanvaller gecontroleerde servers maakt inhoudsinjectie, adverteerdersovernames of drive-by malware-hosting mogelijk.
2. Debug- of gedetailleerde modus inschakelen
   • Sommige plugininstellingen schakelen debuglogging of gedetailleerde foutrapportage in. Zet deze aan om omgevings- of configuratiegegevens te lekken die nuttig zijn voor verdere aanvallen.
3. API-sleutels of integraties vervangen
   • Als de plugin integratiesleutels opslaat (voor activabibliotheken, mediasources of externe diensten), kan een aanvaller deze vervangen door hun eigen sleutels en media onderscheppen of toegang krijgen.
4. Een backdoorconfiguratie persistent maken
   • Wijzig instellingen om een persistente verborgen eindpunt te creëren, of schakel een functie in die bestandsuploads zonder juiste controles mogelijk maakt.
5. Sociale engineering escalatie
   • Wijzig UI-kopie, omleidingsstromen of meldings-eindpunten om phishingcampagnes tegen sitegebruikers of beheerders uit te voeren.

Geen van bovenstaande vereist dat de aanvaller een nieuw beheerdersaccount aanmaakt — ze misbruiken de logica van de plugin om hun doelen te bereiken.

Onmiddellijke acties voor site-eigenaren (stapsgewijs)

Als je WordPress draait en de Canto-plugin is geïnstalleerd (controleer je pluginlijst), volg dan onmiddellijk deze stappen:

1. Controleer je pluginversie
   • Als je plugin versie 3.1.1 of eerder is, behandel de site dan als potentieel kwetsbaar.
2. Als het mogelijk is, werk de plugin bij
   • De beste oplossing is om te updaten naar een gepatchte versie. Als er nog geen vendorpatch beschikbaar is, ga dan verder met de mitigatiestappen hieronder.
3. Verwijder of deactiveer de plugin (als je niet kunt patchen)
   • Als de plugin niet essentieel is en er geen vendorpatch beschikbaar is, deactiveer en verwijder deze totdat een gefixte release is gepubliceerd.
4. Beperk nieuwe registraties en controleer gebruikersrollen
   • Schakel tijdelijke open registratie uit (Instellingen → Algemeen → Lidmaatschap).
   • Controleer accounts met Subscriber-niveau privileges en verwijder verdachte of ongebruikte accounts.
5. Controleer recente configuratiewijzigingen
   • Inspecteer wp_opties voor vermeldingen met betrekking tot de plugin (gebruik phpMyAdmin, WP‑CLI of admin UI).
   • Controleer logs op POST-verzoeken naar plugin-eindpunten van subscriber-accounts.
6. Versterk gebruikersauthenticatie
   • Dwing wachtwoordreset af voor gebruikers waar nodig.
   • Schakel tweefactorauthenticatie (2FA) in voor administratoraccounts.
7. Voer een malwarescan uit
   • Gebruik een gerenommeerde scanner om naar gewijzigde bestanden, verdachte geplande taken en webshells te zoeken.
8. Maak een back-up van je site
   • Maak onmiddellijk een volledige back-up (bestanden + database) — sla deze offline op. Als je later moet terugrollen, behoudt dit de huidige staat voor forensische analyse.

Hoe te detecteren of je het doelwit bent geweest of gecompromitteerd

Detectie is vaak eenvoudig als je weet waar je moet kijken. Focus op deze signalen:

• Auditlogboeken
  • Zoek naar POST-verzoeken van geauthenticeerde niet-beheerder gebruikers die gericht zijn op plugin-eindpunten of admin-ajax.php acties die verband houden met de plugin.
• Optiewijzigingen
  • Vergelijk huidige pluginopties met bekende goede waarden. Optienamen zijn vaak voorafgegaan door de plugin-slug.
• Onbekende API-sleutels of eindpunten in instellingen
  • Elke nieuwe URL of API-inloggegevens moet als verdacht worden beschouwd.
• Nieuwe geplande taken (cron jobs)
  • Verifiëren wp_cron vermeldingen voor onbekende callbacks.
• Webserverlogboeken
  • Zoek naar onverwachte POST's of verzoeken door dezelfde user agent of IP die gericht zijn op plugin-routes.
• Onverwachte omleidingen of inhoudswijzigingen
  • Blader door belangrijke pagina's en controleer op onverwacht gedrag of geïnjecteerde scripts. Wees voorzichtig met het bezoeken van potentiële kwaadaardige omleidingen op productiesystemen zonder beveiligingen.

Als je verdachte activiteit vindt:

• Exporteer logboeken en relevante database-rijen voor onderzoek.
• Isolateer de site (onderhoudsmodus) terwijl u onderzoekt om de impact op gebruikers te minimaliseren.
• Overweeg om een ervaren incident responder in te schakelen als u tekenen van compromittering vindt.

Versterking en ontwikkelingsoplossingen (voor plugin-auteurs en integrators)

Deze kwetsbaarheid is een klassiek voorbeeld van “ontbrekende autorisatie.” Ontwikkelaars moeten meerdere, gelaagde defensieve controles toepassen:

1. Beginsel van de minste privileges
   • Alleen gebruikers met de minimaal vereiste capaciteit mogen persistente instellingen wijzigen. Voor siteconfiguratie, gebruik huidige_gebruiker_kan('opties_beheren') of een nauwkeurig gedefinieerde capaciteit.
2. Nonce- en permissievalidatie
   • Voor admin-ajax en REST-eindpunten:
     • Voor AJAX: gebruik check_ajax_referer('your_nonce_action') en een expliciete capaciteitscontrole.
     • Voor REST: voeg een toe toestemming_callback in registreer_rest_route die verifieert huidige_gebruiker_kan() en aanvullende controles toe indien nodig.
3. Valideer binnenkomende gegevens
   • Zorg voor robuuste sanering en validatie voordat u naar de database schrijft. Gebruik sanitize_tekst_veld, wp_kses_post, intval, of een gestructureerde schema-validatie.
4. Vermijd het vertrouwen op client-side referenties
   • Vertrouw nooit op door de gebruiker aangeleverde rol- of capaciteitsgegevens. Evalueer altijd server-side met huidige_gebruiker_kan().
5. Log administratieve acties
   • Log wijzigingen in gevoelige opties, inclusief de actor, IP, tijdstempel en eerdere/nadat waarden. Bied een manier voor site-eigenaren om audit trails te bekijken.
6. Beveiligingsunit tests
   • Voeg tests toe die gebruikers met lage privileges simuleren die proberen toegang te krijgen tot beschermde handlers en bevestig dat ze 403/401-antwoorden ontvangen.
7. Beveiligingsbeoordelingen en code-audits
   • Neem autorisatiecontroles op in checklisten voor codebeoordelingen. Geautomatiseerde statische analyse kan ontbrekende capaciteitscontroles voor veelvoorkomende patronen markeren.

Aanbevolen WAF-regels en richtlijnen voor virtuele patching

Als een gepatchte pluginversie niet onmiddellijk beschikbaar is of je de plugin om zakelijke redenen niet kunt verwijderen, is virtueel patchen via je Web Application Firewall (WAF) een effectieve tijdelijke oplossing. Hieronder staan defensieve benaderingen die je kunt implementeren. Dit zijn defensieve voorbeelden - ze onthullen niet hoe je de kwetsbaarheid kunt misbruiken.

Algemene richtlijnen

• Blokkeer niet-geauthenticeerde verzoeken naar plugin-eindpunten die instellingen bijwerken.
• Beperk POST-verzoeken die instellingen wijzigen tot administratieve IP's of gebruikers met geauthenticeerde admin-cookies en geldige nonces.
• Monitor en blokkeer herhaalde verzoeken van hetzelfde IP die gericht zijn op de configuratie-eindpunten van de plugin.

Voorbeeld defensieve patronen (veilig, niet-exploitatief)

1. Blokkeer POSTs naar een bekend plugin-configuratiepad, tenzij verzoeken een geldige WordPress admin nonce bevatten of afkomstig zijn van admin IP's.
   • Regel (conceptueel):
     Als de verzoekmethode POST is en de URI overeenkomt /wp-admin/admin-ajax.php of /wp-json/.../canto of /wp-admin/options.php route geassocieerd met de plugin en het verzoek mist _wpnooit parameter (of de verwachte header) → blokkeer of daag uit.
2. Beperk acties van Subscriber-geauthenticeerde sessies die instellingen bijwerken.
3. Weiger POST-verzoeken die proberen optie-sleutels bij te werken die overeenkomen met het optie-prefix van de plugin, tenzij ze een geldige capaciteitscookie of nonce bevatten.

Voorbeeld ModSecurity-regel (illustratief)

# Conceptuele ModSecurity-regel (alleen illustratief)"

Uitleg: Deze regel probeert POSTs naar eindpunten die vaak worden gebruikt voor achtergrondupdates te weigeren wanneer het verzoek het WordPress nonce-veld niet bevat. Wijzig de URI-matcher om overeen te komen met de werkelijke plugin-routes en test in de monitorstand voordat je handhaaft.

nginx voorbeeld (conceptueel)

locatie ~* /wp-admin/admin-ajax.php {

Opmerking: Dit gaat ervan uit dat je een betrouwbare manier hebt om nonces op het proxy-niveau te valideren; in de praktijk vereist volledige validatie server-side logica. Gebruik proxy-gebaseerde controles spaarzaam en alleen als tijdelijke mitigatie.

Virtuele patchingdiensten

Virtuele patching (ook bekend als noodregels of een hotfix op het WAF-niveau) kan exploitpogingen blokkeren zonder de sitecode te wijzigen. Als je een beheerde WAF gebruikt, vraag dan om een virtuele patch om verzoeken te blokkeren die proberen plugininstellingen bij te werken zonder de juiste autorisatie.

Detectie-georiënteerde WAF-regels

In plaats van aanvankelijk outright te weigeren, overweeg een detectiemodus die logt en waarschuwt voor verdachte POST's naar de plugin-eindpunten vanuit door abonnees geauthenticeerde sessies. Dit helpt de regel te valideren en valse positieven te observeren.

Checklist voor incidentrespons

Als je vaststelt dat de kwetsbaarheid op je site is uitgebuit, volg dan deze incidentresponsflow:

1. Bevatten
   • Zet de site in onderhoudsmodus of blokkeer openbaar verkeer.
   • Deactiveer en verwijder de kwetsbare plugin.
2. Bewijsmateriaal bewaren
   • Exporteer logs (webserver, pluginlogs, toegangslogs).
   • Maak een snapshot van het bestandssysteem en de database (bewaar offline/lezen alleen).
3. Onderzoeken
   • Identificeer welke instellingen zijn gewijzigd en wanneer.
   • Zoek naar nieuwe beheerdersaccounts, gewijzigde bestanden, geplande taken of onbekende cronjobs.
4. Schoonmaken
   • Zet kwaadaardige instellingwijzigingen terug waar mogelijk.
   • Verwijder onbekende bestanden en backdoors. Als je niet zeker kunt zijn, breng de site dan naar een schone back-upbasis.
5. Herstellen
   • Herstel van bekende goede back-ups waar mogelijk.
   • Herinstalleer de plugin pas nadat de leverancier een patch heeft uitgebracht of je een geteste codefix hebt toegepast.
6. Herstellen
   • Draai alle inloggegevens die mogelijk zijn aangetast (API-sleutels, wachtwoorden van beheerdersgebruikers).
   • Controleer externe diensten op verdachte activiteit als sleutels in plugininstellingen waren opgeslagen.
7. Na het incident
   • Voer een oorzaak-analyse uit en implementeer sterkere controles: beperk registratie, implementeer WAF-regels en vereis 2FA voor bevoorrechte accounts.
   • Meld belanghebbenden en gebruikers als de inbreuk persoonlijke gegevens heeft aangetast, in overeenstemming met de toepasselijke wetten.

Hoe WP-Firewall je site beschermt

Als de ontwikkelaars en operators van WP-Firewall zien we deze patronen regelmatig. Ons product en onze diensten zijn ontworpen om de blootstellingsperiode voor kwetsbaarheden zoals deze te verkleinen:

• Beheerde webapplicatiefirewall (WAF)
  • Onze WAF kan virtuele patchregels toepassen om verdachte pogingen om plugininstellingen aan te passen aan de rand te blokkeren, zodat zelfs als er een kwetsbaarheid in de plugincode bestaat, kwaadaardige verzoeken nooit uw site bereiken.
• Malwarescanner
  • Regelmatige scans identificeren gewijzigde bestanden, verdachte PHP-code en indicatoren van compromittering, zodat u snel tekenen van exploitatie kunt detecteren.
• OWASP Top 10 mitigatie
  • De bescherming van WP-Firewall omvat mitigaties voor veelvoorkomende klassen van kwetsbaarheden (inclusief gebroken toegangscontrolepatronen), waardoor de kans op misbruik wordt verminderd.
• Gelaagde herstelopties
  • Ons gratis plan biedt essentiële bescherming (beheerde firewall, WAF, malware-scanning, OWASP-mitigaties).
  • Voor teams die meer automatisering nodig hebben, voegen onze betaalde plannen automatische malwareverwijdering, IP-blacklisting/witlisting, virtueel patchen, maandelijkse beveiligingsrapporten en optionele beheerde beveiligingsdiensten toe.

Bescherm uzelf in enkele minuten met het WP‑Firewall Gratis Plan

Als u snelle, betrouwbare bescherming wilt terwijl u evalueert of wacht op een vendor-patch, biedt ons Basis (Gratis) plan essentiële verdedigingen die u onmiddellijk kunt inschakelen:

• Beheerde firewall en WAF van ondernemingskwaliteit
• Onbeperkte bandbreedte (beschermde verkeersbuis)
• Malware-scanner om verdachte wijzigingen te detecteren
• Mitigatieregels voor OWASP Top 10-risico's

Meld u hier aan en schakel gratis bescherming in: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Als u de voorkeur geeft aan geautomatiseerd herstel en meer controle (automatische malwareverwijdering, IP-bloklijsten, virtueel patchen, maandelijkse rapporten en beheerde beveiligingsopties), kunnen onze Standaard- en Pro-plannen op elk moment worden geactiveerd.

Ontwikkelaarsrichtlijnen: checklist voor beveiliging bij ontwerp

Voor plugin-auteurs en ontwikkelingsteams, neem deze checklist-items over om soortgelijke kwetsbaarheden in de toekomst te vermijden:

• Vereis geschikte mogelijkheden voor alle instellingen eindpunten (veronderstel niet dat de context van ingelogde gebruikers voldoende is).
• Valideer nonces en toestemming callbacks voor REST-routes en AJAX-handlers.
• Handhaaf server-side validatie en outputcodering voor alle invoer en opgeslagen gegevens.
• Voeg geautomatiseerde tests toe die laaggeprivilegieerde gebruikers simuleren die proberen admin-gezichte acties aan te roepen.
• Neem logging op voor instellingenupdates en bied een auditinterface.
• Overweeg standaardconfiguraties met de minste privileges en vereis expliciete activatie van elke functie die risico's verhoogt (bijv. remote code inclusion, bestand upload opties).

Waarom procedurele controles belangrijk zijn
Beveiliging is niet alleen code — implementatie- en operationele controles (WAF, toegangscontrolelijsten, accountbeoordelingsbeleid en monitoring) verminderen de blootstelling en de kans dat een omissie in de code leidt tot compromittering.

Veelgestelde vragen

V: Mijn site gebruikt Canto-plugin versie ≤ 3.1.1 — is deze zeker gecompromitteerd?

A: Niet noodzakelijk. De kwetsbaarheid biedt een pad voor misbruik door geauthenticeerde Subscriber-accounts, maar exploitatie vereist dat een geauthenticeerde aanvaller specifieke acties onderneemt. Controleer uw logs, kijk naar gewijzigde opties en volg de detectiestappen hierboven.

V: Ik kan de plugin op dit moment niet verwijderen — wat is de snelste mitigatie?

A: Schakel een beheerde WAF of virtuele patch in die POST-updates naar de plugin-instellingen eindpunten blokkeert, tenzij ze geldige nonces bevatten of afkomstig zijn van vertrouwde admin IP's. Beperk registraties en beoordeel Subscriber-accounts onmiddellijk.

V: Is deze kwetsbaarheid direct uit te buiten door ongeauthenticeerde aanvallers?

A: Nee — de kwetsbaarheid vereist een geauthenticeerde gebruiker (Subscriber of vergelijkbaar). Echter, sites met open registratie of sites waar aanvallers accounts kunnen aanmaken, lopen risico.

V: Wat betreft back-ups? Moet ik herstellen vanuit een back-up?

A: Als u bewijs van exploitatie vindt (nieuwe instellingen, onbekende bestanden of backdoors), herstel dan vanuit een bekende goede back-up die vóór de wijzigingen is gemaakt en voer een volledige beoordeling uit voordat u de diensten opnieuw verbindt.

Slotgedachten

Kwetsbaarheden in gebroken toegangscontrole zijn bedrieglijk eenvoudige fouten met buitensporige gevolgen. In WordPress is het een veelvoorkomend patroon: de ontwikkelaar stelt een eindpunt of optie bloot zonder te verifiëren of de actor het recht heeft om die wijziging aan te brengen. Het goede nieuws is dat de verdedigingsmaatregelen eenvoudig toe te passen zijn: valideer mogelijkheden, handhaaf nonces, saniteer invoer en voeg WAF-bescherming toe.

Als u WordPress-sites beheert of runt, beschouw dit dan als een herinnering om:

• Plugins up-to-date te houden.
• Gebruikersrollen en registraties te auditen.
• Een gelaagde verdedigingsaanpak te gebruiken (codeversterking + WAF + monitoring).
• Onderhoud geteste back-ups en een incidentresponsplan.

Als u een snelle laag bescherming wilt terwijl u code-updates toepast of wacht op de patch van de leverancier, overweeg dan nu het inschakelen van het WP‑Firewall Basic (Gratis) plan: https://my.wp-firewall.com/buy/wp-firewall-free-plan/ — het biedt een beheerde WAF, malware-scanning en essentiële OWASP-mitigaties die de aanvalsvector voor problemen zoals CVE‑2026‑6441 drastisch verminderen.

Voor teams die voortdurende remediatie, geautomatiseerde respons of beheerde ondersteuning nodig hebben, bieden onze betaalde plannen extra automatisering en diensten — inclusief virtuele patching en beheerde verwijdering — om uw operationele last te verminderen.

Heeft u nu hulp nodig?

• Als je hulp nodig hebt bij het auditen van je site, het versterken van gebruikersrollen of het toepassen van WAF-regels, kan ons beveiligingsteam helpen. Neem contact op via onze ondersteuningskanalen en we zullen prioriteit geven aan triage voor actieve incidenten.

Bijlage: Snelle opdrachtfragmenten (veilig, administratief)

• Lijst pluginversies via WP‑CLI:

  wp plugin lijst --format=tabel
      

• Dumpopties gerelateerd aan een plugin om instellingen te inspecteren:

  wp db query "SELECT option_name, option_value FROM wp_options WHERE option_name LIKE 'nto%';"
      

• Zoek toeganglogs naar POST-verzoeken naar plugin-gerelateerde eindpunten (voorbeeld):

  grep -i "POST .*admin-ajax.php" /var/log/nginx/access.log | grep canto
      

Opmerking: Pas de queries aan op jouw omgeving. Voer altijd alleen-lezen queries uit bij het onderzoeken.

---

We zullen deze post bijwerken als de pluginleverancier een officiële patch uitbrengt of als er nieuwe technische details beschikbaar komen. Volg in de tussentijd de hierboven genoemde mitigatiestappen en overweeg om WP‑Firewall-bescherming in te schakelen om snel het risico te verminderen.

Let op je veiligheid,
WP-Firewall Beveiligingsteam