Pluginnaam	Radio Speler
Type kwetsbaarheid	Cross-Site Scripting
CVE-nummer	CVE-2024-13362
Urgentie	Laag
CVE-publicatiedatum	2026-05-01
Bron-URL	CVE-2024-13362

Dringende beveiligingswaarschuwing: Gereflecteerde XSS in WordPress Radio Speler Plugin (≤ 2.0.82) — Wat u moet weten en hoe WP‑Firewall u beschermt

Datum: 2026-05-01
Auteur: WP-Firewall Beveiligingsteam
Trefwoorden: WordPress, Kw vulnerability, XSS, WAF, Pluginbeveiliging, Incidentrespons

Samenvatting: Op 1 mei 2026 werd een gereflecteerde Cross‑Site Scripting (XSS) kwetsbaarheid (CVE‑2024‑13362) gepubliceerd die de “Radio Speler – Live Shoutcast, Icecast en Elke Audio Stream Speler” WordPress plugin (versies ≤ 2.0.82) betreft. Hoewel de kwetsbaarheid is gecategoriseerd met een lage tot gematigde prioriteit (CVSS 6.1), is deze uit te buiten zonder authenticatie en kan deze worden gebruikt in gerichte campagnes om bevoorrechte gebruikers te compromitteren. Deze post legt het risico, de detectie, mitigatie en onmiddellijke stappen uit die site-eigenaren en ontwikkelaars moeten nemen — en hoe WP‑Firewall u helpt dit probleem snel te mitigeren.

Inhoudsopgave

• Wat er is gebeurd (kort)
• Wat is een gereflecteerde XSS? Waarom is dit belangrijk voor WordPress-sites
• De specifics: Radio Speler plugin (≤ 2.0.82), CVE en impact
• Hoe aanvallers gereflecteerde XSS kunnen misbruiken (hoog niveau, geen exploit)
• Wie loopt er risico?
• Onmiddellijke acties voor site-eigenaren (stap-voor-stap)
• Als u niet onmiddellijk kunt updaten — noodmitigaties
• Hoe WP‑Firewall helpt: preventie, detectie en virtueel patchen
• Ontwikkelaarsrichtlijnen: de code repareren en toekomstige XSS voorkomen
• Checklist na een incident: verifiëren en herstellen
• Aanbevelingen voor langdurige verharding en monitoring
• Gratis beschermingsopties van WP‑Firewall (korte highlight)
• Laatste aanbevelingen en bronnen

---

Wat er is gebeurd (kort)

Een gereflecteerde Cross‑Site Scripting (XSS) kwetsbaarheid werd onthuld in de Radio Speler WordPress plugin die alle versies tot en met 2.0.82 betreft. De leverancier heeft een gepatchte versie (2.0.83) uitgebracht. De kwetsbaarheid stelt door de aanvaller geleverde invoer in staat om in een pagina te worden gereflecteerd en door de browser als uitvoerbaar script te worden geïnterpreteerd. Gerapporteerd als CVE‑2024‑13362 en publiekelijk onthuld op 1 mei 2026, kan deze fout worden gebruikt in gerichte phishing-stijl campagnes waarbij de aanvaller een sitebezoeker — vaak een bevoorrechte gebruiker — overtuigt om op een zorgvuldig gemaakte link te klikken.

Hoewel de gerapporteerde ernst in het lage tot gemiddelde bereik ligt (CVSS 6.1), hangt het werkelijke risico af van wie er interactie heeft met een zorgvuldig gemaakte link (bijv. een beheerder of redacteur). Zowel kleine sites als sites met veel verkeer kunnen worden doelwit in geautomatiseerde campagnes.

---

Wat is weerspiegelde XSS en waarom is het belangrijk voor WordPress

Gereflecteerde XSS is een klasse van kwetsbaarheid waarbij gebruikersinvoer (van queryparameters, POST-lichaam, headers of andere delen van het verzoek) in de serverrespons wordt opgenomen zonder juiste contextbewuste escaping. Omdat de aanvaller de invoer controleert en de browser uitvoert wat er in de respons aankomt, kan een aanvaller een speciaal gemaakte URL naar een slachtoffer sturen. Als het slachtoffer (beheerder/redacteur/bezoeker) die link volgt, draait de kwaadaardige payload in de browser van het slachtoffer alsof deze afkomstig is van uw domein.

