| Pluginnaam | FluentForm |
|---|---|
| Type kwetsbaarheid | Onveilige Direct Object Reference (IDOR) |
| CVE-nummer | CVE-2026-5395 |
| Urgentie | Hoog |
| CVE-publicatiedatum | 2026-05-17 |
| Bron-URL | CVE-2026-5395 |
IDOR in FluentForm (CVE-2026-5395): Wat WordPress-site-eigenaren nu moeten doen
Een recent onthulde kwetsbaarheid voor onveilige directe objectreferenties (IDOR) die FluentForm-versies tot en met 6.2.0 (CVE-2026-5395) beïnvloedt, verdient de aandacht van elke WordPress-site-eigenaar die gebruikersaccounts accepteert of deze populaire formulierplugin gebruikt. Hoewel exploitatie een laag-niveau geverifieerd account (abonnee) vereist, staan veel echte WordPress-sites gebruikersregistratie toe — en dat kan een IDOR verrassend praktisch maken om op grote schaal te misbruiken.
In dit bericht leggen we in eenvoudige termen uit wat deze kwetsbaarheid is, waarom het belangrijk is, zelfs wanneer alleen een abonnee-account vereist is, hoe je pogingen tot misbruik kunt detecteren, en — het belangrijkste — welke onmiddellijke en praktische mitigaties je vandaag kunt toepassen. We laten ook zien hoe WP‑Firewall je site kan beschermen (inclusief ons gratis plan) en bieden een duidelijke checklist voor incidentrespons als je vermoedt dat er een compromis is.
Opmerking: Als je FluentForm op je site gebruikt, werk het dan onmiddellijk bij naar de gepatchte versie (6.2.1 of later). Als je om operationele redenen niet kunt updaten, volg dan de mitigatiestappen hieronder om de blootstelling te verminderen.
Samenvatting (TL;DR)
- Kwetsbaarheid: Onveilige directe objectreferenties (IDOR) in FluentForm <= 6.2.0 (CVE-2026-5395).
- Wat het toestaat: Een geverifieerde gebruiker met toegang op abonniveau kan mogelijk toegang krijgen tot of interactie hebben met objecten (formulierinvoeren, exports, uploads of formuliermetadata) die beperkt zouden moeten zijn.
- Risicofactoren: Sites die gebruikersregistratie toestaan, gemeenschapsinvoer accepteren of formulieren integreren met gevoelige workflows hebben een verhoogde blootstelling.
- Onmiddellijke acties: Werk FluentForm bij naar 6.2.1+, beperk of schakel gebruikersregistratie uit indien mogelijk, en implementeer virtuele patching met een Web Application Firewall (WAF).
- Langere termijn: Pas het principe van de minste privileges toe voor rollen, verscherp REST- en AJAX-eindpunten, neem rolversterking aan en monitor logs op verdachte activiteiten.
Wat is een IDOR en waarom is het gevaarlijk?
Een onveilige directe objectreferentie (IDOR) doet zich voor wanneer een applicatie door gebruikers aangeleverde identificatoren (ID's) gebruikt om interne objecten — zoals database-records, bestanden of bronnen — te benaderen zonder voldoende autorisatiecontroles uit te voeren. In plaats van te verifiëren of de geverifieerde gebruiker daadwerkelijk toegang heeft tot het aangevraagde object, vertrouwt de applicatie op de ID van de gebruiker en retourneert het object.
Waarom dit gevaarlijk is:
- IDOR's stellen aanvallers in staat om gegevens te benaderen die ze niet zouden moeten zien door eenvoudigweg een ID-waarde in een verzoek te wijzigen. Bijvoorbeeld, als je indiening #123 kunt ophalen door /api/get_entry?id=123 te bezoeken, zou je kunnen proberen /api/get_entry?id=124 en de gegevens van iemand anders zien.
- De impact varieert van privacylekken tot volledige gegevensmanipulatie, afhankelijk van welke objecten worden blootgesteld en wat de applicatie toestaat.
- In WordPress-plugin-ecosystemen verschijnen IDOR's vaak in REST/HTTP-eindpunten en AJAX-handlers waar ontwikkelaars vergeten om capaciteiten of eigendom te controleren.
Omdat IDOR's afhankelijk zijn van ontbrekende autorisatie in plaats van het breken van authenticatie of het injecteren van code, kunnen ze subtiel zijn om te detecteren in codebeoordelingen en lange tijd onopgemerkt blijven.
Specificaties van het FluentForm-probleem (hoog niveau)
Samenvatting van de openbare waarschuwing:
- Een kwetsbaarheid die als IDOR is geclassificeerd, beïnvloedt FluentForm-versies tot en met 6.2.0.
- Het probleem kreeg CVE-2026-5395 toegewezen en is gepatcht in versie 6.2.1.
- De kwetsbaarheid vereist een geauthenticeerd abonnement-niveau account om te exploiteren (d.w.z. iedereen met een basis site-account kan het proberen).
Wat dit waarschijnlijk in de praktijk betekent:
- Bepaalde FluentForm-eindpunten stonden toegang toe tot bronnen op ID zonder voldoende capaciteits- of eigendomcontroles.
- Een abonnee kon object-ID's (voor formulierindieningen, bestanden, exports, enz.) opsommen of aanvragen en bronnen ophalen of anderszins interactie hebben met bronnen waartoe ze geen toegang zouden moeten hebben.
- Afhankelijk van hoe de plugin bijlagen opslaat (bijvoorbeeld, geüploade bestanden toegankelijk via directe URL's) en hoe invoer wordt teruggegeven, kan een succesvolle exploitatie leiden tot blootstelling van gevoelige gegevens die zijn opgenomen in formulierindieningen.
We vermijden opzettelijk het reproduceren van exploitcode hier. Het doel is om te informeren, niet om misbruik mogelijk te maken. Als uw site FluentForm gebruikt, beschouw dit dan als een dringende actie: plan een update en pas virtuele patches toe als onmiddellijke updates niet mogelijk zijn.
Hoe ernstig is dit voor uw site?
De ernst hangt af van een paar praktische factoren:
- Siteconfiguratie: Als u open gebruikersregistratie toestaat of een gemeenschap heeft die veel abonnementaccounts omvat, groeit uw blootstelling. Aanvallers kunnen accounts aanmaken en eindpunten onderzoeken.
- Soorten formulieren: Bedrijfskritische formulieren (sollicitaties, contactformulieren met gevoelige PII, betalingscallback, bestandsuploadvelden) zijn hoog risico als invoer of bijlagen worden blootgesteld.
- Aanvullende plugin-integraties: Als formulierindieningen worden doorgestuurd naar e-mail, CRM's, of opgeslagen met API-sleutels of privégegevens, kan een IDOR die gevoelige items lekken.
- Aanvalcomplexiteit: Omdat exploitatie een abonnementaccount vereist, is geautomatiseerd grootschalig misbruik mogelijk waarbij nepaccounts gemakkelijk kunnen worden aangemaakt. Sommige sites blokkeren registratie of screenen gebruikers, wat het risico vermindert.
Kortom: als uw site gebruikersregistraties accepteert of u FluentForm gebruikt om enige vorm van persoonlijke gegevens te verzamelen, beschouw dit dan als een update met hoge prioriteit.
Directe herstelchecklist (wat nu te doen)
Als u WordPress-sites host, voer deze acties dan in de onderstaande volgorde uit. Geef prioriteit aan sites die gebruikersregistratie accepteren of waar formulieren PII verzamelen.
- Update FluentForm
– De leverancier heeft versie 6.2.1 uitgebracht die dit probleem oplost. Update onmiddellijk naar 6.2.1 of later op alle getroffen sites. Test updates in staging indien mogelijk, en implementeer ze vervolgens in productie. - Als u niet onmiddellijk kunt updaten
– Deactiveer tijdelijk de FluentForm-plugin totdat u kunt patchen.
– Schakel open gebruikersregistratie uit via WordPress admin: Instellingen → Algemeen → Lidmaatschap (vink “Iedereen kan zich registreren” uit).
– Beperk toegang tot bekende plugin-eindpunten met behulp van je WAF (virtuele patch) of webserverregels (zie volgende sectie). - Pas WAF-virtuele patches toe
– Configureer WAF-regels om:
– Verdachte parameterveranderingen te blokkeren (bijv. pogingen om toegang te krijgen tot vermeldingen door ID's te raden).
– Directe toegang tot plugin-eindpunten blokkeren voor aanvragen op abonnementsniveau die ongebruikelijke object-ID's of methoden proberen.
– Beperk het aantal aanvragen tot relevante eindpunten om enumeratie te beperken. - Controleer gebruikersaccounts
– Verwijder of beperk onnodige abonnementsaccounts.
– Beveilig gecompromitteerde of verdachte accounts door wachtwoordresets af te dwingen.
– Voeg tweefactorauthenticatie toe voor accounts met hogere privileges (beheerders, redacteuren). - Monitor logs en indicatoren
– Zoek naar pieken in aanvragen naar FluentForm-eindpunten, vooral met verschillende id-parameters.
– Controleer toeganglogs op herhaalde 200-antwoorden op GET/POST-aanvragen met queryparameters zoals id= of entry_id=.
– Controleer op ongebruikelijke bestandsdownloads vanuit uploadmappen. - Back-ups en detectie
– Zorg ervoor dat je een recente back-up hebt voordat je updates uitvoert of herstelmaatregelen neemt.
– Voer een volledige site-scan uit met je malware-scanner na de update om te zorgen dat er geen blijvende wijzigingen zijn aangebracht.
Hoe WP‑Firewall helpt (beheerde bescherming en virtuele patching)
WP‑Firewall biedt meerdere lagen van verdediging die effectief zijn tegen kwetsbaarheden zoals deze IDOR:
- Beheerde WAF-regels: We kunnen virtuele patches implementeren die exploitatiepatronen blokkeren of filteren voordat ze de plugin-code bereiken. Bijvoorbeeld, regels kunnen aanvragen van geauthenticeerde gebruikers weigeren die proberen ID's te enumereren of toegang te krijgen tot eindpunten op beheerdersniveau met behulp van abonnementsreferenties.
- OWASP Top 10 mitigatie: De regels van WP‑Firewall richten zich op veelvoorkomende toegangsbewakings- en injectieklassen, waardoor het exploitoppervlak wordt verkleind, zelfs wanneer een plugin een logische fout heeft.
- Malware-scanner en mitigatie: Als een kwetsbaarheid is misbruikt, kan de scanner van WP‑Firewall verdachte bestanden en wijzigingen identificeren en deze in quarantaine plaatsen of markeren voor beoordeling.
- Bescherming met minimale wrijving: Beheerde firewallregels kunnen snel en tijdelijk worden ingezet wanneer een noodpatch nodig is en voordat de plugin kan worden bijgewerkt.
Als je meerdere sites beheert, stellen deze controles je in staat om snel te reageren: blokkeer exploitpogingen, monitor en werk op je eigen schema bij.
Aanbevolen WAF-regels en virtuele patchpatronen (conceptuele richtlijnen)
Hieronder staan conceptuele regelpatronen die je kunt toepassen (geïmplementeerd in je WAF of via WP‑Firewall):
- Blokkeer parameter-gebaseerde enumeratie:
- Weiger of beperk verzoeken die opeenvolgende numerieke ID's met een hoge snelheid van hetzelfde IP of gebruikersaccount presenteren.
- Vereis de aanwezigheid van geldige nonces of capaciteitsheaders voor eindpunten die toegang hebben tot formulierinvoeren.
- Handhaaf rolgebaseerde toegang tot eindpunten:
- Blokkeer verzoeken naar eindpunten voor het exporteren van formulierinvoeren als de rol van de aanvrager abonnee is.
- Geef 403 terug aan niet-geautoriseerde rollen in plaats van 404/200 om informatielekken te verminderen.
- Valideer content-type en HTTP-methode:
- Beperk eindpunten tot verwachte HTTP-methoden (bijv. alleen POST) en blokkeer onjuiste methoden die gegevens kunnen lekken.
- Bestands toegangscontroles:
- Voorkom direct downloaden van geüploade bijlagen uit door de plugin beheerde mappen, tenzij het verzoek dat de bijlage serveert een geldige capaciteitscontrole of token heeft.
- Blokkeer hotlinking naar geüploade bestanden van onbetrouwbare verwijzers als het formulier bijlagen openbaar opslaat.
Je moet samenwerken met je beveiligingsteam om deze patronen om te zetten in precieze WAF-regels. Als je WP‑Firewall gebruikt, kunnen onze analisten virtuele patches voor je toepassen terwijl je de pluginupdate voorbereidt.
Detecteren van tekenen van uitbuiting (waarop te letten)
Als je vermoedt dat de site is onderzocht of uitgebuit, let dan op:
- Ongebruikelijke aanvraagpatronen tegen FluentForm-eindpunten:
- Hoge hoeveelheid aanvragen naar eindpunten met id-, entry_id- of form_id-parameters.
- Aanvragen die alleen variëren op basis van numerieke ID (indicatief voor enumeratie).
- Nieuwe of verdachte abonneerekeningen:
- Meerdere accounts aangemaakt in een korte tijdspanne, vooral met vergelijkbare patronen (e-maildomeinen zoals mailinator, opeenvolgende gebruikersnamen).
- Indicatoren voor gegevensexfiltratie:
- Pieken in uitgaande e-mailactiviteit (als formulierindieningen worden doorgestuurd).
- Toegang tot formulierinvoeren gevolgd door externe netwerkverbindingen (let op scripts of geplande taken).
- Onverwachte bestandsdownloads vanuit uploads of plugindirectories:
- Controleer toeganglogs op 200-antwoorden op aanvragen voor bijlagenbestandsnamen die zelden voorkomen.
- Tekenen van post-exploitwijzigingen:
- Onverwachte beheerdersgebruikers, gewijzigde thema's/plugins, onbekende cron-taken of PHP-bestanden in uploads.
Als u bewijs van inbreuk vindt, volgt u de onderstaande stappen voor incidentrespons.
Checklist voor incidentrespons (als u misbruik vermoedt)
- Isoleer de getroffen site(s)
– Zet de site in onderhoudsmodus of isoleer deze van openbaar verkeer terwijl je onderzoekt.
– Als je meerdere sites op dezelfde server host, overweeg dan isolatie op basis van IP, directory of container. - Logs bewaren
– Exporteer webservertoeganglogs, applicatielogs en databaselogs voor forensisch onderzoek.
– Verwijder logs niet voortijdig; deze zijn essentieel voor het bepalen van de reikwijdte. - Wijzig inloggegevens
– Reset beheerderswachtwoorden en database-inloggegevens.
– Draai alle API-sleutels of tokens die zijn gebruikt door formulieren of integraties van derden. - Scan op persistentie en backdoors
– Gebruik een vertrouwde scanner om gewijzigde bestanden en bekende backdoor-patronen te detecteren.
– Controleer handmatig kritieke mappen (thema's, mu-plugins, uploads) op PHP-bestanden of onverwachte bestanden. - Herstel indien nodig vanuit schone back-ups
– Als de site zwaar gecompromitteerd is, herstel dan vanaf een back-up die vóór het incident is gemaakt.
– Pas na herstel updates en verharding toe voordat je de openbare toegang weer inschakelt. - Meld belanghebbenden en voldoe aan privacyvereisten.
– Als PII is blootgesteld, volg dan het meldingsbeleid van je organisatie en relevante wettelijke vereisten. - Versterk en monitor na het incident
– Pas de aanbevolen WAF-regels toe, werk FluentForm bij en houd toezicht op herhaalde pogingen.
– Schakel logging en geautomatiseerde waarschuwingen in voor verdachte toegangspatronen.
Als je gebruikmaakt van de beheerde diensten van WP‑Firewall, kunnen we helpen met containment, opruimen en het beschermen van de site terwijl je herstelt.
Best practices voor verharding om toekomstige IDOR-blootstelling te verminderen.
IDOR's zijn een logisch en autorisatieprobleem, dus naast het patchen van een plugin moet je systematische verhardingsmaatregelen aannemen:
- Beginsel van de minste privileges:
- Geef gebruikers alleen de mogelijkheden die ze nodig hebben. Veel plugins voegen eindpunten toe die aannemen dat geauthenticeerde gebruikers betrouwbaar zijn — verminder dat vertrouwen.
- Gebruik rolbeheer-plugins om aan te passen wat een abonnee kan (en belangrijker, niet kan) doen.
- Controleer en beperk REST- en AJAX-eindpunten:
- Controleer je plugins om openbare eindpunten te ontdekken en zorg ervoor dat ze current_user_can() of juiste eigendom controleren voordat ze gegevens retourneren.
- Schakel uploadmappen van plugins uit of bescherm ze:
- Verifieer dat geüploade bijlagen veilig worden opgeslagen en via een toegangscontrole worden aangeboden, niet als publiekelijk te raden URL's.
- Beperk open registratie:
- Als je geen anonieme gebruikers accounts nodig hebt, zet dan open registratie uit.
- Gebruik CAPTCHA of e-mailverificatie om de drempel voor massale accountcreatie te verhogen.
- Houd de creatie en activiteit van gebruikers in de gaten:
- Stel waarschuwingen in voor bulkaccountcreatie of abnormale abonneeactiviteit.
- Beperk acties zoals “bekijk invoer” of “exporteer” voor geauthenticeerde gebruikers.
- Gebruik een gefaseerde, geteste updatecyclus:
- Test updates in staging of een lokale omgeving voordat je ze in productie neemt. Gebruik back-ups en een terugrolplan.
- Houd plugins tot een minimum:
- Verwijder ongebruikte plugins. Elke plugin is extra code die logische fouten kan bevatten.
Hoe te testen of je niet langer kwetsbaar bent
Na het updaten naar FluentForm 6.2.1 of later en het toepassen van WAF-regels:
- Controleer de pluginversie
– Bevestig in de WordPress-admin dat FluentForm is bijgewerkt naar 6.2.1+. - Test in staging
– Creëer de omstandigheden (een abonneeaccount) en probeer normale plugin-workflows om ervoor te zorgen dat er geen legitieme functionaliteit wordt geblokkeerd. - Controleer logs op geblokkeerde pogingen
– WAF zou geblokkeerde of beperkt aantal pogingen moeten tonen die overeenkomen met de oudere kwetsbaarheids patronen. - Voer een beveiligingsscan uit
– Gebruik de WP‑Firewall malware scanner en andere scan-tools om verdachte bestanden en anomalieën te inspecteren. - Beoordeel gebruikersaccounts en formulierinvoeren
– Zorg ervoor dat er geen ongeautoriseerde toegang of exports van formulierinvoeren zijn.
Als je niet zeker weet of je het probleem succesvol hebt verholpen, kan de beheerde service van WP‑Firewall je site auditen en beschermende regels toepassen.
FAQ: Veelgestelde vragen van site-eigenaren
V: Als een aanvaller alleen een abonneeaccount nodig heeft, hoe erg is dit?
A: Het kan significant zijn. Veel sites staan abonnementen toe voor opmerkingen, nieuwsbrieven of afgeschermde inhoud. Aanvallers gebruiken vaak wegwerp-e-mails om massaal accounts aan te maken en gebruiken vervolgens geautomatiseerde tools om te zoeken naar IDORs en ID's te enumereren. Als uw formulieren PII, bestanden of geheimen verzamelen, kan die data in gevaar zijn.
Q: Zal het uitschakelen van gebruikersregistratie dit oplossen?
A: Het vermindert het risico, omdat het de drempel voor aanvallers verhoogt. Echter, als er al geldige abonnee-accounts bestaan, of als aanvallers manieren vinden om gegevens via andere integraties te uploaden, zijn aanvullende bescherming nog steeds vereist.
Q: Is het voldoende om te vertrouwen op serverniveau-bescherming (zoals privé-upload)?
A: Bescherming op serverniveau helpt. Maar de meest robuuste aanpak is een gelaagde verdediging: patch de plugin, handhaaf capaciteitscontroles en gebruik een WAF om exploitatiepogingen te stoppen voordat ze de applicatie bereiken.
Q: Moet ik oude formulierinvoeren verwijderen?
A: Verwijder alleen als ze bekend zijn als gecompromitteerd of onnodige gevoelige informatie bevatten. Houd back-ups bij en volg uw gegevensbewaarbeleid. Sanitize of redacteer PII als het niet langer nodig is.
Voorbeeld van capaciteitscontroles die plugin-auteurs zouden moeten gebruiken (conceptueel)
Plugin-code die objecttoegang beheert, moet zowel authenticatie als eigendom/capaciteiten verifiëren. In WordPress PHP pseudo-code omvat een robuust controlepatroon:
- Verifiëren van nonces voor AJAX of REST
- Controleren van current_user_can() voor de juiste capaciteit
- Zorgen dat de huidige gebruiker het object bezit of een bevoorrechte capaciteit heeft
(We laten specifieke kwetsbare eindpuntnamen weg en vermijden het geven van reproductiedetails. Ontwikkelaars moeten deze controles toepassen op alle plugin-eindpunten die een object-ID van een gebruiker accepteren.)
Waarom een WAF essentieel is in uw beveiligingsstack
Een Web Application Firewall (WAF) aanvult patching door te voorzien in:
- Virtuele patching: onmiddellijke blokkering van exploitpatronen terwijl u code-updates voorbereidt en test.
- Rate limiting: voorkomt massale enumeratie en brute-force ID-gokken.
- Bescherming voor eindpunten die moeilijk snel te veranderen zijn: soms is een plugin cruciaal voor bedrijfsworkflows en kan deze niet onmiddellijk worden uitgeschakeld — een WAF koopt tijd.
- Logging en dreigingsinformatie: in combinatie met monitoring helpen WAF-logs u verdachte scans en exploitatiepogingen op te sporen.
WP‑Firewall biedt beheerde WAF-beleid die zijn afgestemd op WordPress en proactieve regels voor veelvoorkomende logica-gebaseerde kwetsbaarheden zoals IDORs.
Bescherm je site vandaag — Begin met het WP‑Firewall Gratis Plan
Als je onmiddellijke, beheerde bescherming nodig hebt terwijl je plugin-updates en verificatie afhandelt, biedt WP‑Firewall een gratis basisplan dat is ontworpen voor essentiële dekking:
- Basis (gratis): Beheerde firewall, onbeperkte bandbreedte, WAF, malware-scanner en mitigatie van OWASP Top 10-risico's.
- Standaard ($50/jaar): Voegt automatische malwareverwijdering en eenvoudige IP-blacklist-/whitelist-controles toe.
- Pro ($299/jaar): Voegt maandelijkse beveiligingsrapporten, automatische virtuele patches en premium add-ons toe, zoals een toegewijde accountmanager en beheerde beveiligingsdienst.
Meld je aan voor het WP‑Firewall gratis plan en krijg beheerde WAF-bescherming en automatische scanning terwijl je plugin-updates en verharding toepast: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Dit is de snelste manier om een beschermende laag over je site te leggen en de blootstellingsperiode te verkleinen die wordt veroorzaakt door kwetsbaarheden in derde-partij plugins.
Laatste woorden — een praktische routekaart
- Update FluentForm onmiddellijk naar 6.2.1 of later.
- Als je niet onmiddellijk kunt updaten: schakel open registratie uit, deactiveer de plugin tijdelijk en pas WAF-virtuele patches toe.
- Controleer en verhard gebruikersrollen, verwijder onnodige abonnees en voeg monitoring voor verdachte activiteiten toe.
- Gebruik WP‑Firewall voor onmiddellijke, beheerde bescherming — het gratis plan biedt een solide basis terwijl je de bovenstaande stappen onderneemt.
- Als je een compromis detecteert, volg dan de checklist voor incidentrespons: isoleer, bewaar logs, reset inloggegevens, scan, herstel en verhard.
IDOR's zijn geen exotische bugs — het zijn logische tekortkomingen die te vermijden zijn met goede ontwikkelingshygiëne en gelaagde verdedigingen. Patching is de belangrijkste actie, maar onderschat de snelheid en waarde van virtuele patches en monitoring niet. Als je meerdere WordPress-sites beheert, investeer dan in een routine-update- en monitoringplan. Dat bespaart je tijd, reputatie en mogelijk kostbare incidentafhandeling later.
Als je hulp wilt bij het beoordelen van je site of het toepassen van nood-virtuele patches, kan het team van WP‑Firewall helpen met audits, beheerde WAF-regels en herstelopties. Begin met het gratis beschermingsplan om onmiddellijke dekking te krijgen terwijl je oplossingen implementeert: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Als je wilt, kunnen we een beknopte, stapsgewijze herstelhandleiding opstellen die is afgestemd op jouw hostingomgeving (cPanel, Plesk, beheerde host of gecontaineriseerde implementaties). Vertel ons welke hostingconfiguratie je gebruikt en we zullen een checklist en voorbeelden van WAF-regels voorbereiden die je kunt kopiëren naar WP‑Firewall of je bestaande WAF-beheerconsole.
