| Pluginnaam | Form Maker door 10Web |
|---|---|
| Type kwetsbaarheid | SQL-injectie |
| CVE-nummer | CVE-2025-15441 |
| Urgentie | Hoog |
| CVE-publicatiedatum | 2026-04-14 |
| Bron-URL | CVE-2025-15441 |
Reageren op de Form Maker (< 1.15.38) SQL-injectie: Wat elke site-eigenaar en ontwikkelaar nu moet doen
Auteur: WP-Firewall Beveiligingsteam
Gepubliceerd: 2026-04-14
Trefwoorden: WordPress, Beveiliging, WAF, SQL-injectie, Incidentrespons, Plugin-kwetsbaarheid
Korte samenvatting: Een kritieke SQL-injectie (SQLi) kwetsbaarheid die de “Form Maker” plugin van 10Web (versies ouder dan 1.15.38, gevolgd als CVE‑2025‑15441) beïnvloedt, werd gepubliceerd op 14 april 2026. Het probleem stelt niet-geauthenticeerde aanvallers in staat om op maat gemaakte invoer te leveren die door de plugin op een onveilige manier kan worden geïnterpreteerd, waardoor directe interactie met de WordPress-database mogelijk is. Deze post legt risico, detectie, containment, remediëring en praktische WAF virtuele patching richtlijnen uit vanuit het perspectief van een WordPress Web Application Firewall-provider.
Inhoudsopgave
- Wat is er gebeurd (snel overzicht)
- Waarom SQL-injectie nog steeds belangrijk is voor WordPress
- Technische samenvatting van het Form Maker-probleem
- Bedreigingsmodel en waarschijnlijk aanvallersgedrag
- Onmiddellijke stappen voor site-eigenaren (0–24 uur)
- Tussentijdse stappen (24–72 uur)
- Hoe een WAF (virtuele patch) uw site beschermt
- Voorgestelde virtuele patch / WAF-regels en afstemmingsrichtlijnen
- Detecteren van compromittering en indicatoren van misbruik
- Incidentrespons checklist (gedetailleerd)
- Ontwikkelaarsrichtlijnen: de oorzaak van het probleem correct oplossen
- Operationele verharding en monitoring best practices
- Hoe WP-Firewall helpt uw WordPress-site te beschermen
- Bescherm uw site vandaag — begin met ons gratis plan
- Afsluitende gedachten en bronnen
Wat is er gebeurd (snel overzicht)
Op 14 april 2026 werd een openbaar advies bekendgemaakt over een SQL-injectie kwetsbaarheid in de Form Maker-plugin van 10Web die versies ouder dan 1.15.38 beïnvloedt. De kwetsbaarheid stelt niet-geauthenticeerde verzoeken in staat om codepaden te bereiken die kunnen worden gemanipuleerd om SQL-fragmenten in te voegen. De plugin-auteur heeft versie 1.15.38 met een patch uitgebracht; de aanbevolen onmiddellijke actie voor alle site-eigenaren is om te updaten naar 1.15.38 of later.
Omdat dit een niet-geauthenticeerde SQLi is in een veelgeïnstalleerde formulierverwerkingsplugin, is het venster voor massale exploitatie reëel: geautomatiseerde scanners en exploitkits zullen sites targeten die niet zijn bijgewerkt. Het beschermen van uw site vereist snelle actie, en — wanneer u de plugin-update niet onmiddellijk kunt toepassen — kan virtuele patching met een WAF exploitatie voorkomen.
Waarom SQL-injectie nog steeds belangrijk is voor WordPress
WordPress-sites bestaan uit core, thema's en plugins. Plugins die gebruikersinvoer accepteren — vooral plugins die formulier-eindpunten, logging-eindpunten, import/export-functies of oppervlakkige invoersanitatie blootstellen — zijn risicovolle centra voor SQL-injectie.
Waarom SQLi gevaarlijk is:
- Directe database-interactie: SQLi maakt het mogelijk om de database te lezen of te wijzigen, wat gebruikersgegevens (inclusief gehashte inloggegevens, e-mails, formulierindieningen) en site-metadata kan blootstellen.
- Persistentie: aanvallers kunnen beheerdersgebruikers, achterdeurtjes of geplande taken toevoegen die blijven bestaan, zelfs nadat de voor de hand liggende kwetsbaarheid is verholpen.
- Gegevensexfiltratie en pivoteren: een succesvolle exploit kan een uitvalsbasis zijn voor laterale beweging (het uploaden van shells, toegang tot andere interne gegevens).
- Automatisering: zodra een exploit openbaar is, schalen massascans en geautomatiseerde aanvallen snel naar duizenden sites.
Zelfs een plugin die wordt gebruikt om formulieren weer te geven — schijnbaar onschuldig — kan parameters blootstellen die aan SQL-query's worden doorgegeven. Een combinatie van niet-gevalideerde parameters, ontbrekende voorbereide instructies of dynamische SQL-concatenatie leidt tot injectierisico's.
Technische samenvatting van het Form Maker-probleem
- Aangetaste software: Form Maker (plugin van 10Web).
- Kwetsbare versies: elke versie vóór 1.15.38.
- Gepatcht in: 1.15.38.
- CVE-referentie: CVE‑2025‑15441.
- Aanvalsvlak: openbare formulierverwerkings-eindpunten (HTTP GET/POST-parameters), niet-geauthenticeerde aanroepen.
- Impact: willekeurige SQL-injectie — aanvallers kunnen lezen van of schrijven naar de database, mogelijk gevoelige inhoud exfiltreren of administratieve toegang creëren.
- Kans op exploitatie: hoog voor niet-gepatchte openbare sites omdat formulier-eindpunten doorgaans bereikbaar zijn en scanners actief WordPress-formulier-eindpunten doorzoeken.
Belangrijk: Terwijl de gepubliceerde waarschuwing een CVSS-score bevat, hangt het werkelijke risico af van of uw site de kwetsbare eindpunten openbaar blootstelt, of u up-to-date back-ups heeft en uw detectie-/responspositie.
Bedreigingsmodel en waarschijnlijk aanvallersgedrag
Gezien een niet-geauthenticeerde SQLi in een plugin die formulieren verwerkt, zullen aanvallers doorgaans:
- Scannen naar WordPress-sites die Form Maker draaien (door plugin-slug + versie-enumeraties).
- Veelvoorkomende eindpuntpaden en parameters met SQL-payloads doorzoeken, inclusief union-select-patronen, booleaanse tests en tijdvertraging (sleep/benchmark) payloads.
- Als het succesvol is, eerst de aanwezigheid van de injectie valideren met blinde technieken (booleaans of tijdgebaseerd), en vervolgens proberen gegevens te extraheren: gebruikers tabel (wp_users), opties, postmeta en elke tabel gerelateerd aan formulierindieningen.
- Poging tot persistentie: een beheerdersgebruiker aanmaken, themabestanden wijzigen, een achterdeurtje PHP invoegen of kwaadaardige geplande taken toevoegen.
- Massale defacements, spampagina's of cryptocurrency-miners inzetten afhankelijk van de intentie.
Omdat veel site-eigenaren niet snel patchen, kan campagne-gedreven exploitatie zeer snel zijn. De snelheid van mitigatie is cruciaal.
Onmiddellijke stappen voor site-eigenaren (0–24 uur)
Als je een site host die Form Maker gebruikt, volg dan onmiddellijk deze stappen:
- Update de plug-in (beste optie)
- Log in op je WordPress-beheerder en werk Form Maker bij naar versie 1.15.38 of later. Dit verhelpt de onderliggende code en zou de kwetsbaarheid moeten verwijderen.
- Als automatische updates beschikbaar zijn en je vertrouwt je staging, schakel ze dan in voor de plugin.
- Als je niet onmiddellijk kunt updaten, neem dan noodcontainmentmaatregelen:
- Deactiveer de plugin tijdelijk (Plugins > Geïnstalleerde Plugins > Deactiveer Form Maker).
- Beperk de openbare toegang tot formulier-eindpunten via je hostcontrolepaneel of door HTTP-methoden of routes te blokkeren (bijv. toegang tot plugin-eindpunten ontzeggen met webserverregels).
- Als je een Web Application Firewall (WAF) draait, schakel dan de SQLi-bescherming in en pas een virtuele patch toe (zie WAF-richtlijnen hieronder).
- Maak een back-up van uw site
- Maak nu een volledige back-up: bestanden en database. Bewaar een offline kopie om te voorkomen dat deze wordt overschreven door een latere aanvaller.
- Inspecteer logs
- Onderzoek onmiddellijk de toegangslijsten van de webserver en de applicatielogs op verdachte payloads (zie detectie-indicatoren hieronder).
- Referenties roteren
- Wijzig de WordPress-beheerder wachtwoorden en eventuele database-inloggegevens als je een compromis vermoedt.
- Draai API-sleutels en geheimen die door de site worden gebruikt.
Als je bewijs van exploitatie ziet (nieuwe beheerdersgebruikers, onbekende bestandswijzigingen, ongebruikelijke databasequery's), ga dan naar de incidentrespons-checklist hieronder.
Tussentijdse stappen (24–72 uur)
- Voer een grondige integriteitscontrole uit:
- Vergelijk thema- en pluginbestanden met een bekende goede kopie.
- Verifieer checksums, zoek naar recent gewijzigde bestanden en bekijk wp-content/uploads op PHP-bestanden (een veelvoorkomende persistentievector).
- Scan op malware:
- Voer een volledige malware-scan van de site uit (woordkeuze: gebruik de scanner van je site of de door WAF geleverde scanner). Zoek naar geïnjecteerde PHP-backdoors, obfuscatiecode of geplande taken (wp_cron-invoeren).
- Herstellen en verhelpen:
- Als je persistente backdoors of onomkeerbare wijzigingen detecteert, herstel dan vanaf een schone back-up die vóór de compromis is gemaakt.
- Pas beveiligingspatches opnieuw toe, inclusief de plugin-update naar 1.15.38 of later.
- Uitharden en monitoren:
- Handhaaf het principe van de minste privilege: zorg ervoor dat alleen noodzakelijke gebruikers admin-mogelijkheden hebben.
- Zorg ervoor dat automatische updates zijn geconfigureerd voor kritieke platforms of plan regelmatige onderhoudsvensters.
- Zet een WAF in (indien nog niet gedaan) met afgestemde regels voor SQLi, gedragsgebaseerde detectie en IP-reputatiecontroles.
- Rapporteren en communiceren:
- Informeer belanghebbenden, klanten of gebruikers als gebruikersgegevens waarschijnlijk zijn blootgesteld.
- Houd een gedocumenteerde tijdlijn van acties bij voor auditing.
Hoe een WAF (virtuele patch) uw site beschermt
Een Web Application Firewall kan onmiddellijke mitigatie bieden wanneer een patch niet snel genoeg kan worden toegepast. Virtueel patchen werkt door kwaadaardige verzoeken op de HTTP-laag te onderscheppen en te blokkeren voordat ze kwetsbare code bereiken. Voor een SQLi in een formulierplugin kan een WAF:
- Verzoeken blokkeren die SQL-sleutelwoorden of verdachte payload-coderingen bevatten die gericht zijn op specifieke eindpunten.
- Strengere validatie afdwingen voor formulierinvoer (lengtebeperkingen, karakter-whitelisting).
- Toepassen van snelheidslimieten en CAPTCHAs op hoog-risico eindpunten om geautomatiseerde scanners te voorkomen.
- Algemene foutreacties of 403/429-codes retourneren wanneer kwaadaardige patronen worden gedetecteerd.
Virtueel patchen is een tijdelijke oplossing — essentieel in noodrespons — maar het moet worden gebruikt terwijl de plugin wordt bijgewerkt en de site volledig wordt schoongemaakt als er een compromis heeft plaatsgevonden.
Voorgestelde virtuele patch / WAF-regels en afstemmingsrichtlijnen
Hieronder staan voorbeeldpatronen en regels die een ervaren WAF-engineer zou implementeren om deze klasse van SQLi te mitigeren. Dit zijn algemene richtlijnen — uw WAF-product heeft zijn specifieke syntaxis (ModSecurity, Nginx lua, Cloud WAF-regels, enz.). Test regels zorgvuldig op staging voordat u ze in productie brengt.
- Beperk de regel nauwkeurig
- Richt u op verzoeken die Form Maker-eindpunten raken (bijv. paden onder /wp-content/plugins/form-maker/ of gedocumenteerde openbare eindpunten die door de plugin worden gebruikt).
- Vernauwen vermindert het risico van het blokkeren van legitiem verkeer.
- Blokkeer bekende SQLi-patronen (hoofdletterongevoelig):
- Zoek naar SQL-meta-tekens en controlepatronen in invoerparameters:
- UNIE SELECTEREN
- SELECT .* VAN
- INFORMATIE_SCHEMA
- SLEEP\(|BENCHMARK\(
- OF\s+1=1|EN\s+1=1
- Voorbeeld regex (pseudocode):
(?i)(\b(unie(\s+alle)?\s+kies|informatie_schema|slaap\(|benchmark\(|--\s|;|\ of\s+1=1\b)\b)
- Zoek naar SQL-meta-tekens en controlepatronen in invoerparameters:
- Blokkeer verdachte codering en obfuscatie:
- Detecteer percent-encoding of hex-gecodeerde payloads die SQL-tokens bevatten.
- Detecteer payloads met buitensporige concatenatie-operators of inline opmerkingen.
- Beperk invoerlengtes en tekenreeksen:
- Als het formulierveld een e-mailadres of naam verwacht, beperk dan tot een redelijke tekenreeks en maximale lengte.
- Voorbeeld: ontzeg als len(param) > 200 en param SQL-markeringen bevat.
- Beperk de snelheid van onbetrouwbare eindpunten:
- Pas agressieve snelheidslimieten toe op niet-geauthenticeerde formulier-eindpunten vanaf een enkel IP (bijv. 10–20 verzoeken per minuut).
- Wanneer limieten worden overschreden, vereis CAPTCHA of retourneer 429.
- Blokkeer tijdgebaseerde blinde SQLi-pogingen
- Detecteer SLEEP/Benchmark payloads en blokkeer verzoeken die tijdanomalieën veroorzaken.
- Volg cumulatieve vertragingpatronen van een enkel IP en escaleer blokkering.
- Ontzeg verdachte user-agents en aanvraagheaders
- Veel scanners gebruiken lage kwaliteit of lege User-Agent headers. Implementeer beleid om ontbrekende headers uit te dagen of te blokkeren.
- Voeg aangepaste handtekeninguitzonderingen toe
- Vermijd het blokkeren van goedaardige beheertools door uitzonderingen te creëren voor geauthenticeerde beheerdersgebruikers en geverifieerde administratieve servers (maar verwijder de bescherming niet volledig).
Belangrijk: WAF-regels kunnen valse positieven genereren. Gebruik gemonitorde blokkering (uitdaging eerst) modus totdat je stabiliteit bevestigt, en handhaaf dan blokkering. Log alles — logs zijn cruciaal voor forensisch onderzoek na incidenten.
Detecteren van compromittering en indicatoren van misbruik
Als de site werd doelwit of geëxploiteerd, let dan op deze tekenen:
- Nieuwe beheerdersaccounts in de WordPress-gebruikers tabel die je niet hebt aangemaakt.
- Onverwachte databasequery's in logs, of query's die grote rijen retourneren wanneer ze via formulier-eindpunten worden benaderd.
- Verhoogde CPU- of I/O-activiteit van de database.
- Onverklaarde bestandswijzigingen in wp-content (thema's, plugins, uploads) — vooral PHP-bestanden in uploads.
- Meldingen van uw beveiligingsscanner of WAF over SQLi-pogingen (union/select, sleep).
- Vreemde uitgaande netwerkverbindingen vanaf uw server (data-exfiltratie of callbacks).
- Google- of zoekmachinewaarschuwingen over malware of spam.
- Bezoekers die spammy pagina's, omleidingen of inlogfouten melden.
Wanneer u deze detecteert, bewaar logs en back-ups voordat u wijzigingen aanbrengt die bewijs kunnen overschrijven.
Incidentrespons checklist (gedetailleerd)
Als u bevestigt of sterk vermoedt dat er exploitatie plaatsvindt, volg dan deze gestructureerde reactie:
- Bevatten
- Zet de site in onderhoudsmodus of neem deze offline als data-exfiltratie aan de gang is.
- Deactiveer onmiddellijk de kwetsbare plugin.
- Pas onmiddellijke virtuele patchregels toe op de WAF voor de specifieke eindpunten.
- Bewijsmateriaal bewaren
- Maak volledige schijven en database-snapshots (alleen-lezen indien mogelijk).
- Archiveer webserver- en applicatielogs voor de periode van mogelijke compromittering.
- Beoordeel
- Bepaal de reikwijdte: welke gegevens en systemen zijn benaderd? Kijk naar query's, IP-adressen en tijdstempels.
- Controleer op persistentie-artifacten: web shells, gewijzigde thema's, nieuwe geplande evenementen, verdachte pluginbestanden.
- Uitroeien
- Verwijder web shells en backdoors.
- Vervang gecompromitteerde bestanden door schone kopieën (bijv. plugin uit de officiële repository).
- Als de inhoud van de database is gewijzigd, overweeg dan om te herstellen vanuit een bekende goede back-up of om kwaadaardige rijen chirurgisch te verwijderen.
- Herstellen
- Pas alle beveiligingsupdates toe (Form Maker 1.15.38+, WordPress-kern, andere plugins, thema's).
- Draai inloggegevens en API-sleutels.
- Verstevigen: bestandsmachtigingen, PHP-uitvoering in uploads uitschakelen, reikwijdte van databasegebruikersrechten.
- Na het incident
- Verbeter detectie: versnel WAF-regels, voeg monitoring en waarschuwingen toe voor verdachte SQL-patronen.
- Bereid een post-mortem voor: tijdlijn, beslissingen, hoofdoorzaak, herstelstappen en geleerde lessen.
- Meld getroffen gebruikers als persoonlijke gegevens zijn blootgesteld (volg toepasselijke wetten en beleidslijnen).
- Test
- Voer integriteits- en kwetsbaarheidsscans uit op een staging-kloon.
- Simuleer pogingen om opnieuw te exploiteren om mitigaties te verifiëren.
Ontwikkelaarsrichtlijnen: de oorzaak van het probleem correct oplossen
Als je een plugin- of thema-ontwikkelaar bent, is de juiste oplossing om onveilige SQL-constructies volledig te verwijderen. Aanbevolen coderingspraktijken:
- Gebruik geparameteriseerde query's
- Geef in WordPress de voorkeur aan
$wpdb->prepare()voor SQL-instructies die gebruikersinvoer bevatten. Voorbeeld:$sql = $wpdb->prepare( "SELECT * FROM $table WHERE id = %d", $id );
- Geef in WordPress de voorkeur aan
- Vermijd dynamische SQL die gebruikersinvoer direct samenvoegt.
- Valideer en normaliseer invoer
- Handhaaf server-side validatie voor invoertypen (gehele getallen, e-mails, slugs) voordat er toegang tot de DB is.
- Gebruik
sanitize_text_veld(),sanitize_email(),intval(),absint(), en soortgelijke helpers.
- Handhaaf strikt controle op bevoegdheden
- Als een eindpunt geprivilegieerde toegang vereist, controleer
huidige_gebruiker_kan()en valideer nonces.
- Als een eindpunt geprivilegieerde toegang vereist, controleer
- Escape output
- Gebruik bij het weergeven van gegevens
esc_html(),esc_attr(),esc_url()om XSS te voorkomen (apart probleem, maar gebruikelijk bij het versterken van plugins).
- Gebruik bij het weergeven van gegevens
- Minimaliseer DB-rechten
- Plugin DB-gebruikers mogen geen buitensporige rechten hebben; gebruik de normale DB-gebruiker van de site, maar vermijd het verlenen van bredere systeemtoegang.
- Voeg logging en waarschuwingen toe voor ongebruikelijke DB-activiteit.
Wanneer je de plugin-code repareert, voeg dan eenheid- en integratietests toe om invoer en randgevallen te valideren. Contextuele codebeoordeling en beveiligingsaudits (handmatig of geautomatiseerd) zijn essentieel.
Operationele verharding en monitoring best practices
Om je algehele beveiligingshouding te verbeteren:
- Houd WordPress, thema's en plugins up-to-date. Neem een patchbeleid en geplande onderhoudsvensters aan.
- Gebruik een WAF met:
- Virtuele patchingcapaciteit
- SQLi en OWASP Top 10 bescherming
- Botbeheer en IP-reputatie-throttling
- Handhaaf het principe van de minste privileges op WordPress-accounts en de database.
- Versterk de serveromgeving: schakel PHP-bestandsexecutie in uploads uit, gebruik veilige bestandsmachtigingen, schakel OS-niveau-updates in.
- Maak regelmatig een back-up en sla back-ups offsite op. Test herstelprocedures.
- Monitor logs en stel alarmdrempels in (bijv. verhoogde aanvraagpercentages naar formulier-eindpunten, herhaalde 4xx/5xx-fouten, hoge DB-CPU).
- Twee-factor-authenticatie voor alle administratieve accounts.
- Periodieke kwetsbaarheidsscans en penetratietests.
Hoe WP‑Firewall helpt uw WordPress-site te beschermen
Als een beheerde WordPress WAF-provider biedt WP‑Firewall beschermingslagen die direct relevant zijn voor de Form Maker SQLi:
- Beheerde firewall met aangepaste regelcreatie: ons team kan binnen enkele minuten virtuele patches implementeren tegen nieuw onthulde plugin-kwetsbaarheden om exploitpogingen te blokkeren voordat je kunt patchen.
- WAF (Web Application Firewall): handtekening- en gedragsgebaseerde regels die SQLi-patronen detecteren, waaronder union/select, tijdgebaseerde injectie en obfuscated payloads.
- Malware-scanner & mitigatie: continue scanning naar backdoors en verdachte bestandswijzigingen, plus herstelopties.
- OWASP Top 10 mitigatie: applicatielaagbescherming die de blootstelling aan injectie en andere webrisico's vermindert.
- Onbeperkte bandbreedte en beheerde diensten: bescherm piekverkeer zonder verborgen throttling.
Als je niet onmiddellijk kunt patchen, is een beheerde WAF een essentiële tijdelijke oplossing. Klanten van WP‑Firewall ontvangen snelle virtuele patching en voortdurende monitoring, zodat ze tijd kunnen kopen om officiële updates veilig te testen en te implementeren.
Bescherm uw site vandaag — begin met ons gratis plan
Beveilig je WordPress-site nu met een beschermingsniveau dat bij je behoeften past. Het Basis Gratis niveau van WP‑Firewall biedt je essentiële bescherming zonder kosten: een beheerde firewall, WAF-regels afgestemd op OWASP Top 10-risico's, een geautomatiseerde malware-scanner en onbeperkte bandbreedtebescherming om je site bereikbaar en veilig te houden.
Als je onmiddellijke virtuele patching en hands-on mitigatie wilt voor plugin-kwetsbaarheden zoals de Form Maker SQLi, meld je dan aan voor het gratis plan om onmiddellijk bescherming te starten. Verken het plan en registreer je hier:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Upgradepaden zijn beschikbaar als je automatische malwareverwijdering, IP-toegangs-/weigeringenlijsten, maandelijkse beveiligingsrapporten en automatische virtuele patching wilt — functies die zijn ontworpen om de responstijd en operationele belasting te verminderen, zodat je je kunt concentreren op de inhoud van je site.
Afsluitende gedachten en bronnen
De Form Maker SQL-injectie waarschuwing herinnert eraan dat zelfs plugins die onschadelijk lijken kritieke aanvalsvlakken kunnen blootstellen. De juiste mix van snelle patching, waakzaam toezicht en defensieve controles (inclusief virtuele patching met een WAF) is de beste manier om risico's te verminderen.
Praktische samenvatting:
- Update Form Maker onmiddellijk naar 1.15.38 of later.
- Als je niet kunt updaten, deactiveer dan de plugin en pas WAF-virtuele patches toe die SQL-stijl payloads voor de plugin-eindpunten blokkeren.
- Maak een back-up, inspecteer logs en volg de checklist voor incidentrespons als je een compromis vermoedt.
- Gebruik WAF's en beheerde diensten om jezelf ademruimte te geven terwijl je patcht en herstelt.
Als je hulp nodig hebt bij het implementeren van virtuele patches, het bouwen van detectieregels of het herstellen van een incident, biedt het beveiligingsteam van WP-Firewall zowel geautomatiseerde als beheerde diensten aan om je snel terug te brengen naar een veilige, schone site.
Blijf veilig, monitor nauwlettend en prioriteer updates — die combinatie houdt 99% van aanvallers buiten.
— WP‑Firewall Beveiligingsteam
Referenties en verder lezen
- CVE: CVE-2025-15441 (Form Maker < 1.15.38) — controleer de officiële plugin-release-opmerkingen voor details.
- OWASP Top 10: Injectierisico's en mitigaties.
- WordPress ontwikkelaarsdocumentatie:
$wpdb->prepare(), sanitization en escaping helpers.