Waarom dit belangrijk is voor WordPress-sites:

• Veel WordPress-installaties hebben bevoorrechte gebruikers (beheerders, redacteuren) en die sessies zijn waardevol. Een succesvolle gereflecteerde XSS kan worden gebruikt om admin-sessiecookies te stelen, acties uit te voeren namens de admin, persistente backdoors in te voegen of kwaadaardige plugins te installeren.
• Plugins, thema's en aangepaste eindpunten accepteren vaak parameters; als deze zonder escaping in HTML worden gereflecteerd, worden ze aanvalsvectoren.
• Geautomatiseerde scanners en mass-exploit bots zoeken naar publieke, niet-geauthenticeerde kwetsbaarheden; zelfs minder ernstige bugs worden hoog impact wanneer mass-exploitatie plaatsvindt.

---

De specifics: Radio Speler plugin (≤ 2.0.82)

• Aangetaste software: Radio Player – Live Shoutcast, Icecast en Any Audio Stream Player (WordPress-plugin)
• Kwetsbare versies: 2.0.82 en eerder (≤ 2.0.82)
• Gepatchte versie: 2.0.83
• Kwetsbaarheidstype: Gereflecteerde Cross-Site Scripting (XSS)
• CVE: CVE‑2024‑13362
• Datum gepubliceerd: 1 mei 2026
• Gerapporteerd door: (openbare bekendmaking vermeldt onderzoeker toeschrijving)

Belangrijke nuance gerapporteerd met deze bekendmaking: de kwetsbaarheid is bereikbaar zonder authenticatie (de kwetsbare parameter kan worden benaderd door niet-geauthenticeerde aanvallers), maar succesvolle exploitatie in veel aanvalsscenario's vereist dat een slachtoffer interactie heeft (klik op een gemaakte link). Als het slachtoffer een bevoorrechte gebruiker is, is de impact veel groter.

---

Hoe aanvallers (algemeen) een gereflecteerde XSS kunnen misbruiken

Ik sla opzettelijk technische exploitstrings en exacte payloads over (het openbaar delen van exploitdetails verhoogt het risico). Hoog-niveau aanvalsstroom:

1. Aanvaller ontdekt een parameter of eindpunt in de plugin die invoer terugreflecteert in een HTML-pagina zonder juiste escaping.
2. Aanvaller maakt een URL die een kwaadaardige payload bevat die in die parameter is ingebed.
3. De aanvaller verspreidt die link via e-mail, sociale engineering of geautomatiseerd scannen — gericht op beheerders, redacteuren of bijdragers.
4. Wanneer een slachtoffer de link opent, wordt de kwaadaardige inhoud uitgevoerd in hun browser onder de context van jouw domein.
5. Mogelijke uitkomsten:
   • Diefstal van sessiecookies (als cookiebescherming zwak is)
   • Stille, ongeautoriseerde acties (bijv. het aanmaken van een nieuwe admin-gebruiker, het publiceren van berichten met kwaadaardige links)
   • Installatie van backdoors of gewijzigde thema/plugin-bestanden via admin-acties
   • Redirects naar phishing-sites, drive-by malware of ongewenste JavaScript-injecties

Vanwege deze gevolgen kan zelfs een “gereflecteerde” XSS die gebruikersinteractie vereist zeer gevaarlijk zijn voor WordPress-sites.

---

Wie loopt risico?

• Sites die Radio Player-plugin versie ≤ 2.0.82 draaien.
• Elke site die de plugin op een manier gebruikt die de kwetsbare parameter blootstelt aan openbare verzoeken (de meeste installaties).
• Sites waar beheerders of redacteuren kunnen worden misleid om de gemaakte URL te openen terwijl ze zijn ingelogd.
• Sites met zwakkere cookiebescherming (afwezigheid van HttpOnly, SameSite-misconfiguraties) lopen een hoger risico op cookie-diefstal.

---

Onmiddellijke acties voor site-eigenaren (stap-voor-stap)

Als je een WordPress-site beheert die de Radio Player-plugin gebruikt, volg dan onmiddellijk deze stappen:

1. Pluginversie bevestigen:
   • Dashboard: WordPress Admin → Plugins → Geïnstalleerde Plugins → zoek “Radio Player” en controleer de versie.
   • WP‑CLI: wp plugin lijst | grep radio-speler (of de plugin-slug die op jouw site wordt gebruikt).
