Pluginnaam	Templatera
Type kwetsbaarheid	XSS (Cross-Site Scripting)
CVE-nummer	CVE-2025-54747
Urgentie	Laag
CVE-publicatiedatum	2025-08-14
Bron-URL	CVE-2025-54747

WordPress Templatera (≤ 2.3.0) — XSS-advies, impact en hoe WP‑Firewall u beschermt

Auteur: WP-Firewall Beveiligingsteam
Datum: 14 augustus 2025

---

Samenvatting: Een Cross-Site Scripting (XSS)-kwetsbaarheid die de Templatera-plug-in (versies ≤ 2.3.0) treft, is openbaar gemaakt en kreeg CVE-2025-54747 toegewezen. Het probleem stelt een gebruiker met rechten op Contributor-niveau in staat om JavaScript/HTML in sjablonen te injecteren die kunnen worden uitgevoerd in de browser van sitebeheerders of bezoekers. De leverancier heeft het probleem opgelost in versie 2.4.0. In deze waarschuwing leggen we het risico uit, hoe aanvallers er misbruik van kunnen maken (en niet kunnen), welke directe inperkingsmaatregelen er zijn, hoe u op de lange termijn maatregelen kunt nemen en welke specifieke bescherming u kunt inschakelen met WP-Firewall om het aanvalsoppervlak te verkleinen totdat u de publisher-fix toepast.

Dit artikel is geschreven vanuit een praktisch WordPress-beveiligingsperspectief: praktische richtlijnen voor site-eigenaren, beheerders en ontwikkelaars.

---

Inhoud

• Wat werd gerapporteerd
• Waarom dit belangrijk is (dreigingsmodel en impact)
• Wie loopt er risico?
• Indicatoren van compromittering en detectietips
• Onmiddellijke inperking (wat u nu moet doen)
• Volledige sanering (updaten, opschonen, valideren)
• Hoe WP-Firewall u beschermt (virtueel patchen, WAF-regels, scannen)
• Aanbevolen WAF-handtekeningen en blokkeringsheuristieken (voorbeelden)
• Verharding en beste praktijken op lange termijn
• Voor ontwikkelaars: hoe los je het probleem bij de bron op (richtlijnen voor sanering)
• Checklist voor incidentrespons
• Bescherm uw site met ons gratis Basis-abonnement

---

Wat werd gerapporteerd

Er is een Cross-Site Scripting (XSS)-kwetsbaarheid ontdekt in de Templatera-plugin voor WordPress (versies tot en met 2.3.0). Het probleem wordt geregistreerd als CVE-2025-54747 en werd medio augustus 2025 gepubliceerd. De ontwikkelaar heeft een gecorrigeerde versie 2.4.0 uitgebracht.

Belangrijkste feiten:

• Kwetsbaarheidstype: Cross-Site Scripting (XSS)
• CVE: CVE‑2025‑54747
• Betrokken versies: Templatera ≤ 2.3.0
• Vastgesteld in: 2.4.0
• Gerapporteerd door: onafhankelijke onderzoeker (vermeld)
• Vereiste bevoegdheid: Bijdrager (kan sjablonen maken of bewerken)
• CVSS: De auteur van de patch gaf een score van 6,5 (gemiddelde/lage drempel, afhankelijk van de context)

Hoewel niet elke site automatisch wordt gecompromitteerd, is de kwetsbaarheid ernstig omdat gebruikers met minder rechten actieve inhoud in sjablonen kunnen injecteren. Deze kunnen worden uitgevoerd in de browsers van beheerders, redacteuren of zelfs openbare bezoekers, afhankelijk van hoe de sjablonen worden gebruikt.

---

Waarom dit belangrijk is – dreigingsmodel en impact

XSS is een injectiekwetsbaarheid waarbij een aanvaller JavaScript (of HTML die de uitvoering activeert) in content kan plaatsen die later in de browser van een slachtoffer wordt weergegeven. De praktische risico's zijn onder meer:

