Pluginnaam	WordPress MStore API-plugin
Type kwetsbaarheid	Onveilige Direct Object Reference (IDOR)
CVE-nummer	CVE-2026-3568
Urgentie	Laag
CVE-publicatiedatum	2026-04-09
Bron-URL	CVE-2026-3568

Onveilige directe objectreferentie (IDOR) in de MStore API Plugin (<= 4.18.3) — Wat WordPress-site-eigenaren moeten weten en hoe ze hun sites kunnen beschermen

Auteur: WP-Firewall Beveiligingsteam
Datum: 2026-04-10
Trefwoorden: WordPress, Beveiliging, Kwetsbaarheid, IDOR, MStore API, WAF, Incidentrespons

Samenvatting: Een onveilige directe objectreferentie (IDOR) kwetsbaarheid die de MStore API-plugin (versies tot en met 4.18.3) beïnvloedt, stelt een geauthenticeerde gebruiker met lage privileges (abonnee of vergelijkbaar) in staat om willekeurige gebruikersmeta op een WordPress-site bij te werken. De kwetsbaarheid is toegewezen aan CVE-2026-3568 en heeft een CVSS-score van 4.3 (Laag). Hoewel geclassificeerd als lage ernst, hangt de praktische impact af van welke gebruikersmeta-sleutels kunnen worden gewijzigd — in sommige gevallen kan exploitatie leiden tot privilege-escalatie, accountmanipulatie of sessie-tampering. Deze post legt uit hoe de fout werkt, de risico's in de echte wereld, detectiestappen, mitigaties en aanbevolen verhardingspraktijken — inclusief onmiddellijke acties die moeten worden ondernomen en hoe WP-Firewall kan helpen uw site te beschermen.

---

Inhoudsopgave

• Wat is een IDOR en waarom is dit belangrijk in WordPress
• De MStore API IDOR: wat er is gebeurd (hoog niveau)
• Technische analyse: hoe de kwetsbaarheid kan worden geëxploiteerd
• Praktische impact en realistische aanvalscenario's
• Hoe exploitatie te detecteren en indicatoren van compromittering
• Korte termijn mitigaties (wanneer u niet onmiddellijk kunt bijwerken)
• Lange termijn oplossingen en veilige coderingspraktijken
• Het verharding van uw WordPress-site om toekomstige risico's te verminderen
• Checklist voor incidentrespons (stap voor stap)
• Hoe WP-Firewall kan helpen uw site nu te beveiligen
• Beveilig uw site met WP-Firewall Basic (Gratis)
• Bijlage: aanbevolen WAF-regelvoorbeelden en veilige codefragmenten

---

Wat is een IDOR en waarom is dit belangrijk in WordPress