2. Als je op versie ≤ 2.0.82 bent, werk dan onmiddellijk bij naar 2.0.83:
   • Dashboard: Plugins → Update beschikbaar → Update de plugin.
   • WP‑CLI: wp plugin update radio-speler --versie=2.0.83 (test eerst op staging waar mogelijk).
3. Als je niet onmiddellijk kunt updaten, pas dan tijdelijke mitigaties toe (hieronder).
4. Backup: maak een volledige site-backup (bestanden + database) voordat je wijzigingen aanbrengt. Bewaar een kopie op een andere locatie.
5. Scan je site na het patchen:
   • Voer een vertrouwde malware-scan uit (WP‑Firewall omvat malware-scanning op het Basisplan).
   • Controleer op onverwachte admin-gebruikers, verdachte berichten, gewijzigde themabestanden of onbekende geplande taken.
6. Bekijk logs:
   • Toegangslogs van de webserver (zoek naar ongebruikelijke querystrings / verwijzers).
   • WordPress inloggeschiedenis en administratieve activiteitslogs (als je een logging/audit-plugin hebt).
7. Reset alle inloggegevens als je actieve compromittering detecteert: admin-wachtwoorden en API-sleutels, en roteer alle API-geheimen die door jouw site worden gebruikt.
8. Als je bewijs van compromittering vindt, volg dan een incidentresponsplan (zie Post-incident Checklist hieronder) en overweeg professionele opschoning.

---

Als u niet onmiddellijk kunt updaten — noodmitigaties

Hoewel de door de leverancier geleverde oplossing (2.0.83) het juiste pad is, zijn updates niet altijd onmiddellijk mogelijk (compatibiliteitstests, bevroren wijzigingsvensters, legacy-omgevingen). Als je tijdelijke bescherming nodig hebt, overweeg dan de volgende gelaagde mitigaties. Dit zijn defensieve maatregelen die bedoeld zijn om het aanvalsvlak te verkleinen. tot je de patch kunt installeren.

1. Een webapplicatiefirewall (WAF) implementeren
   • Een WAF kan verzoeken blokkeren die scriptachtige payloads bevatten in querystrings of POST-lichamen, of verzoeken blokkeren die overeenkomen met specifieke patronen. Dit is de snelste, minst ingrijpende mitigatie.
   • Als je WP‑Firewall gebruikt, schakel dan de beheerde firewall en de WAF-regels in; ons team kan een gerichte regel pushen om bekende exploitpatronen voor deze kwetsbaarheid op Pro (automatische virtuele patching) of via aangepaste regels op Standaard/Basis te blokkeren.
2. Blokkeer verdachte payloads aan de rand:
   • Configureer je WAF om verzoeken te laten vallen die verdachte substrings bevatten, zoals <script, onerror=, of javascript: in queryparameters (gebruik contextbewuste matching — zodat je legitieme functionaliteit niet verstoort).
   • Als de plugin een specifieke eindpunt of bestands pad blootlegt, blokkeer dan tijdelijk externe toegang tot dat pad via IP of webregel totdat je kunt updaten.
3. Beperk de toegang voor beheerders:
   • Beperk de toegang tot wp‑admin en gevoelige pagina's met behulp van IP-toelatingslijsten of VPN voor beheerders.
   • Gebruik tweefactorauthenticatie (2FA) en sterke wachtwoorden voor alle bevoorrechte accounts.
4. Voeg Content Security Policy (CSP) toe
   • Een strikte CSP vermindert de impact van XSS door inline scripts of bronnen die niet op de whitelist staan in je beleid te blokkeren. Implementeer CSP geleidelijk (eerst in rapportagemodus) om te voorkomen dat sitefuncties worden verbroken.
5. Versterk cookies
   • Zorg ervoor dat sessiecookies de HttpOnly-, Secure- en SameSite-attributen gebruiken om diefstal via client-side scripting te verminderen.
6. Verkort de duur van admin-sessies.
   • Dwing beheerders om uit te loggen door zouten te roteren en sessies te laten verlopen, zodat eerder vastgelegde sessiecookies ongeldig worden.

Deze maatregelen verminderen het risico, maar zijn geen vervanging voor het installeren van de officiële patch.