• Sessietokens of authenticatiecookies stelen (als cookies niet worden beschermd door HttpOnly of als beheerderspagina's tokens aan de clientzijde lezen).
• Bevoorrechte acties uitvoeren in de context van een beheerderssessie (CSRF + XSS gecombineerd).
• Het injecteren van persistente payloads, zoals site-defacing HTML, schadelijke omleidingen, cryptojackingscripts of ongewenste advertenties.
• Het leveren van secundaire payloads aan bezoekers (kwaadaardige JavaScript die externe malware laadt).

Deze kwetsbaarheid is met name zorgwekkend omdat:

• Het vereiste privilege is Contributor – een rol die vaak wordt gebruikt voor gastauteurs of externe contentmakers. Veel sites kennen dit niveau toe aan vertrouwde contractanten, gastbloggers of community-bijdragers.
• Sjablonen kunnen op meerdere pagina's worden hergebruikt. Een kwaadaardige sjabloon kan echter meerdere pagina's of beheerdersschermen aantasten.
• Als de inhoud van een sjabloon wordt weergegeven in beheerdersschermen (om een voorbeeld te bekijken of te bewerken), kunnen beheerders hier risico's mee lopen.

Aanvallers automatiseren exploits voor plugin-kwetsbaarheden; zelfs kwetsbaarheden met een lage complexiteit kunnen snel als wapen worden ingezet.

---

Wie loopt er risico?

• Sites die de Templatera-plug-in ≤ 2.3.0 gebruiken.
• Sites die niet-vertrouwde gebruikers toestaan zich te registreren of inhoud bij te dragen op het niveau van Contributor (of hoger).
• Multisite-netwerken waar sjablonen worden gedeeld of waar bijdragers sjablonen kunnen maken.
• Sites met slechte sessie- of cookiebeveiliging (ontbrekende HttpOnly, SameSite, beveiligde vlaggen) of zonder extra browserbeveiliging (inhoudsbeveiligingsbeleid).

Als uw locatie aan een van de bovenstaande voorwaarden voldoet, beschouw dit dan als een uitvoerbaar proces: voer onmiddellijk maatregelen uit om het probleem in te dammen en te verhelpen.

---

Indicatoren van compromis (IoC's) en detectietips

Let bij het controleren op misbruik van een XSS-kwetsbaarheid op het volgende:

• Onverwachte JavaScript in sjablooninhoud: zoek thema-/plug-in-/sjabloonvermeldingen in de database (wp_posts, wp_postmeta, wp_usermeta als sjablonen in meta zijn opgeslagen).
• Nieuwe/gewijzigde sjablonen door gebruikers die geen sjablonen zouden moeten bewerken (controleer de velden wp_posts post_author en post_modified).
• Verdachte HTML-kenmerken in sjabloonnamen, titels, beschrijvingen of inhoud: bijvoorbeeld inline tags, onerror=, onload= handler attributes, javascript: URIs, data: URIs.
• Kennisgeving of voorbeeldweergave van beheerderspagina's met onbekende inhoud of pop-ups wanneer beheerders bepaalde schermen laden.
• Ongebruikelijke uitgaande verzoeken van de site naar domeinen van derden (cryptomining- of analyse-eindpunten).
• Inlogpogingen of sessieafwijkingen voor beheerdersaccounts rond het moment dat de sjabloon is gemaakt/gewijzigd.
• Waarschuwingen van WP-Firewall-scanners of vlaggen van malware-scanners die geïnjecteerde JavaScript markeren.

Zoek naar voorbeelden (SQL) om voor de hand liggende scriptinjecties te vinden:

SELECT ID, post_titel, post_auteur, post_datum, post_gewijzigd VAN wp_posts WAAR post_inhoud ZOALS '%

Opmerking: sommige legitieme inhoud kan omvatten (e.g., embeds). Review results carefully.

---

Onmiddellijke inperking - wat u nu moet doen

Als u de plug-in niet direct kunt bijwerken (om operationele redenen), voert u de volgende containmentstappen uit:

1. Tijdelijk de privileges van Contributor-sjablonen intrekken
   Beperk wie sjablonen kan maken of bewerken. Verwijder de mogelijkheid voor bijdragers om sjablonen te beheren als de plugin functionaliteitshooks beschikbaar stelt waarop u kunt filteren.
2. Schakel sjabloonvoorbeelden uit in het beheer (indien mogelijk)
   Als de beheerdersvoorvertoning sjablooninhoud weergeeft, kunt u dit tijdelijk uitschakelen of beperken om automatische uitvoering in de browsers van beheerders te voorkomen.
3. Werk WP-Firewall WAF-regels bij / blokkeer algemene XSS-payloads
   Schakel strikte WAF-regels in voor POST-aanvragen naar bekende Templatera-eindpunten en beheer-POST-eindpunten (wij bieden virtuele regels en handtekeningen).
4. Dwing beheerders om nieuwe sessies te gebruiken
   Sessies voor beheerdersgebruikers resetten (indien nodig de toepassingszouten roteren) of alle gebruikers geforceerd afmelden om mogelijk gestolen sessies ongeldig te maken.
5. Beperk het bewerken van bestanden en plug-ins
   Schakel plug-ins en thema-editors voorlopig uit om verdere ongeoorloofde bewerkingen te voorkomen.
6. Controleer recente activiteit van bijdragers
   Bekijk recent aangemaakte/bewerkte sjablonen, berichten en uploads van Contributor-accounts.
7. Scan de site
   Voer een snelle scan uit op malware en het bestandssysteem. Kijk of er geïnjecteerde bestanden of wijzigingen in de kern-/plug-in-/themabestanden zijn.

Bij inperking gaat het om het beperken van de directe blootstelling en het voorbereiden van volledige sanering.

---

Volledige sanering – update en opschoning

1. Werk de plugin onmiddellijk bij naar 2.4.0 of later
   Pas de officiële patch van de leverancier toe. Dit is de belangrijkste aanbeveling: versie 2.4.0 bevat de oplossing voor de XSS-vector.
2. Controleer en verwijder schadelijke sjablonen
   Auditsjablonen die vóór de patch zijn gemaakt. Verwijder of reinig inhoud met scripttags, gebeurtenis-handlers, JavaScript: URI's of verdachte coderingen.
3. Geheimen roteren
   Herstel beheerderswachtwoorden. Als u vermoedt dat er cookies of sessies zijn gestolen, kunt u de authenticatie-salts (AUTH_KEY, SECURE_AUTH_KEY, enz.) in wp-config.php wijzigen. Hierdoor worden alle sessies ongeldig.
4. Database-inhoud saneren
   Als sjablonen zijn opgeslagen in postcontent of postmeta, reinig dan de velden. Zoek naar base64-gecodeerde payloads en ongebruikelijke HTML-coderingen.
5. Controleer op persistentie
   Zoek naar webshells, cronjobs, geplande gebeurtenissen of nieuwe beheerdersgebruikers die kunnen wijzen op een dieperliggend gevaar.
6. Terugdraaien of herstellen indien nodig
   Als u een wijdverspreide inbreuk constateert en het opruimen ervan complex is, herstel dan vanaf een schone back-up die is gemaakt vóór het moment van de exploit.
7. Monitoren en scannen
   Voer na het opschonen gedurende meerdere dagen herhaalde scans uit en controleer de logboeken op gerelateerde verkeerspatronen.

Als u professionele hulp nodig heeft, schakel dan een WordPress incident response team in. Een volledige forensische analyse wordt aanbevolen als u vermoedt dat beheerdersreferenties of serverbestanden zijn gecompromitteerd.

---

Hoe WP-Firewall u beschermt (virtueel patchen, WAF en scannen)

Bij WP‑Firewall ontwerpen we gelaagde bescherming die het risicovenster tussen openbare bekendmaking en het patchen van plug-ins minimaliseert:

• Beheerde WAF-regels gericht op deze Templatera-kwetsbaarheid.
  • We implementeren regels voor aanvraaginspectie die verdachte POST's en bestandsinhoud blokkeren die naar de plug-in-eindpunten en admin-ajax-eindpunten gaan die zijn gekoppeld aan het opslaan en weergeven van sjablonen.
• Virtueel patchen (vPatch).
  • Onze vPatching-engine creëert op handtekeningen gebaseerde en heuristische filters die exploit-payloads aan de edge tegenhouden, zelfs als de kwetsbare plug-in nog steeds is geïnstalleerd en niet is gepatcht.
• Malwarescanner en controle van de inhoudsintegriteit.
  • We scannen berichten, sjablonen, geüploade bestanden en thema-/pluginbestanden op verdachte inline JavaScript en bekende payloads.
• Gedragsdetectie.
  • We markeren accounts die ongebruikelijke sjabloonbewerkingen uitvoeren, wijzigingen in het aantal berichten en snelle wijzigingen in de inhoud die kenmerkend zijn voor geautomatiseerde aanvallen.
• Snelheidsbeperking en IP-blokkering.
  • Bij vermoedelijke misbruikpatronen die afkomstig zijn van geautomatiseerde scanners, beperken of blokkeren we de betreffende IP's en gebruikersagents.

Als u WP-Firewall hebt geactiveerd, raden we u aan om virtuele patching en het strikte WAF-profiel in te schakelen terwijl u de plugin bijwerkt. Deze maatregelen verkleinen de kans dat een XSS op bijdragersniveau een beheerder wordt en bieden directe bescherming zonder downtime.

---

Aanbevolen WAF-handtekeningen en blokkeringsheuristieken (voorbeeldregels)

Hieronder vindt u voorbeelden van detectie- en blokkeringsheuristieken die u in een WAF kunt implementeren. Deze worden gepresenteerd voor educatieve doeleinden. WP-Firewall onderhoudt afgestemde productieregels om foutpositieve resultaten te voorkomen.

1. Blokkeer verzoeken die scripttags bevatten op plaatsen waar normaal gesproken sjabloontitels/-identificatiegegevens worden bewaard:
   • Patroon: POST-body's waarbij 'template_title' of soortgelijke velden “
   • Voorbeeld regex (pseudo):
     (?i)(<\s*script\b|onerror\s*=|onload\s*=|javascript\s*:)
2. Blokkeer verzoeken met verdachte coderingen:
   • Detect %3Cscript or base64 encoded javascript in POST fields:
     (?i)(%3C\s*script|data:text/html;base64|base64,PHNjcmlwdA==)
3. Blokkeer AJAX-aanroepen van beheerders naar sjabloonopslageindpunten wanneer payloads inline-scripts bevatten:
   • Controleer POST naar /wp-admin/admin-ajax.php met action=templatera_save (of equivalent) en blokkeer als de inhoud scriptpatronen bevat.
4. Heuristiek voor het detecteren van UX-stijl event handler-injectie:
   • Zoek naar kenmerken die beginnen met 'on' gevolgd door letters in de invoervelden van de gebruiker:
     (?i)op[az]+\s*=\s*["']?[^"'\s>]+
5. Voorkom dat XSS wordt gereflecteerd door queryparameters:
   • Blokkeer GET-aanvragen die niet-vertrouwde, door de gebruiker opgegeven waarden bevatten en die worden weergegeven in inhoud met scriptpatronen.
6. Content Security Policy (CSP) afdwingen voor het beheerdersgedeelte:
   • Voorbeeldheader om de impact van XSS in de administratie te verminderen:
     Content-Security-Policy: standaard-bron 'zelf'; script-bron 'zelf' 'nonce- '; object-src 'geen'; base-uri 'zelf';

Opmerking: CSP moet zorgvuldig worden getest, aangezien strikte beleidsregels plug-ins en beheerdersinterfaces kunnen verstoren.

---

Verharding en beste praktijken op lange termijn

Los van het repareren van de specifieke plugin, moet u uw WordPress-site beschermen tegen toekomstige injectieproblemen:

• Beginsel van de minste privileges
  Ken alleen de rol 'Bijdrager' (en hoger) toe aan vertrouwde gebruikers. Heroverweeg workflows die externe medewerkers de mogelijkheid bieden om sjablonen te bewerken.
• Auditing van rolcapaciteiten
  Gebruik een machtigingsplugin of aangepaste code om te beperken welke mogelijkheden beschikbaar zijn voor welke rollen. Verwijder of filter pluginmogelijkheden die het maken van sjablonen voor rollen met een laag vertrouwen mogelijk maken.
• Inhoudssanering
  Zorg ervoor dat de plugin voor velden die HTML accepteren een veilige subset gebruikt (bijv. wp_kses of wp_kses_post) en gevaarlijke kenmerken (on*, javascript:, data:) verwijdert.
• Gebruik HttpOnly en veilige cookies
  Cookies die met HttpOnly zijn ingesteld, kunnen niet worden gelezen door JavaScript aan de clientzijde.
• Contentbeveiligingsbeleid (CSP) implementeren
  Gebruik CSP in beheer om te beperken waar scripts kunnen worden geladen.
• Houd een patchschema aan
  Zorg voor een updatebeleid en test updates in de testfase voordat u ze in productie neemt.
• Gebruik monitoring en logging
  Houd beheerdersaanmeldingen, bestandswijzigingen en ongebruikelijke uitgaande verzoeken in de gaten.
• Geautomatiseerde back-ups met versiebeheer
  Met dagelijkse back-ups met retentie kunt u indien nodig herstellen naar een staat van vóór de exploitatie.

---

Voor ontwikkelaars: XSS bij de bron repareren

Als u een plugin- of themaontwikkelaar bent, volg dan deze best practices om XSS te vermijden:

• Desinfecteren bij invoer, ontsnappen bij uitvoer
  Voor opgeslagen HTML die bedoeld is om markup op te nemen, valideer en desinfecteer je invoer- en escape-attributen en uitvoer in admin- en publieke contexten. Gebruik wp_kses() met een toegestane taglijst.
• Gebruik WordPress-functies
  esc_html(), esc_attr(), wp_kses_post(), wp_kses_data() enz.
• Voorkom dat niet-vertrouwde gebruikersinhoud rechtstreeks in de beheerdersinterface wordt weergegeven
  Behandel inhoud ook in beheerdersschermen als niet-vertrouwd. Beheerders zijn ook gebruikers en hun browsers kunnen het doelwit zijn van aanvallen.
• Gebruik mogelijkheden consistent
  Controleer current_user_can() voordat u inhoud opslaat of weergeeft die andere gebruikers kan beïnvloeden.
• Gebruik nonces en capaciteitscontroles voor AJAX-eindpunten
  Valideer verzoeken met check_admin_referer() of wp_verify_nonce() en controleer op de juiste capaciteit.
• Controleer bibliotheken en ontsmettingsmiddelen van derden
  Zorg ervoor dat de bibliotheek die wordt gebruikt om sjablonen weer te geven, de opschoning niet omzeilt.

---

Checklist voor incidentrespons (snel naslagwerk)

1. Identificeren: Bevestig de plug-in en versie. Let op tijdstempels en verdachte gebruikersaccounts.
2. Bevat: Trek tijdelijk de rechten van bijdragesjablonen in, schakel voorbeelden uit en schakel strikte WAF-regels in.
3. Patch: Werk Templatera zo snel mogelijk bij naar 2.4.0 (of later).
4. Opschonen: verwijder ingespoten sjablonen/inhoud, reinig de database, reset gecompromitteerde inloggegevens.
5. Herstellen: Indien nodig, herstel vanaf een vertrouwde back-up.
6. Monitoren: Logboeken bekijken, scannen op persistentie, uitgaande verbindingen onderzoeken op exfiltratie.
7. Leren: Bekijk hoe het bijdragersaccount rechten heeft verkregen en dicht de kloof.

---

Echte aanvalsscenario's en hoe ze zich afspelen

• Scenario A (gerichte overname door de beheerder)
  Een aanvaller met een Contributor-account maakt een sjabloon met een script dat cookies naar een door de aanvaller beheerde server stuurt. Wanneer een beheerder een voorbeeld van de sjablonen bekijkt in de beheerdersinterface, wordt het script uitgevoerd, wordt de sessiecookie verzonden en gebruikt de aanvaller deze om toegang te krijgen tot het beheerdersdashboard.
  Beperkingen: Beheerdersvoorbeelden uitgeschakeld, HttpOnly-cookies, WAF blokkeert scriptpayloads, beheerders moeten opnieuw worden geverifieerd.
• Scenario B (massale infectie van openbare pagina's)
  De aanvaller publiceert een template die veel gebruikt wordt op de site en die een cryptominerscript in openbare pagina's injecteert. Bezoekers laden het script en de site wordt een distributiepunt voor cryptomining.
  Beperkingen: WAF detecteert uitgaande verbindingen naar bekende miningdomeinen, een malwarescanner markeert het geïnjecteerde script, waarna de malware snel wordt verwijderd en de inhoud wordt opgeschoond.

Als u inzicht hebt in echte aanvalsketens, kunt u de juiste verdediging kiezen (blokkeren aan de rand of interne content opruimen).

---

Detectieafstemming en het vermijden van vals-positieve resultaten

Bij het afstemmen van WAF-regels en virtuele patches moet u een balans vinden tussen het blokkeren van echte aanvallen en het voorkomen dat legitieme toepassingen van HTML in sjablonen worden verstoord:

• Gebruik whitelists voor bekende beheerders-IP-adressen tijdens de eerste afstemming.
• Test regels in de detectie-/logmodus voordat u overschakelt naar blokkeren.
• Geef beheerdersmeldingen weer in plaats van een volledige blokkering wanneer een actie de redactionele workflow kan verstoren.
• Gebruik context: als een veld markup (sjabloontekst) moet bevatten, beperk dan specifieke gevaarlijke kenmerken in plaats van alle HTML te blokkeren.

WP‑Firewall biedt aanpasbare beleidsprofielen (Strikt, Gebalanceerd, Permissief) zodat teams regels veilig kunnen testen.

---

Waarom onmiddellijk updaten, zelfs voor problemen met ‘lage prioriteit’?

Hoewel in deze waarschuwing wordt aangegeven dat de kwetsbaarheid een lagere patchprioriteit heeft vergeleken met het uitvoeren van code op afstand of SQLi, zijn er goede redenen om snel actie te ondernemen:

• XSS is een krachtig draaipunt: het kan leiden tot inbreuk op beheerdersaccounts, data-exfiltratie en verdere code-uitvoering.
• Het komt vaak voor dat accounts met minder rechten worden gehackt, en veel sites staan standaard de rollen Contributor of Author toe.
• Aanvallers kunnen meerdere kwetsbaarheden aan elkaar koppelen (XSS + CSRF + zwakke sessieverwerking).
• Openbare bewijzen van exploits of scannerhandtekeningen zijn vaak binnen enkele dagen beschikbaar. Hoe langer u wacht met patchen, hoe groter de kans op kwetsbaarheid.

Kortom: een gemiddelde/lage CVSS betekent niet “geen actie”.

---

Bescherm uw site met ons gratis Basis-abonnement (Essentiële bescherming)

Titel: Ontvang essentiële SWIFT-bescherming voor uw WordPress-site — begin gratis

Als u onmiddellijke, beheerde bescherming wilt terwijl u plug-ins bijwerkt en uw site controleert, biedt WP‑Firewall een gratis Basis-abonnement dat essentiële bescherming omvat die speciaal is ontworpen voor scenario's zoals deze:

• Beheerde firewall met WAF-regels
• Onbeperkte bandbreedte
• Malwarescanner
• Beperking van de top 10-risico's van OWASP, inclusief XSS
• Continue monitoring en regelupdates

Meld u nu aan voor het gratis Basis-abonnement om een beheerde WAF, scans en basisbeveiligingen voor uw site te installeren terwijl u oplossingen van de leverancier toepast en een opschoning uitvoert: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(U kunt later upgraden naar Standard of Pro voor automatische verwijdering van malware, gedetailleerdere IP-controles of virtuele patches en maandelijkse beveiligingsrapporten.)

---

Eindnotities en aanbevolen vervolgstappen (actieplan)

1. Controleer meteen of uw site Templatera gebruikt en zo ja, welke versie.
2. Als u ≤ 2.3.0 gebruikt:
   • Plan een noodupdate naar 2.4.0 (test indien nodig in de staging-fase).
   • Schakel daarnaast WP-Firewall-beveiliging in (virtuele patch en strikt WAF-profiel).
   • Controleer recente bijdragersactiviteiten en sjablooninhoud.
3. Versterk de beheer- en sessiebeveiliging (HttpOnly-cookies, gedwongen herauthenticatie).
4. Voer een volledige scan van de site uit en controleer op ongebruikelijke activiteiten gedurende ten minste 72 uur na het herstel.
5. Bekijk het interne beleid voor de toegang van bijdragers tot sjablonen en redactionele workflows.

Als u hulp nodig heeft bij het implementeren van een van de bovenstaande stappen, kan het supportteam van WP-Firewall u helpen met het afstemmen van WAF, virtuele patching, het verwijderen van malware en een volledige incidentbeoordeling. Ons gratis Basic-abonnement biedt u direct geavanceerde bescherming; een upgrade naar Standard of Pro biedt geautomatiseerde verwijdering, virtuele patching en uitgebreidere incidentondersteuning.

---

Beveiliging is een continu proces: patch snel, monitor constant en verklein uw aanvalsoppervlak. Wilt u direct beheerde bescherming tijdens het updaten en controleren? Start dan vandaag nog met het Basic-abonnement van WP-Firewall: https://my.wp-firewall.com/buy/wp-firewall-free-plan/