Een onveilige directe objectreferentie (IDOR) doet zich voor wanneer een webapplicatie verwijzingen naar interne objecten (ID's, bestandsnamen, database-sleutels) blootlegt en niet voldoende toegangscontrolecontroles afdwingt voordat bewerkingen op die objecten worden toegestaan. In WordPress omvatten “objecten” vaak gebruikers, berichten, bijlagen en gebruikersmeta-rijen. Als een plugin een REST-eindpunt, AJAX-handler of formulier blootstelt dat een gebruikersidentificator accepteert en updates uitvoert met die identificator zonder te verifiëren of de aanvrager bevoegd is om op de doelgebruiker te opereren, kan een aanvaller de identificator manipuleren en de gegevens van andere gebruikers beïnvloeden.

Waarom dit belangrijk is voor de beveiliging van WordPress-sites:

• WordPress slaat belangrijke accountgegevens op in gebruikersmeta (bijv. sessietokens, rollen/vaardigheden opgeslagen in wp_capabilities, en pluginspecifieke vlaggen). Als een van deze door een aanvaller kan worden gewijzigd, kan de integriteit van de site in gevaar komen.
• Plugins voegen vaak aangepaste REST-routes of AJAX-handlers toe. Als die handlers de WordPress-capaciteitscontroles en nonces niet correct gebruiken, worden ze een frequente vector voor IDOR.
• Zelfs een kwetsbaarheid die als “Laag” is beoordeeld, kan een draaipunt worden voor een grotere compromittering (bijv. het wijzigen van een rol om admin-toegang te krijgen).

---

De MStore API IDOR: wat er is gebeurd (hoog niveau)

Er is een kwetsbaarheid ontdekt in de MStore API-plugin die versies <= 4.18.3 beïnvloedt en die geauthenticeerde gebruikers met lage privileges - zoals abonnees - in staat stelde om willekeurige gebruikersmeta-records bij te werken via een blootgestelde plugin-eindpunt. Het probleem is toegewezen aan CVE-2026-3568 en gepatcht in versie 4.18.4.

Belangrijkste feiten:

• Kwetsbaarheidsklasse: Onveilige Directe Objectreferentie (IDOR) - gebroken toegangscontrole.
• Beïnvloede plugin: MStore API (<= 4.18.3).
• CVE: CVE-2026-3568.
• Gepatcht in: 4.18.4 (site-eigenaren moeten onmiddellijk updaten).
• CVSS: 4.3 (Laag), maar de praktische impact kan hoger zijn, afhankelijk van welke meta-sleutels schrijfbaar zijn.

In een oogopslag: een eindpunt in de plugin accepteerde een gebruikersidentificator en gebruikersmeta sleutel/waarde zonder sterke permissiecontroles af te dwingen, waardoor een account met lage privileges meta voor willekeurige gebruikers kon wijzigen.

---

Technische analyse: hoe de kwetsbaarheid kan worden geëxploiteerd

Dit gedeelte legt de typische mechanismen van de kwetsbaarheid op een toegankelijke manier uit. Implementatiedetails van de originele plugin zijn specifiek, maar het algemene patroon is gebruikelijk:

1. De plugin registreert een REST-eindpunt (of AJAX-handler) zoals:
   • POST /wp-json/mstore-api/v1/update_user_meta
   • of een admin-ajax eindpunt dat wordt aangeroepen via admin-ajax.php?action=mstore_update_meta
2. De handler accepteert parameters zoals:
   • gebruikers-id (de doelgebruiker)
   • meta_sleutel (welk stuk meta moet worden bijgewerkt)
   • meta_waarde (nieuwe waarde om te schrijven)
3. De handler roept update_user_meta($user_id, $meta_key, $meta_value) aan zonder:
   • Verifiëren of de huidige gebruiker toestemming heeft om de doelgebruiker bij te werken (bijv., current_user_can('edit_user', $user_id)).
   • Beperken welke meta-sleutels mogen worden gewijzigd.
   • Invoer op de juiste manier valideren of saniteren.
   • Een nonce of een juiste permissiecallback gebruiken voor een REST-route.
4. Vanwege deze ontbrekende controles kan een aanvaller met een laaggeprivilegieerd account een verzoek opstellen waarin een ander gebruikers-ID en willekeurige meta-sleutels en waarden worden opgegeven om de metadata van die gebruiker te wijzigen.

Waarom dit gevaarlijk is

• WordPress slaat rolinformatie op in gebruikersmeta (wp_capabilities). Als de meta-sleutel kan worden gewijzigd, kan een aanvaller zichzelf (of een ander account) hogere privileges toekennen.
• Sessie- of authenticatiegerelateerde meta kan worden gebruikt om sessies in sommige configuraties te verstoren of over te nemen.
• Plugin- of thema-specifieke metadata kan de toegang tot functies regelen — het bijwerken daarvan kan beperkingen omzeilen.
• Op grote schaal kunnen geautomatiseerde aanvallers gebruikers-ID's opsommen en proberen sleutelwaarden op veel sites te manipuleren.

Belangrijke kanttekening: Of een aanvaller volledig privileges kan escaleren, hangt af van welke meta-sleutels schrijfbaar zijn via het kwetsbare eindpunt. Op veel sites zal het direct wijzigen van geserialiseerde capaciteitsarrays (wp_capabilities) de gebruiker niet automatisch inloggen of gecachte capaciteiten vernieuwen, tenzij sessies op een permissieve manier worden behandeld — maar het risico is reëel en moet serieus worden genomen.

---

Praktische impact en realistische aanvalscenario's

Hier zijn concrete voorbeelden van wat een kwaadwillende actor zou kunnen proberen na het misbruiken van deze IDOR:

• Privilege-escalatie:
  • Wijzig de wp_capabilities meta voor een gebruiker om hogere capaciteiten op te nemen (bijv. een abonnee een beheerder maken).
  • Als de site capaciteiten cachet of server-side sessiegegevens gebruikt die bij het volgende verzoek opnieuw worden geladen, kan de escalatie onmiddellijk effect hebben.
• Accountovername of het creëren van een achterdeur:
  • Injecteer meta die een aangepaste plugin of thema gebruikt om toegang te verlenen tot verborgen beheerdersfuncties.
  • Wijzig plugin-specifieke meta om externe functies in te schakelen of webhook-URL's te wijzigen.
• Persistentie en stealth:
  • Stel plugin meta-vlaggen in die aanvallers-IP's op de witte lijst zetten of bepaalde beveiligingscontroles uitschakelen.
  • Voeg onschuldig uitziende metadata toe die later wordt gebruikt als een backdoor-trigger.
• Massale exploitatie:
  • Een laaggeprivilegieerd account met geautomatiseerde verzoeken kan proberen de exploit uit te voeren tegen meerdere gebruikers-ID's om snel veel sites aan te vallen.

Als voorbeeldscenario:

1. De aanvaller registreert een site-account (of gebruikt aangeschafte abonnee-accounts).
2. Ze sturen HTTP-verzoeken naar het kwetsbare eindpunt met user_id=1 (de hoofdbeheerder) en meta_key=wp_capabilities, meta_value={"administrator":true}.
3. Afhankelijk van de caching en sessiebeheer van de site, kan de site nu een account als een beheerder beschouwen — of een aanvaller gebruikt een secundaire techniek om die rol te activeren.
4. Met beheerders toegang kan de aanvaller backdoors creëren, nieuwe beheerdersgebruikers aanmaken, kwaadaardige plugins installeren of gegevens exfiltreren.

Niet elke exploitatiepoging levert beheerders toegang op, maar zelfs het wijzigen van minder belangrijke meta kan leiden tot code-executie of gegevensblootstelling, afhankelijk van de configuratie van de site.

---

Hoe exploitatie en indicatoren van compromittering (IoCs) te detecteren

Als je reageert op deze kwetsbaarheid of controleert of je site is getroffen, hier zijn praktische detectiestappen en IoC's:

Serverlogs en verzoekpatronen:

• Zoek naar POST-verzoeken naar REST-eindpunten of admin-ajax-URL's die verband houden met de plugin (zoek in de toegangslogs naar “mstore” of naar verzoeken met verdachte parameters zoals gebruikers-id En meta_sleutel).
• Herhaalde verzoeken van hetzelfde laaggeprivilegieerde account naar usermeta-update-eindpunten.
• Onverwachte POST-verzoeken van geauthenticeerde abonnee-accounts.

Database-indicatoren:

• Onverwachte wijzigingen in usermeta-invoeren (vooral wp_capabilities, wp_user_level, plugin-specifieke sleutels).
• Nieuwe of gewijzigde admin-niveau meta-waarden gedateerd op tijden die correleren met verdachte verzoeken.

WordPress-niveau indicatoren:

• Nieuwe admin-accounts die je niet hebt aangemaakt.
• Wijzigingen in bestaande gebruikersrollen (controleer de gebruikerslijst op onverwachte admins).
• Onverklaarde wijzigingen in plugininstellingen.

Voorbeeld MySQL-query om recente wijzigingen te vinden in wp_usermeta (pas aan voor je tabelprefix en tijdstempelkolom als je een transactioneel log gebruikt):

SELECT user_id, meta_key, meta_value;

(Als je databaseback-ups hebt, vergelijk een back-up die vóór de kwetsbaarheid is gemaakt met de huidige staat om te zien wat er is veranderd.)

Bestandsysteemindicatoren:

• Nieuwe bestanden in wp-content/uploads of pluginmappen aangemaakt door admin-niveau acties.
• Gewijzigde plugin- of themabestanden rond de tijd van vermoedelijke exploitatie.

Monitoring- en logtips:

• Schakel gedetailleerde verzoeklogging in voor admin/API-paden voor een korte periode indien mogelijk.
• Zet auditlogging aan (er zijn plugins voor dit doel) om te zien wie wat en wanneer heeft gewijzigd.
• Als je gecentraliseerde logging gebruikt (ELK, Splunk), zoek dan naar patronen zoals “update_user_meta” die op afstand worden aangeroepen.

---

Onmiddellijke acties (korte termijn mitigaties)

Als je ontdekt dat je site een getroffen versie van MStore API (<=4.18.3) draait, volg dan deze onmiddellijke stappen, in volgorde:

1. Werk de plugin bij naar 4.18.4 of later (de gepubliceerde patch). Dit is de definitieve oplossing.
2. Als u niet onmiddellijk kunt updaten:
   • Deactiveer de plugin tijdelijk totdat je de gepatchte versie kunt toepassen.
   • Als deactivatie niet mogelijk is, blokkeer dan de toegang tot de kwetsbare eindpunten op het niveau van de webserver (nginx/Apache) of op de WAF.
3. Reset wachtwoorden en sessies:
   • Dwing een wachtwoordreset af voor beheerdersaccounts (of alle accounts als je vermoedt dat er breed misbruik is).
   • Ongeldig maken van sessies voor gebruikers (bijv. wijzig het authenticatiesalt of gebruik een plugin die uitloggen van alle sessies afdwingt).
4. Controleer gebruikersrollen en gebruikersmeta:
   • Verifieer dat wp_capabilities En wp_user_level invoer is correct.
   • Herroep alle nieuw aangemaakte beheerdersaccounts die je niet hebt goedgekeurd.
5. Scan op webshells en kwaadaardige bestanden:
   • Voer een volledige malwarescan van de site en een integriteitscontrole van het bestand uit.
6. Controleer logs op verdachte activiteiten en verzamel ze voor forensisch onderzoek.
7. Overweeg om te herstellen vanaf een schone back-up als je een inbreuk bevestigt en niet volledig kunt herstellen.

Korte termijn WAF-mitigaties (als een update niet meteen mogelijk is):

• Blokkeer POST/PUT-verzoeken naar de REST-route van de plugin of de admin-ajax-actie.
• Beperk verzoeken naar die eindpunten tot vertrouwde IP's (niet ideaal voor openbare API's, maar nuttig als tijdelijke mitigatie).
• Weiger verzoeken die meta-gerelateerde parameters instellen of bevatten van laaggeprivilegieerde accounts.