---

Detectie van exploitatie en indicatoren van compromittering

Zelfs na het patchen of toepassen van WAF-regels, moet je controleren of er eerder enige exploitatie heeft plaatsgevonden. Veelvoorkomende tekenen:

• Nieuwe beheerdersaccounts die je niet hebt aangemaakt.
• Berichten, pagina's of widgets die onverwachte JavaScript of onbekende links bevatten.
• Gewijzigde thema- of pluginbestanden (vooral header/footer, functions.php).
• Ongebruikelijke uitgaande verbindingen die van je site afkomstig zijn.
• Vreemde geplande taken (cron jobs) die je niet hebt ingepland.
• Abnormale pieken in verkeer met vreemde querystrings.
• Toegangslogboeken die verdachte queryparameters of verwijzers bevatten die terugwijzen naar phishingdomeinen.

Snelle controles en nuttige commando's:

• Lijst plugins en versies (WP‑CLI):
  • wp plugin lijst --format=tabel
• Zoek naar recent gewijzigde bestanden:
  • vind . -type f -mtime -30 -ls
• Zoek naar verdachte strings (server shell; vermijd het echoën van kwaadaardige payloads):
  • grep -R --line-number "<script" wp-content/themes wp-content/plugins
  • grep -R --line-number "eval(" wp-content
• Databasecontroles:
  • Zoek berichten en opties naar onverwachte script-tags: SELECT * FROM wp_posts WHERE post_content LIKE '%<script%';
• Logreview:
  • Inspecteer access.log op ongebruikelijke GET-verzoeken met lange querystrings.

Als je een van deze indicatoren vindt, behandel de site dan als potentieel gecompromitteerd en volg de checklist na een incident hieronder.

---

Hoe WP‑Firewall je site beschermt (praktisch, vanuit ons serviceperspectief)

Bij WP‑Firewall opereren we op het snijpunt van preventie, detectie en snelle mitigatie. Hier is hoe ons product en beheerde diensten het risico van plugin-kwulnerabiliteiten zoals deze gereflecteerde XSS verminderen:

• Beheerde webapplicatiefirewall (WAF)
  • Onze WAF blokkeert kwaadaardige verzoekpatronen aan de netwerkrand voordat ze WordPress bereiken. Voor een gereflecteerde XSS kan de WAF verzoeken blokkeren met scriptachtige payloads in queryparameters en bekende exploitpatronen.
• Malware-scanning en detectie (Basis)
  • Continue scanning identificeert nieuw toegevoegde kwaadaardige bestanden, geïnjecteerde scripts in de database en verdachte thema/plugin-wijzigingen.
• Automatische malwareverwijdering en IP-zwart/witlijsten (Standaard)
  • Het standaardplan omvat automatische opruimcapaciteiten voor veelvoorkomende dreigingshandtekeningen en de mogelijkheid om snel tot 20 IP's te blokkeren of toe te staan.
• Automatische kwetsbaarheid virtuele patching (Pro)
  • Als er een nieuwe kwetsbaarheid wordt onthuld en een onmiddellijke plugin-update geen optie voor je is, biedt onze Pro-aanbieding automatische virtuele patching — een tijdelijke beschermende regelset die op de WAF-laag wordt toegepast en de exploitatievector neutraliseert totdat je de patch van de leverancier kunt toepassen.
• Monitoring en maandelijkse beveiligingsrapporten (Pro)
  • Krijg een hoog niveau overzicht van pogingen tot aanvallen, geblokkeerde gebeurtenissen en aanbevelingen voor verhoging van de beveiliging.
• Incidentrespons en ondersteuningsadd-ons (Pro en beheerde diensten)
  • Voor gecompromitteerde sites omvat onze beheerde beveiligingsdienst opruiming, forensische analyse en herversteviging.

Praktische opmerking: firewallregels moeten zorgvuldig worden afgesteld om te voorkomen dat legitieme pluginfunctionaliteit wordt verbroken. Ons team test en past regels toe in een stagingomgeving voordat ze breed worden uitgerold.

---

Ontwikkelaarsrichtlijnen — hoe de plugin moet worden gerepareerd

De juiste, langdurige oplossing voor een gereflecteerde XSS zit in de plugincode: valideer en saniteer alle binnenkomende invoer en voer altijd contextbewuste escaping uit op de output. Specifieke principes:

1. Valideer invoer vroeg
   • Als een parameter wordt verwacht een URL te zijn, valideer deze via filter_var of esc_url_raw en zorg ervoor dat deze overeenkomt met het verwachte patroon.
   • Als het numeriek is, cast naar int of gebruik absint().
2. Sanitize invoer
   • Gebruik sanitize_text_veld(), sanitize_textarea_field(), esc_url_raw() zoals passend voor het parameter type.
3. Escape op output (contextbewust)
   • Voor HTML-body-inhoud: gebruik esc_html().
   • Voor HTML-attributen: gebruik esc_attr().
   • Voor inline JavaScript-context: gebruik esc_js().
   • Voor XML/JSON-output: gebruik wp_json_encode().
   • Voor toegestane HTML, gebruik wp_kses() met een whitelist van toegestane tags en attributen.
4. Vermijd het weergeven van ruwe gebruikersinvoer in de paginamarkup.
5. Gebruik capaciteitscontroles en nonces voor acties die de status veranderen.
6. Gebruik voorbereide statements voor databasequery's (wpdb->voorbereiden) om SQL-injectie te voorkomen.
7. Log verdachte invoer voor auditing en monitoring.

Voorbeeld: veilige output in een sjabloon (hoog-niveau PHP-snippet)

<?php

Als de inhoud beperkte HTML moet bevatten, gebruik wp_kses():

<?php

Ontwikkelaars moeten ook geautomatiseerde eenheid- en integratietests toevoegen die verifiëren dat invoer correct is gesaneerd en ontsnapt voordat deze wordt weergegeven.

---

Checklist na een incident: wat te doen als je denkt dat je bent uitgebuit

Als je site tekenen van compromittering vertoont, volg dan deze checklist voor containment en herstel:

1. Isoleren
   • Zet de site in onderhoudsmodus of schakel openbare toegang tijdelijk uit indien mogelijk.
2. Back-up
   • Maak een onmiddellijke back-up van bestanden en DB (bewaar bewijs).
3. Scannen
   • Voer volledige malware-scans uit (bestandssysteem + DB). Gebruik indien nodig meerdere scanners.
4. Opnieuw instellen
   • Draai alle administratieve wachtwoorden, applicatiesleutels en API-sleutels.
   • Ongeldig alle actieve sessies (plugin of aangepaste code kan helpen).
5. Verwijder kwaadaardige inhoud
   • Herstel bestanden vanuit een schone back-up (voor compromittering) waar mogelijk.
   • Verwijder onbekende beheerdersgebruikers en verdachte berichten/plugins/thema's.
6. Patch
   • Pas de patch van de leverancier toe (update Radio Player naar 2.0.83).
   • Update de WordPress-kern, thema's en alle plugins.
7. Versterken
   • Pas de hardening-stappen toe die in dit artikel worden beschreven (WAF-regels, CSP, 2FA).
8. Forensische analyse
   • Identificeer de tijdlijn van de aanval en de oorzaak. Bewaar logs voor onderzoek.
9. Rapporteren.
   • Als de compromittering gebruikersgegevens heeft blootgesteld, volg dan de toepasselijke wetten en informeer de getroffen gebruikers.
10. Post-mortem
    • Documenteer de lessen die zijn geleerd en werk interne processen bij.

Als je professionele hulp nodig hebt om op te schonen en te herstellen, schakel dan een specialist in met ervaring in WordPress-incidentrespons.

---

Aanbevelingen voor langdurige verharding en monitoring

• Handhaaf automatische updates voor kleine releases waar mogelijk. Test grote updates op staging.
• Gebruik een beheerde Web Application Firewall met de mogelijkheid voor virtuele patching.
• Handhaaf een offline back-upretentiebeleid. Maak regelmatig back-ups van zowel bestanden als DB.
• Vereis twee-factor-authenticatie (2FA) voor alle beheerders.
• Handhaaf sterke wachtwoordbeleid en overweeg SSO voor bedrijfsinstellingen.
• Monitor logs en stel waarschuwingen in voor ongebruikelijke patronen (meerdere mislukte inlogpogingen, lange querystrings, nieuwe admin-gebruikerscreatie).
• Controleer regelmatig de geïnstalleerde plug-ins en verwijder de plug-ins die u niet gebruikt.
• Abonneer je op kwetsbaarheidsfeeds of een beheerde beveiligingsdienst zodat je snel op de hoogte bent van nieuwe openbaarmakingen.
• Voer statische code-analyse of codebeoordelingen uit op aangepaste plugins/thema's voordat je deze implementeert.

