| Pluginnaam | AddFunc Hoofd- en Voettekstcode |
|---|---|
| Type kwetsbaarheid | Cross-site scripting (XSS) |
| CVE-nummer | CVE-2026-2305 |
| Urgentie | Laag |
| CVE-publicatiedatum | 2026-04-10 |
| Bron-URL | CVE-2026-2305 |
AddFunc Hoofd- en Voettekstcode plugin XSS (CVE-2026-2305): Wat WordPress-site-eigenaren moeten weten — en hoe WPFirewall je beschermt
Datum: 10 april 2026
Ernst (Patchstack-lijst): Laag (CVSS 6.5)
Aangetaste versies: <= 2.3
Gepatcht in: 2.4
Vereiste bevoegdheid: Contributor (geauthenticeerd)
Een recente openbaarmaking (CVE-2026-2305) beschrijft een geauthenticeerde opgeslagen cross-site scripting (XSS) kwetsbaarheid in de AddFunc Hoofd- en Voettekstcode plugin voor WordPress (versies tot en met 2.3). Deze kwetsbaarheid stelt een gebruiker met Contributor-toegang in staat om scriptachtige payloads in te voegen via aangepaste velden die later mogelijk niet goed worden gesaneerd — wat opgeslagen XSS op pagina's of beheerschermen produceert waar die velden worden weergegeven.
Als het team achter WPFirewall (een WordPress-beveiligings- en beheerde WAF-provider) wil ik je een leesbare, praktische uiteenzetting geven van het risico, realistische aanvalscenario's, detectie- en opruimstappen, en de gelaagde bescherming die je onmiddellijk moet toepassen. Ik zal ook uitleggen hoe onze firewallcapaciteiten je beschermen (inclusief virtuele patching en WAF-handtekeningen), en concrete, veilige code- en configuratierichtlijnen bieden voor ontwikkelaars en sitebeheerders.
Dit is geschreven vanuit het perspectief van een WordPress-beveiligingspraktijk — praktisch, zonder poespas, met reproduceerbare stappen die je vandaag kunt gebruiken.
Samenvatting voor het management — wat er is gebeurd en waarom het belangrijk is
- De plugin AddFunc Hoofd- en Voettekstcode (versies <= 2.3) stond gebruikersinhoud van aangepaste velden in berichten toe om in de uitvoer te worden opgenomen zonder voldoende sanering/escaping.
- Een geauthenticeerde gebruiker met Contributor-rechten (in staat om berichten en aangepaste velden toe te voegen of te bewerken) kon een payload opslaan die script-tags of gebeurtenishandlers bevat.
- Wanneer die inhoud later op de front-end of binnen een beheerderspagina wordt weergegeven zonder juiste escaping, wordt het opgeslagen script uitgevoerd in de browser van de bezoeker of beheerder.
- De impact hangt af van waar het veld wordt weergegeven:
- Als de payload op de front-end (publieke pagina's) wordt uitgevoerd, kunnen sitebezoekers worden getroffen (kwaadaardige omleidingen, nepformulieren, cryptomining, inhoudsinjectie).
- Als de payload binnen beheerderspagina's wordt uitgevoerd (bijv. wanneer een redacteur of beheerder het bericht in het dashboard opent), kunnen gebruikers met hogere privileges worden doelwit, wat kan leiden tot overname van de site: accountovername, installatie van plugins/thema's, wijziging van instellingen of het installeren van achterdeurtjes.
- De plugin is gepatcht in versie 2.4. De onmiddellijke juiste actie voor aangetaste sites is om te updaten naar 2.4 of later.
Waarom een Contributor gevaarlijk kan zijn — dreigingsmodel in de echte wereld
Veel site-eigenaren denken dat gebruikers op Contributor-niveau laag risico lopen omdat ze geen inhoud kunnen publiceren. Hoewel dat een geldige opvatting is voor contentbeheer, kunnen bijdragers doorgaans nog steeds berichten aanmaken, hun eigen concepten bewerken en aangepaste velden toevoegen (afhankelijk van de siteconfiguratie). Opgeslagen XSS via aangepaste velden is bijzonder gevaarlijk omdat:
- De kwaadaardige inhoud is persistent - het wordt opgeslagen in de database en zal worden geactiveerd wanneer het wordt weergegeven.
- Als de site of het thema aangepaste velden afdrukt in beheerderspagina's (berichtvoorbeelden, metaboxen) of front-end pagina's zonder te ontsnappen, worden scripts uitgevoerd met de privileges van de kijkende gebruiker in hun browser.
- Aanvallers kunnen payloads maken die acties uitvoeren namens een beheerder (wachtwoorden wijzigen, beheerdersaccounts aanmaken, plugins installeren) door gebruik te maken van de geauthenticeerde sessie van de beheerder en vervalste verzoeken (CSRF gecombineerd met XSS).
Kortom: bijdragen van gebruikers die je vertrouwde voor inhoud kunnen worden gebruikt om de site te compromitteren als sanitization/escaping ontbreekt.
Typische exploitatieflow (hoog niveau, niet-acties)
- De aanvaller registreert of gebruikt een account met bijdragerprivileges (of compromitteert er een).
- De aanvaller bewerkt een concept of maakt een bericht aan en voegt kwaadaardige inhoud toe in een aangepast veld (bijvoorbeeld,
<script>…</script>of op attribuut gebaseerde payloads zoalsonerror=…binnen een toegestaan tag). - De site slaat die inhoud op in postmeta.
- Wanneer het bericht wordt geladen in een context waarin de plugin of het thema dat aangepaste veld niet-sanitized uitvoert (front-end pagina, admin voorbeeld, of metabox), voert de browser de geïnjecteerde code uit.
- Als een beheerder de aangetaste pagina of het bericht bekijkt in de admininterface (of als bezoekers worden gericht), kan het geïnjecteerde script:
- Beheerdercookies stelen (als ze niet HttpOnly zijn - hoewel moderne best practices de diefstal van cookies verminderen, maar niet alle sites volgen dit),
- Beheerderprivileges gebruiken om een nieuw beheerdersaccount aan te maken via REST API / admin-eindpunten,
- Plugin/thema-bestanden of instellingen wijzigen,
- Een backdoor installeren of verdere malware persistent maken,
- Gegevens exfiltreren.
Omdat exploitatie vaak vereist dat een beheerder interactie heeft (het bericht in admin bekijkt of op een specifieke voorbeeldlink klikt), vermeldt Patchstack “Gebruikersinteractie Vereist”, maar deze interactie kan zo eenvoudig zijn als het openen van de berichteditor of een gemaakte voorbeeldlink.
Praktische stappen om uw site te beschermen — onmiddellijke acties (checklist)
- De plug-in bijwerken
– Als u AddFunc Head & Footer Code gebruikt, werk dan onmiddellijk bij naar versie 2.4 of later. Dit is de canonieke oplossing. - Als u niet onmiddellijk kunt updaten
– Verwijder of deactiveer de plugin tijdelijk.
– Blokkeer bijdragersaccounts om aangepaste velden te bewerken of toe te voegen totdat de plugin is bijgewerkt.
– Pas virtuele patching toe op het WAF-niveau (zie WAF-richtlijnen hieronder). - Scan op kwaadaardige inhoud in aangepaste velden
– Gebruik WPCLI of directe DB-query's om meta-waarden te vinden die bevatten<script,onerror=,javascript:, of verdachte HTML.
– Voorbeeld (maak eerst een back-up van uw DB):
wp db query "SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script%';"
– Zoek ook naaronerror=,onload=,javascript:patronen.
– Beoordeel invoer en verwijder of saniteer verdachte meta-waarden. - Controleer gebruikersaccounts
– Verifieer alle bijdragers en redacteuren: zijn ze legitiem? Verwijder verouderde of verdachte accounts.
– Handhaaf sterke wachtwoorden en 2FA voor bevoorrechte rollen (Redacteur, Beheerder). - Controleer op tekenen van compromittering
– Zoek naar onbekende admin-accounts, onverwachte plugin/thema-bestanden, recent gewijzigde bestanden, geplande taken en uitgaande verbindingen vanaf de server.
– Voer een malware-scan uit (WPFirewall's scanner of een andere gerenommeerde scanner). - Draai inloggegevens en API-sleutels als er een compromis wordt vermoed
– Wijzig admin-wachtwoorden en alle blootgestelde API-sleutels.
– Ongeldig sessies indien nodig (dwing uitloggen af voor alle gebruikers). - Maak een back-up voordat u opruimt
– Maak een volledige site-back-up (bestanden en DB) vóór de oplossing. Dit behoudt bewijs en geeft u een terugrolpunt. - Versterk aangepaste velden voortaan
– Vereis sanering bij opslaan en ontsnapping bij uitvoer — zie de code-aanbevelingen hieronder.
Hoe je kwaadaardige opgeslagen XSS-invoeren veilig kunt vinden
Het zoeken naar verdachte inhoud in de database is cruciaal, maar moet voorzichtig gebeuren:
- Maak altijd een back-up voordat je queries uitvoert of wijzigingen aanbrengt.
- Begin met alleen-lezen queries om verdachte invoeren te identificeren, en bekijk ze vervolgens handmatig.
- Voorbeeld WPCLI detectiequeries:
# Zoek postmeta die <script bevat"
Exporteer verdachte meta-waarden en inspecteer ze, beslis dan om te saniteren of te verwijderen.
Het schoonmaken van verdachte invoeren
Als je kwaadaardige meta-waarden identificeert:
- Als de invoer duidelijk kwaadaardig is (volledige
<script>blokken), verwijder dan de meta-rij. - Als de invoer nuttige gegevens bevat maar ook geïnjecteerde tags, saniteer dan de inhoud:
<?php
Als je je niet comfortabel voelt bij het handmatig bewerken van de DB, schakel dan je ontwikkelaar of host in.
Ontwikkelaarsrichtlijnen: veilige omgang met aangepaste velden (sanitization bij opslaan en escaping bij uitvoer)
Kwetsbaarheden zoals deze worden meestal veroorzaakt door ontbrekende of inadequate sanitization bij invoer, en ontbrekende escaping bij uitvoer. Volg beide principes:
- Sanitize bij opslaan (zodat opgeslagen gegevens veilig zijn)
- Escape bij uitvoer (vertrouw nooit op opgeslagen gegevens)
Aanbevolen patronen:
- Gebruik WordPress sanitization-functies bij het opslaan van meta:
<?php
- Bij uitvoer altijd escapen op basis van context:
<?php
- Beter patroon: registreer meta met een sanitize callback (werkt goed met REST):
<?php
- Controleer altijd de capaciteit voordat je admin-only meta opslaat of weergeeft. Gebruik nonces voor admin-formulieren.
WAF en virtuele patching — onmiddellijke bescherming op netwerkniveau
Wanneer er een kwetsbaarheid in een plugin bestaat en onmiddellijk updaten niet mogelijk is, biedt een goed geconfigureerde Web Application Firewall (WAF) virtuele patching. Virtuele patching betekent het onderscheppen van kwaadaardige verzoeken en deze blokkeren voordat ze de kwetsbare codepad bereiken.
Typische WAF-mitigaties voor dit type opgeslagen XSS omvatten:
- Blokkeren van POST-verzoeken die verdachte scriptpayloads bevatten in bekende meta-veldnamen (bijv. postmeta-inhoud,
_aangepast_*). - Blokkeren of sanitizen van verzoeken die bevatten
<script>tags, gebeurtenis-handler-attributen (onerror=,onload=),javascript:URI's, base64-gecodeerde scriptinhoud, of voor de hand liggende obfuscatiepaterns. - Rate-limiting van POST's die berichten creëren of bijwerken van gebruikers met lage privileges.
- Blokkeren van bekende exploit-handtekeningen en payload-coderingen.
Voorbeeld pseudo-regel (voor een generieke WAF-engine) — alleen conceptueel:
# Pseudocode WAF-regel: blokkeer script-tags in postmeta-velden'
Als je een host-gebaseerde WAF of cloud WAF draait, configureer dan een regel die de verzoekinhoud inspecteert op deze patronen en deze blokkeert voor gebruikers met Contributor/Author-rechten. Dat biedt een onmiddellijke mitigatie terwijl je update.
Bij WPFirewall bieden we gerichte virtuele patching-regels die patronen detecteren en blokkeren die worden gebruikt in pogingen tot opgeslagen XSS, gecombineerd met monitoring en notificatie wanneer een geblokkeerde poging heeft plaatsgevonden.
WAF regelvoorbeelden — ModSecurity-stijl (voorbeeld, pas aan voor jouw omgeving)
Hieronder staan voorbeeldpatronen die als uitgangspunt kunnen dienen. Deze zijn illustratief — test zorgvuldig om valse positieven te vermijden:
# Voorbeeld ModSecurity-regel om tags in POST-lichaam te detecteren"
# Voorbeeldregel om gebeurtenisattributen zoals onerror= of onload= te detecteren"
Belangrijk: test altijd regels in een staging-omgeving om legitieme randgevallen te identificeren (sommige legitieme inhoud kan toegestane HTML bevatten) en pas de regels dienovereenkomstig aan.
Detectie — logs en indicatoren van exploitatie
Als je vermoedt dat er exploitatie heeft plaatsgevonden:
- Controleer servertoeganglogs op POST's die berichten aanmaken of wijzigen (POST's naar /wp-admin/post.php, /wp-json/wp/v2/posts).
- Controleer applicatielogs (als je die hebt) op verdachte POST-parameters.
- Zoek naar waarschuwingen van je malware-scanner die gewijzigde plugin/thema-bestanden, onbekende bestanden of webshells tonen.
- Controleer de lijst met beheerdersgebruikers op nieuw aangemaakte administratoraccounts.
- Zoek naar uitgaande verbindingen van je server naar onbekende hosts.
- Bekijk recente cron-taken en geplande taken op onbekende PHP-uitvoeringen.
Als je geïnjecteerde inhoud in postmeta vindt, beschouw het dan als een potentiële compromittering: voer een volledige incidentrespons uit (quarantaine, forensische snapshot, herstel vanaf een schone back-up indien nodig).
Na een infectie — herstel en verharding
Als je bewijs vindt dat de site is gecompromitteerd:
- Isoleren neem de site offline (maak het offline of blokkeer inkomende toegang) terwijl je onderzoekt.
- Bewijsmateriaal bewaren: maak een volledige snapshot, bewaar logs (webserver, database).
- Identificeer persistentiemechanismen: controleer op toegevoegde beheerdersgebruikers, gewijzigde wp-config.php, vervangen kernbestanden, kwaadaardige plugins/thema's, cron-taken, geplande evenementen.
- Schoonmaken: verwijder kwaadaardige bestanden en database-invoer. Als je het niet zeker weet, herstel dan vanaf een schone back-up.
- Wijzig inloggegevens: reset alle wachtwoorden, intrek API-sleutels, roteer SSH-sleutels.
- Patch: update de WordPress-kern, plugins en thema's naar de nieuwste versies.
- Versterken: beperk bestandsmachtigingen, schakel bestandsbewerking via wp-config.php uit (
define('DISALLOW_FILE_EDIT', true)), handhaaf 2FA voor alle beheerders, herzie de minste privileges voor alle accounts. - Monitoren: schakel beveiligingsmonitoring, bestandsintegriteitsmonitoring en waarschuwingen voor kritieke gebeurtenissen in.
Langdurige controles — verminder risico's van rolmisbruik en onbetrouwbaar HTML
- Minimaliseer het aantal accounts dat inhoud kan bewerken; pas de minste privileges toe.
- Vereis goedkeuringsworkflows voor door gebruikers ingediende inhoud waar mogelijk (beoordeling vóór publicatie).
- Beperk welke rollen aangepaste velden kunnen toevoegen of plugins kunnen gebruiken die de weergave van aangepaste velden blootstellen.
- Educateer bijdragers over de risico's van het insluiten van HTML in velden.
- Gebruik Content Security Policy (CSP) headers om de impact van geïnjecteerde scripts te beperken (dit kan de reikwijdte van sommige XSS-aanvallen verminderen).
- Voor sites met veel bijdragers, schakel sterkere rol scheiding in en overweeg moderatieflow-plugins.
Hoe vertrouwde WAF + beheerde beveiliging de tijd tot herstel vermindert
Een beheerde WAF en beveiligingsdienst biedt:
- Snelle virtuele patching: blokkeer exploitpogingen onmiddellijk zonder de applicatiecode te hoeven wijzigen.
- Handtekeningupdates zodra onderzoek wordt gepubliceerd, zodat regels opkomende payloads opvangen.
- Malware-scanning en verwijderingstools om geïnjecteerde inhoud te vinden en te verhelpen.
- Monitoring en waarschuwingen zodat je niet 24/7 naar logs hoeft te kijken.
- Begeleiding tijdens incidentrespons en rollback-assistentie wanneer nodig.
WPFirewall combineert deze mogelijkheden met gespecialiseerde logica voor WordPress (verzoekpatronen, REST-eindpunten, admin-eindpunten) zodat we aanvallen kunnen detecteren en mitigeren die gericht zijn op veelvoorkomende WordPress-vectoren zoals opgeslagen XSS in meta.
Praktische WAF-tuningnotities (verminder valse positieven)
- Het uitsluiten van vertrouwde administrator-IP's van agressieve blokkering kan onderbrekingen in de admin-werkstroom voorkomen — maar balanceer dat met het beveiligingsrisico.
- Gebruik regels die overeenkomen met parameter namen die vaak worden gebruikt voor meta-velden (meta[], postmeta, acf, aangepaste velden) in plaats van alles globaal te blokkeren.
<script>tags wereldwijd. - Log verdachte maar niet duidelijk kwaadaardige verzoeken (alleen waarschuwing modus) voor een periode voordat je blokkeert — dit helpt om handtekeningen af te stemmen op de gebruikspatronen van je site.
Voorbeeld incidentrespons-handboek (bondig)
- Update de plugin naar 2.4 (indien mogelijk).
- Als onmiddellijke update onmogelijk is: schakel virtuele patchregel(en) in die POST-lichaams inspecteren op scripts en gebeurtenisattributen die gericht zijn op postmeta-parameters.
- Voer een DB-query uit om verdachte meta-waarden te vinden; exporteer resultaten voor beoordeling.
- Verwijder bevestigde kwaadaardige vermeldingen en saniteer onduidelijke.
- Reset wachtwoorden voor alle admins; handhaaf 2FA.
- Scan het bestandssysteem op gewijzigde bestanden en onbekende PHP-bestanden.
- Herstel vanaf een schone back-up als herstel onzeker is.
- Monitor logs op herhaalde pogingen; blokkeer de betreffende IP's.
Ontwikkelaar-vriendelijke aanbevelingen om deze klasse van bugs te elimineren.
- Saniteer altijd bij opslaan en escape bij uitvoer.
- Gebruik WordPress-API's: register_post_meta met saniteer callbacks, sanitize_text_field, wp_kses_post, esc_html, esc_attr.
- Gebruik nonces en capaciteitscontroles voor alle admin-zijde opslaan operaties.
- Vermijd het opslaan van ruwe HTML tenzij absoluut noodzakelijk; als je dat doet, beperk dan toegestane tags en attributen met wp_kses.
- Maak beveiliging onderdeel van de CI/CD-pijplijn: statische analyse, afhankelijkheidscontroles en beveiligingsreviews vóór de release van plugins/thema's.
Hoe te verifiëren dat uw site niet langer kwetsbaar is
- Zorg ervoor dat de AddFunc Head & Footer Code is bijgewerkt naar 2.4 of later.
- Controleer of er geen postmeta-invoeren zijn met
<script>of gebeurtenisattributen die kunnen worden uitgevoerd. - Bevestig dat de front-end en admin pagina's van de site de uitvoer van aangepaste velden ontsnappen.
- Controleer uw WAF-logboeken op geblokkeerde pogingen en zorg ervoor dat u logging/waarschuwingen hebt ingeschakeld.
- Voer een volledige malware-scan uit en verifieer de bestandsintegriteit.
Begin met Gratis Bescherming van WPFirewall
Het beschermen van uw WordPress-site zou niet ingewikkeld moeten zijn. Als u onmiddellijke basisbescherming wilt terwijl u plugin-updates bekijkt en verdachte inhoud opruimt, overweeg dan om u aan te melden voor het gratis Basisplan van WPFirewall. Het gratis plan omvat een actief beheerde firewall, onbeperkte bandbreedte, een WAF, een malware-scanner en mitigatie-dekking voor OWASP Top 10-risico's — genoeg om veel voorkomende exploitpogingen te blokkeren en uw team de ruimte te geven om veilig oplossingen toe te passen. Probeer WPFirewall Basic hier gratis: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Als u automatische malwareverwijdering en meer geavanceerde controle zoals IP-zwarte lijsten wilt, voegen onze betaalde plannen deze functies toe tegen een bescheiden jaarlijkse kosten.)
Laatste aanbevelingen — prioriteitsactielijst (kort)
- Werk de AddFunc Head & Footer Code nu bij naar 2.4+.
- Als u niet onmiddellijk kunt bijwerken, blokkeer of deactiveer de plugin en pas WAF virtuele patchregels toe.
- Scan en verwijder kwaadaardige invoeren van aangepaste velden.
- Controleer gebruikers en handhaaf wachtwoord/2FA voor bevoorrechte accounts.
- Versterk de sanitatie tijdens het opslaan en de ontsnapping tijdens het uitvoeren voor aangepaste velden.
- Gebruik WPFirewall of een beheerde WAF om onmiddellijke bescherming en monitoring te krijgen.
Slotgedachten
Deze kwetsbaarheid herinnert eraan dat zelfs schijnbaar laagprivilege rollen en kleine plugins een buitensporig risico kunnen vormen als gegevens worden opgeslagen en later worden weergegeven zonder de juiste sanitatie en ontsnapping. WordPress is flexibel, wat zijn grootste kracht is — en ook zijn meest frequente bron van risico wanneer code vertrouwen aanneemt waar het niet thuishoort.
Pas de update toe, scan naar en verwijder verdachte meta-waarden, en zet een WAF voor uw site — niet als een permanente vervanging voor veilige code, maar als een essentiële compenserende controle die u tijd geeft terwijl u de oorzaak aanpakt. Als u hulp wilt bij het implementeren van WAF-regels, virtuele patching of een opruiming na een incident, is het team van WPFirewall gespecialiseerd in snelle, WordPress-bewuste mitigatie.
Als je een stapsgewijze audit of hulp wilt, neem dan contact op met je beveiligingsprovider of maak gebruik van het gratis plan van WPFirewall om onmiddellijke basisbescherming te krijgen terwijl je herstelt.
Blijf veilig en behandel aangepaste velden als onbetrouwbare invoer — saniteer, ontsnap en controleer.
— WP-Firewall Beveiligingsteam