---

Lange termijn oplossingen en veilige coderingspraktijken

Voor plugin-auteurs en ontwikkelaars, vermijd IDOR-problemen door deze regels te volgen:

1. Handhaaf altijd permissiecontroles:

   register_rest_route( 'mstore-api/v1', '/update_user_meta', array(;
   

   Controleer in de callback:

   if ( ! current_user_can( 'edit_user', $user_id ) ) {
   

2. Beperk welke meta-sleutels kunnen worden geschreven:

   $allowed_meta_keys = array( 'telefoonnummer', 'verzendadres' );
   

3. Sanitize en valideer invoer:
   • Gebruik sanitize_text_veld(), wp_verify_nonce(), en type-geschikte sanitization.
   • Vermijd het direct schrijven van geserialiseerde arrays die van de client zijn ontvangen.
4. Vermijd het gebruik van door de gebruiker geleverde gebruikers-ID's zonder controles:
   • Als een actie alleen de momenteel geauthenticeerde gebruiker zou moeten beïnvloeden, accepteer dan helemaal geen gebruikers-id parameter.
5. Gebruik nonces of andere anti-CSRF-tokens voor AJAX-eindpunten en toestemming_callback voor REST.
6. Log administratieve acties:
   • Houd een audittrail bij voor alle wijzigingen in gebruikersrollen en belangrijke metadata-velden.

Als je een plugin onderhoudt, voer dan codebeoordelingen uit met toegang tot controle als focus, en voer geautomatiseerde scans uit op gevaarlijke patronen (ongeldige update_user_meta aanroepen, ontbrekende capaciteitscontroles, enz.).

---

Het verharding van uw WordPress-site om toekomstige risico's te verminderen

Naast het patchen van deze specifieke plugin, pas deze maatregelen toe om de blootstelling in je WordPress-stack te verminderen:

• Houd de WordPress-kern, thema's en plugins regelmatig bijgewerkt.
• Beperk administratieve accounts en vermijd het gebruik van de standaard “admin” gebruikersnaam.
• Implementeer tweefactorauthenticatie (2FA) voor elk account met verhoogde privileges.
• Handhaaf sterke wachtwoordbeleid en overweeg wachtwoordverval voor beheerders.
• Gebruik een beheerde WAF die virtuele patches / regels kan toepassen om exploitatiepogingen te blokkeren, zelfs voordat een update wordt toegepast.
• Schakel REST- en admin-ajax-eindpunten uit of bescherm ze die niet nodig zijn voor openbare toegang.
• Beoordeel regelmatig de permissies van plugins en verwijder ongebruikte plugins.
• Implementeer rol- en capaciteitsbeperkingen: gebruik aangepaste rollen zorgvuldig en vermijd per-gebruiker verhoogde capaciteiten waar niet nodig.
• Schakel logging in en stel waarschuwingen in voor verdachte admin-gebeurtenissen (nieuwe admin-gebruikers, wijziging van bevoegdheden, plugin-activaties).

---

Checklist voor incidentrespons (stap voor stap)

Als je vermoedt dat je site het doelwit was van deze kwetsbaarheid:

1. Zet de site in onderhoudsmodus (indien nodig) om lopende wijzigingen te stoppen.
2. Werk de MStore API-plugin onmiddellijk bij naar 4.18.4 (of deactiveer deze).
3. Maak een forensische snapshot:
   • Exporteer logs, database-dump en bestandslijsten voor analyse.
4. Geheimen roteren:
   • Wijzig alle wachtwoorden van admin-gebruikers.
   • Reset API-sleutels, OAuth-tokens en webhooks die door plugins worden gebruikt.
5. Forceer uitlogsessies:
   • Gebruik een plugin of programmatische methode om bestaande sessies voor alle gebruikers ongeldig te maken, of in ieder geval voor admin-accounts.
6. Scan op malware en webshells, met de focus op wp-content, wp-includes en uploads mappen.
7. Audit wp_usermeta voor verdachte wijzigingen.
8. Verwijder ongeautoriseerde admin-gebruikers en herstel de juiste rollen voor gewijzigde accounts.
9. Als er administratieve toegang is verkregen, controleer dan op ongeautoriseerde plugin/thema-installaties en achterdeurtjes.
10. Herstel vanaf een schone back-up als een volledige herstel noodzakelijk is en je anders de systeemintegriteit niet kunt waarborgen.
11. Her-deploy met versterking: sterke wachtwoorden, 2FA, bijgewerkte plugins en WAF-regels.
12. Meld het incident aan partners/belanghebbenden en documenteer de herstelstappen.

---

Hoe WP-Firewall kan helpen uw site nu te beveiligen

Bij WP-Firewall raden we een verdediging-in-diepte aanpak aan. Ons platform is ontworpen voor WordPress-site-eigenaren die snelle, effectieve bescherming nodig hebben tegen plugin-kwetsbaarheden zoals de MStore API IDOR.

Wat WP-Firewall biedt dat helpt in dit scenario:

• Beheerde WAF: regels die snel kunnen worden ingezet om bekende exploitatiepatronen en REST/AJAX-verzoeken die kwetsbare plugin-eindpunten targeten te blokkeren.
• Virtueel patchen: tijdelijke mitigatie die het exploitpatroon aan de rand blokkeert, zelfs voordat je een plugin kunt bijwerken (nuttig wanneer onmiddellijke update of testen niet mogelijk is).
• Malware scanner: vindt verdachte bestanden en indicatoren van compromittering snel, zodat je kunt bepalen of een aanvaller is geëscaleerd.
• Rol- en activiteitsmonitoring: logboeken en waarschuwingen voor wijzigingen in gebruikersrollen en verdachte meta-updates.
• Geautomatiseerd scannen op OWASP Top 10 risico's: vermindert de kans op het missen van onveilige plugin-eindpunten.
• Auto-mitigatie workflows voor veelvoorkomende exploitpatronen — waardoor je sneller kunt reageren met minder technische stappen.

We bouwen onze bescherming met echte wereldincidenten in gedachten. Als je meerdere sites beheert, stellen de beheerde regels en virtueel patchen van WP-Firewall je in staat om ze allemaal snel te beschermen terwijl je plugin-updates test en uitrolt.

---

Beveilig uw site met WP-Firewall Basic (Gratis)

Bescherm je site nu meteen — Begin met WP-Firewall Basic (Gratis)

Als je onmiddellijke basisbescherming wilt terwijl je plugins beoordeelt en patcht, is WP-Firewall Basic een uitstekende eerste stap. Het Basic (Gratis) plan biedt:

• Essentiële bescherming: beheerde firewall, onbeperkte bandbreedte, WAF, malwarescanner en beperking van de top 10-risico's van OWASP.

Het is ontworpen om je onmiddellijke, continue bescherming te bieden tegen typische WordPress-bedreigingen — inclusief virtueel patchen dat exploitpogingen tegen blootgestelde plugin-eindpunten kan blokkeren. Als je extra functies nodig hebt zoals automatische malwareverwijdering, IP-blacklist/witlijstbeheer of maandelijkse beveiligingsrapporten, stellen onze betaalde plannen pijnloze upgrades mogelijk.

Begin snel door je aan te melden voor WP-Firewall Basic (Gratis): https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(We raden aan om het gratis plan onmiddellijk in te schakelen en vervolgens de plugin-update toe te passen. De combinatie van virtueel patchen + het patchen van de oorzaak biedt je de beste korte- en langetermijnbescherming.)

---

Bijlage: aanbevolen WAF-regelvoorbeelden en veilige codefragmenten

A. Voorbeeld WAF-blokkeringsregels (conceptueel; pas aan voor je WAF-engine)

• Blokkeer verzoeken naar een kwetsbare REST-route van laaggeprivilegieerde geauthenticeerde gebruikers:

  Regel: Als het verzoekpad overeenkomt met ^/wp-json/mstore-api/v1/update_user_meta en de verzoekmethode is POST en het verzoek bevat geen geldige, door de site uitgegeven header of token OF de geauthenticeerde rol is abonnee => blokkeer.

• Blokkeer admin-ajax exploitpatroon:

  Regel: Als POST naar /wp-admin/admin-ajax.php met action=mstore_update_meta En meta_sleutel parameter aanwezig en gebruikersrol is abonnee => blokkeer.

• Opmerking: Precieze WAF-regels zijn afhankelijk van uw WAF-syntaxis en of u de geverifieerde rol in headers kunt inspecteren. Als de rol niet beschikbaar is voor de WAF, blokkeer of beperk dan verdachte parametercombinaties en dwing reCAPTCHA / uitdaging af.

B. Voorbeeld: Veilige permissiecontrole voor REST-route in WordPress

function mstore_register_routes() {

C. Voorbeeld: Snelle mu-plugin om een specifieke plugin REST-route uit te schakelen totdat u kunt updaten

<?php;

Dit is een tijdelijke mitigatie — verwijder de mu-plugin pas nadat u bent bijgewerkt naar een veilige pluginversie.

---

Laatste woorden van het WP-Firewall beveiligingsteam

Kwetsbaarheden zoals IDOR zijn gebruikelijk wanneer plugins objectidentifiers blootstellen en geen strikte permissies afdwingen. De MStore API IDOR (CVE-2026-3568) herinnert eraan dat zelfs classificaties met lage ernst kunnen leiden tot aanzienlijke risico's in bepaalde omgevingen. De veiligste, snelste oplossing is om zo snel mogelijk te updaten naar de gepatchte versie (4.18.4).

Als u meerdere WordPress-sites beheert of sites voor klanten host, overweeg dan een gelaagde aanpak: houd software gepatcht, gebruik sessie- en rolversterking, en zorg voor een edge-level WAF die virtuele patches kan toepassen en exploitpatronen kan blokkeren. Het Basis (Gratis) plan van WP-Firewall is ontworpen om u snel die essentiële bescherming te bieden terwijl u langetermijnoplossingen plant en toepast.

Neem de onmiddellijke stap: controleer uw pluginversies, update MStore API naar 4.18.4 of later, en schakel bescherming in die exploitpogingen blokkeert terwijl u audits en herstel uitvoert. Als u een gemakkelijke startpunt wilt, kan WP-Firewall Basic binnen enkele minuten actief zijn: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Als u hulp nodig heeft bij het bekijken van logs, het opstellen van WAF-regels voor uw omgeving, of het uitvoeren van een volledige forensische beoordeling na verdachte activiteit, staat ons beveiligingsteam klaar om te helpen.

Let op je veiligheid,
WP-Firewall Beveiligingsteam

---

Referenties en bronnen (voor beheerders)

• CVE-2026-3568 (MStore API IDOR) — controleer in CVE-lijsten voor details.
• WordPress ontwikkelaarsdocumentatie: register_rest_route(), huidige_gebruiker_kan(), nonces, capaciteitscontroles.
• WP-Firewall-documentatie en snelle startgidsen zijn beschikbaar na aanmelding.