---

Gratis bescherming beschikbaar van WP‑Firewall

Onmiddellijke bescherming hoeft je niets te kosten. WP‑Firewall Basic (Gratis) omvat essentiële, altijd actieve bescherming die geschikt is voor de meeste sites die een sterke defensieve basis willen:

• Beheerde firewall en WAF-regels op maat gemaakt voor WordPress
• Onbeperkte bandbreedte om verloren verkeer te voorkomen tijdens het filteren van aanvallen
• Malware-scanner om geïnjecteerde bestanden en kwaadaardige database-inhoud te detecteren
• Mitigatie voor OWASP Top 10-risico's (inclusief XSS-patronen)
• Eenvoudige installatie en continue monitoring zodat je met vertrouwen kunt opereren

Als je je site snel wilt beveiligen, meld je dan hier aan voor WP‑Firewall Basic:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Als je automatische virtuele patching en ondersteuning voor incidentrespons nodig hebt, zie dan onze Standaard- en Pro-niveaus — zij bieden automatische malwareverwijdering, IP-controles, virtuele patching, maandelijkse rapporten en beheerde beveiligingsdiensten.)

---

Veelgestelde vragen

Q: Als ik update naar 2.0.83, ben ik dan volledig veilig?
A: Updaten is de juiste remedie voor deze kwetsbaarheid. Zodra je hebt geüpdatet, zou de plugin niet langer kwetsbaar moeten zijn voor de gerapporteerde gereflecteerde XSS. Als je site echter vóór de patching is uitgebuit, moet je nog steeds scannen en schoonmaken om eventuele achtergebleven kwaadaardige artefacten te verwijderen.

Q: Zal het gebruik van een WAF de functionaliteit van de Radio Player-plugin verstoren?
A: Een goed afgestelde WAF zou de legitieme functionaliteit van de plugin niet moeten verstoren. Blokregels moeten contextbewust zijn. WP‑Firewall test veelgebruikte plugins en past regels toe op een manier die valse positieven minimaliseert. Als een regel functionaliteit verstoort, zal ons ondersteuningsteam helpen om uitzonderingen aan te passen.

Q: Moet ik de plugin verwijderen in plaats van te updaten?
A: Als je de plugin niet nodig hebt, vermindert het verwijderen ervan het aanvaloppervlak en is het een redelijke optie. Als je de plugin nodig hebt, update dan naar de gepatchte versie. Verwijder altijd ongebruikte plugins en thema's.

---

Eindaanbevelingen

1. Controleer of uw site de Radio Player-plugin gebruikt. Zo ja, werk dan onmiddellijk bij naar 2.0.83.
2. Maak een back-up voordat u iets wijzigt en scan uw site op bewijs van compromittering.
3. Implementeer kortetermijnmaatregelen als u niet onmiddellijk kunt patchen — WAF-regels, IP-beperkingen, CSP, cookie-versteviging en controle op admin-toegang.
4. Overweeg een gelaagde, beheerde beveiligingsaanpak: WAF + malware-scanning + virtueel patchen (voor kritieke vensters waarin updates moeten wachten).
5. Voor ontwikkelaars: neem strikte invoervalidatie, escaping en contextbewuste uitvoerhandling in alle code aan.

Beveiliging is een continu proces. Kwetsbaarheden zoals die voor de Radio Player-plugin zijn een herinnering om een sterke, gelaagde verdediging te behouden en plugins up-to-date te houden. WP-Firewall is ontworpen om u een snelle, beheerde laag van bescherming en zichtbaarheid te bieden, zodat u risico's kunt verminderen en snel kunt reageren wanneer nieuwe bedreigingen zich voordoen.

---

Als u een gratis, beheerde laag van bescherming wilt die een WAF, malware-scanning en OWASP-mitigatie omvat, zodat u onmiddellijk actie kunt ondernemen terwijl u patcht en herstelt, overweeg dan ons Basisplan: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Let op je veiligheid,
WP-Firewall Beveiligingsteam