Plugin-navn	TilføjFunc Hoved- & Fodkode
Type af sårbarhed	Cross-Site Scripting (XSS)
CVE-nummer	CVE-2026-2305
Hastighed	Lav
CVE-udgivelsesdato	2026-04-10
Kilde-URL	CVE-2026-2305

AddFunc Head & Footer Code plugin XSS (CVE-2026-2305): Hvad WordPress-webstedsejere skal vide — og hvordan WP­Firewall beskytter dig

Dato: 10. april 2026
Alvorlighed (Patchstack-listing): Lav (CVSS 6.5)
Berørte versioner: <= 2.3
Patchet i: 2.4
Nødvendige rettigheder: Bidragyder (godkendt)

En nylig offentliggørelse (CVE-2026-2305) beskriver en autentificeret lagret cross-site scripting (XSS) sårbarhed i AddFunc Head & Footer Code-pluginet til WordPress (versioner op til 2.3). Denne sårbarhed tillader en bruger med Contributor-niveau adgang at injicere script-lignende payloads gennem brugerdefinerede felter, som senere kan blive gengivet usanitiseret — hvilket producerer lagret XSS på sider eller administrationsskærme, hvor disse felter vises.

Som teamet bag WP­Firewall (en WordPress sikkerheds- og administreret WAF-udbyder) ønsker jeg at give dig en læsbar, praktisk opdeling af risikoen, realistiske angrebsscenarier, detektion og oprydningstrin samt de lagdelte beskyttelser, du straks bør anvende. Jeg vil også forklare, hvordan vores firewall-funktioner beskytter dig (inklusive virtuel patching og WAF-signaturer) og give konkret, sikker kode- og konfigurationsvejledning til udviklere og webstedadministratorer.

Dette er skrevet fra perspektivet af en WordPress sikkerhedspraktiker — praktisk, uden nonsens, med reproducerbare trin, du kan bruge i dag.

---

Ledelsesresumé — hvad der skete, og hvorfor det er vigtigt

• Pluginet AddFunc Head & Footer Code (versioner <= 2.3) tillod brugerleveret indhold fra brugerdefinerede felter at blive inkluderet i output uden tilstrækkelig sanitering/escaping.
• En autentificeret bruger med Contributor-rettigheder (i stand til at tilføje eller redigere indlæg og brugerdefinerede felter) kunne gemme en payload, der indeholder script-tags eller begivenhedshåndterere.
• Når dette indhold senere gengives på front-end eller inden for en administrationsside uden korrekt escaping, udføres det gemte script i besøgendes eller administratorers browser.
• Indvirkningen afhænger af, hvor feltet gengives:
  • Hvis payloaden udføres i front-end (offentlige sider), kan webstedets besøgende blive påvirket (ondartede omdirigeringer, falske formularer, kryptovaluta-minere, indholdsindsprøjtning).
  • Hvis payloaden udføres inde i administrationssider (f.eks. når en redaktør eller administrator åbner indlægget i dashboardet), kan brugere med højere privilegier blive målrettet, hvilket fører til overtagelse af webstedet: kontoovertagelse, installation af plugins/temaer, ændringer af indstillinger eller installation af bagdøre.
• Pluginet blev patchet i version 2.4. Den umiddelbare korrekte handling for berørte websteder er at opdatere til 2.4 eller senere.

---

Hvorfor en Contributor kan være farlig — trusselmodel i den virkelige verden

Mange webstedsejere mener, at brugere på Contributor-niveau er lavrisiko, fordi de ikke kan offentliggøre indhold. Selvom det er en gyldig opfattelse for indholdsstyring, kan bidragydere stadig typisk oprette indlæg, redigere deres egne udkast og tilføje brugerdefinerede felter (afhængigt af webstedets konfiguration). Lagret XSS via brugerdefinerede felter er særligt farligt, fordi:

• Det ondsindede indhold er vedholdende - det er gemt i databasen og vil blive udløst, når det gengives.
• Hvis siden eller temaet udskriver brugerdefinerede felter på admin-sider (indlægforhåndsvisninger, meta-bokse) eller front-end sider uden at undslippe, udføres scripts med de privilegier, som den visende bruger har i deres browser.
• Angribere kan skabe payloads, der udfører handlinger på vegne af en administrator (ændre adgangskoder, oprette administrator-konti, installere plugins) ved at udnytte administratorens autentificerede session og forfalskede anmodninger (CSRF kombineret med XSS).

Kort sagt: bidrag fra brugere, du har stolet på for indhold, kan udnyttes til at pivotere ind i kompromittering af siden, hvis sanitering/undslipning mangler.

---

Typisk udnyttelsesflow (højt niveau, ikke-handlingsbar)

1. Angriberen registrerer eller bruger en konto med bidragsyderprivilegier (eller kompromitterer en).
2. Angriberen redigerer et udkast eller opretter et indlæg og tilføjer ondsindet indhold i et brugerdefineret felt (for eksempel, <script>…</script> eller attributbaserede payloads som onerror=… inden for et tilladt tag).
3. Siden gemmer det indhold i postmeta.
4. Når indlægget indlæses i en kontekst, hvor pluginet eller temaet udskriver det brugerdefinerede felt uden sanitering (front-end side, admin forhåndsvisning eller meta-boks), kører browseren den injicerede kode.
5. Hvis en administrator ser den berørte side eller indlæg i admin-grænsefladen (eller hvis besøgende er målrettet), kan det injicerede script:
   • Stjæle admin-cookies (hvis ikke HttpOnly - selvom moderne bedste praksis reducerer cookie-tyveri, men ikke alle sider følger det),
   • Bruge admin-privilegier til at oprette en ny admin-konto via REST API / admin-endepunkter,
   • Ændre plugin-/temafiler eller indstillinger,
   • Installere en bagdør eller vedholde yderligere malware,
   • Eksfiltrere data.

Fordi udnyttelse ofte kræver, at en administrator interagerer (ser indlægget i admin eller klikker på et specifikt forhåndsvisningslink), angiver Patchstack “Brugerinteraktion krævet”, men denne interaktion kan være så simpel som at åbne indlægsredigeringsværktøjet eller et udformet forhåndsvisningslink.

---

Praktiske skridt til at beskytte dit site — umiddelbare handlinger (tjekliste)

1. Opdater plugin'et
   – Hvis du kører AddFunc Head & Footer Code, opdater straks til version 2.4 eller senere. Dette er den kanoniske afhjælpning.
2. Hvis du ikke kan opdatere med det samme
   – Fjern eller deaktiver plugin'et midlertidigt.
   – Bloker bidragende konti fra at redigere eller tilføje brugerdefinerede felter, indtil plugin'et er opdateret.
   – Anvend virtuel patching på WAF-niveau (se WAF-vejledningen nedenfor).
3. Scan for ondsindet indhold i brugerdefinerede felter
   – Brug WP­CLI eller direkte DB-forespørgsler til at finde meta-værdier, der indeholder <script, en fejl=, javascript:, eller mistænkelig HTML.
       – Eksempel (tag sikkerhedskopi af din DB først):
          wp db query "SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script%';"
       – Søg også efter en fejl=, onload=, javascript: mønstre.
   – Gennemgå poster og fjern eller saniter mistænkelige meta-værdier.
4. Revider brugerkonti
   – Bekræft alle bidragydere og redaktører: er de legitime? Fjern forældede eller mistænkelige konti.
   – Hæv kravene til stærke adgangskoder og 2FA for privilegerede roller (Redaktør, Administrator).
5. Tjek for tegn på kompromittering.
   – Se efter ukendte admin-konti, uventede plugin-/tema-filer, nyligt ændrede filer, planlagte opgaver og udgående forbindelser fra serveren.
   – Kør en malware-scanning (WP­Firewall's scanner eller anden anerkendt scanner).
6. Rotér legitimationsoplysninger og API-nøgler, hvis der mistænkes kompromittering
   – Skift admin-adgangskoder og eventuelle eksponerede API-nøgler.
   – Ugyldiggør sessioner om nødvendigt (tving log ud for alle brugere).
7. Tag backup før oprydning
   – Tag en fuld sikkerhedskopi af sitet (filer og DB) før afhjælpning. Dette bevarer beviser og giver dig et rollback-punkt.
8. Hærd brugerdefinerede felter fremadrettet
   – Kræv sanitering ved gemning og escaping ved output — se kodeanbefalingerne nedenfor.

---

Hvordan man sikkert finder ondsindede gemte XSS-indgange

At søge efter mistænkeligt indhold i databasen er afgørende, men skal gøres forsigtigt:

• Opret altid en sikkerhedskopi, før du kører forespørgsler eller foretager ændringer.
• Start med kun læse-forespørgsler for at identificere mistænkelige indgange, og gennemgå dem derefter manuelt.
• Eksempel på WP­CLI detektionsforespørgsler:

# Find postmeta, der indeholder <script"

Eksporter mistænkelige meta-værdier og inspicer dem, og beslut derefter at rense eller fjerne.

---

Rensning af mistænkelige indgange

Hvis du identificerer ondsindede meta-værdier:

• Hvis indgangen åbenlyst er ondsindet (fulde . blokke), fjern meta-rækken.
• Hvis indgangen indeholder nyttige data, men også injicerede tags, skal du rense indholdet:

<?php

Hvis du ikke er komfortabel med manuelt at redigere databasen, så involver din udvikler eller vært.

---

Udviklervejledning: sikker håndtering af brugerdefinerede felter (rense ved gemning og output-escaping)

Sårbarheder som denne skyldes normalt manglende eller utilstrækkelig rensning ved input og manglende escaping ved output. Følg begge principper:

1. Rens ved gemning (så gemte data er sikre)
2. Escape ved output (stol aldrig på gemte data)

Anbefalede mønstre:

• Brug WordPress rensningsfunktioner, når du gemmer meta:

<?php

• Ved output, undgå altid baseret på kontekst:

<?php

• Bedre mønster: registrer meta med en sanitere callback (fungerer godt med REST):

<?php

• Tjek altid kapabilitet før du gemmer eller gengiver admin-only meta. Brug nonces til admin formularer.

---

WAF og virtuel patching — øjeblikkelig netværksbeskyttelse

Når der findes en plugin-sårbarhed, og opdatering straks ikke er muligt, giver en velkonfigureret Web Application Firewall (WAF) virtuel patching. Virtuel patching betyder at opsnappe ondsindede anmodninger og blokere dem, før de når den sårbare kodevej.

Typiske WAF-afbødninger for denne type lagret XSS inkluderer:

• Blokering af POST-anmodninger, der inkluderer mistænkelige script payloads i kendte meta felt navne (f.eks. postmeta indhold, _tilpasset_*).
• Blokering eller rensning af anmodninger, der indeholder . tags, event handler attributter (en fejl=, onload=), javascript: URIs, base64-kodet script indhold, eller åbenlyse obfuskationsmønstre.
• Rate-limiting POSTs, der opretter eller opdaterer indlæg fra lavprivilegerede brugere.
• Blokering af kendte exploit signaturer og payload kodninger.

Eksempel pseudo-regel (for en generisk WAF motor) — kun konceptuel:

Pseudokode WAF regel: blokér script tags i postmeta felter'

Hvis du kører en host-baseret WAF eller cloud WAF, konfigurer en regel, der inspicerer anmodningskroppen for disse mønstre og blokerer dem for brugere med Contributor/Author privilegier. Det giver en øjeblikkelig afbødning, mens du opdaterer.

Hos WP­Firewall tilbyder vi målrettede virtuelle patching regler, der opdager og blokerer mønstre brugt i lagrede XSS forsøg, kombineret med overvågning og notifikation, når et blokeret forsøg fandt sted.

---

WAF regel eksempler — ModSecurity-stil (eksempel, tilpas til dit miljø)

Nedenfor er eksempel mønstre, der kan bruges som udgangspunkt. Disse er illustrative — test omhyggeligt for at undgå falske positiver:

# Eksempel ModSecurity regel til at opdage  tags i POST-krop"

# Eksempel regel til at opdage begivenhedsegenskaber som onerror= eller onload="

Vigtigt: test altid regler på et staging-miljø for at identificere legitime kanttilfælde (nogle legitime indhold kan inkludere tilladt HTML) og tilpas reglerne derefter.

---

Detektion — logs og indikatorer for udnyttelse

Hvis du mistænker, at udnyttelse er sket:

• Tjek serverens adgangslogs for POSTs, der opretter eller ændrer indlæg (POSTs til /wp-admin/post.php, /wp-json/wp/v2/posts).
• Tjek applikationslogs (hvis du har dem) for mistænkelige POST-parametre.
• Se efter advarsler fra din malware-scanner, der viser ændrede plugin-/tema-filer, ukendte filer eller webshells.
• Tjek listen over admin-brugere for nyoprettede administrator-konti.
• Se efter udgående forbindelser fra din server til ukendte værter.
• Gennemgå nylige cron-jobs og planlagte opgaver for ukendte PHP-udførelser.

Hvis du finder injiceret indhold i postmeta, behandl det som potentiel kompromittering: udfør en fuld hændelsesrespons (karantæne, retsmedicinsk snapshot, gendan fra ren backup hvis nødvendigt).

---

Efter en infektion — afhjælpning og hårdføring

Hvis du finder beviser for, at siden var kompromitteret:

1. Isolere tag siden (tag den offline eller blokér indgående adgang) mens du undersøger.
2. Bevar beviser: tag et fuldt snapshot, bevar logs (webserver, database).
3. Identificer vedholdenhedsmekanismer: tjek for tilføjede admin-brugere, ændret wp-config.php, udskiftede kernefiler, ondsindede plugins/temaer, cron-opgaver, planlagte begivenheder.
4. Rens: fjern ondsindede filer og databaseposter. Hvis du er usikker, gendan fra en ren sikkerhedskopi.
5. Skift legitimationsoplysninger: nulstil alle adgangskoder, tilbagekald API-nøgler, roter SSH-nøgler.
6. Patch: opdater WordPress-kerne, plugins og temaer til de nyeste versioner.
7. Hærd: begræns filrettigheder, deaktiver filredigering via wp-config.php (define('DISALLOW_FILE_EDIT', sand)), håndhæve 2FA for alle administratorer, gennemgå mindst privilegium for alle konti.
8. Overvåge: aktiver sikkerhedsovervågning, filintegritetsovervågning og alarmering for kritiske begivenheder.

---

Langsigtede kontroller — reducer risikoen fra rollemisbrug og ikke-pålidelig HTML

• Minimér antallet af konti, der kan redigere indhold; anvend mindst privilegium.
• Kræv godkendelsesarbejdsgange for brugerindsendt indhold, hvor det er muligt (gennemgå før offentliggørelse).
• Begræns hvilke roller der kan tilføje brugerdefinerede felter eller bruge plugins, der eksponerer rendering af brugerdefinerede felter.
• Uddan bidragsydere om risiciene ved at indlejre HTML i felter.
• Brug Content Security Policy (CSP) headers til at begrænse virkningen af injicerede scripts (dette kan reducere rækkevidden af nogle XSS-angreb).
• For websteder med mange bidragsydere, aktiver stærkere rolleadskillelse og overvej moderationsflow-plugins.

---

Hvordan betroet WAF + administreret sikkerhed reducerer tid til afhjælpning

En administreret WAF og sikkerhedstjeneste tilbyder:

• Hurtig virtuel patching: blokér udnyttelsesforsøg straks uden at skulle ændre applikationskode.
• Signaturopdateringer, efterhånden som forskning offentliggøres, så regler fanger nye payloads.
• Malware-scannings- og fjernelsesværktøjer til at finde og afhjælpe injiceret indhold.
• Overvågning og alarmering, så du ikke behøver at overvåge logs 24/7.
• Vejledning under hændelsesrespons og rollback-assistance når det er nødvendigt.

WP­Firewall kombinerer disse funktioner med specialiseret logik til WordPress (anmodningsmønstre, REST-endepunkter, admin-endepunkter), så vi kan opdage og afbøde angreb, der retter sig mod almindelige WordPress-vektorer som gemt XSS i meta.

---

Praktiske WAF-justeringsnoter (reducer falske positiver)

• At udelukke betroede administrator-IP'er fra aggressiv blokering kan forhindre afbrydelser i admin-arbejdsgange — men balancer det med sikkerhedsrisiko.
• Brug regler, der matcher parameternavne, der almindeligvis bruges til meta-felter (meta[], postmeta, acf, brugerdefinerede felter) i stedet for at blokere alle . tags globalt.
• Log mistænkelige, men ikke klart ondsindede anmodninger (kun alarmtilstand) i en periode før blokering — dette hjælper med at justere signaturer til dit sites brugs mønstre.

---

Eksempel på hændelsesrespons playbook (kortfattet)

1. Opdater plugin til 2.4 (hvis muligt).
2. Hvis øjeblikkelig opdatering er umulig: aktiver virtuelle patch-regel(r), der inspicerer POST-kroppe for scripts og begivenhedsegenskaber, der retter sig mod postmeta-parametre.
3. Kør DB-forespørgsel for at finde mistænkelige meta-værdier; eksporter resultater til gennemgang.
4. Fjern bekræftede ondsindede poster og saniter tvetydige.
5. Nulstil adgangskoder for alle administratorer; håndhæv 2FA.
6. Scann filsystemet for ændrede filer og ukendte PHP-filer.
7. Gendan fra ren backup, hvis afhjælpning er usikker.
8. Overvåg logs for gentagne forsøg; blokér krænkende IP'er.

---

Udviklervenlige anbefalinger til at eliminere denne klasse af fejl

• Sanitér altid ved gemning og undgå ved output.
• Brug WordPress-API'er: register_post_meta med sanitære callbacks, sanitize_text_field, wp_kses_post, esc_html, esc_attr.
• Brug nonces og kapabilitetskontroller for enhver admin-side gemmeoperationer.
• Undgå at gemme rå HTML, medmindre det er absolut nødvendigt; hvis du gør det, begræns tilladte tags og attributter med wp_kses.
• Gør sikkerhed til en del af CI/CD-pipelinen: statisk analyse, afhængighedstjek og sikkerhedsanmeldelser før plugin-/temaudgivelser.

---

Hvordan man verificerer, at din side ikke længere er sårbar

1. Sørg for, at AddFunc Head & Footer Code er opdateret til 2.4 eller senere.
2. Bekræft, at der ikke er postmeta-indgange med . eller begivenhedsegenskaber, der kan udføres.
3. Bekræft, at sidens front-end og admin-sider undgår output fra brugerdefinerede felter.
4. Tjek dine WAF-logs for blokerede forsøg, og sørg for, at du har logging/advarsler aktiveret.
5. Udfør en fuld malware-scanning og verificer filintegritet.

---

Start med gratis beskyttelse fra WP­Firewall

At beskytte din WordPress-side bør ikke være kompliceret. Hvis du ønsker øjeblikkelig grundlæggende beskyttelse, mens du gennemgår plugin-opdateringer og rydder op i mistænkeligt indhold, overvej at tilmelde dig WP­Firewall's gratis Basic-plan. Den gratis plan inkluderer en aktivt administreret firewall, ubegribelig båndbredde, en WAF, en malware-scanner og dækningsforanstaltninger for OWASP Top 10-risici — nok til at blokere mange almindelige udnyttelsesforsøg og give dit team plads til sikkert at anvende rettelser. Prøv WP­Firewall Basic gratis her: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Hvis du ønsker automatisk malwarefjernelse og mere avanceret kontrol som IP-blacklister, tilføjer vores betalte planer disse funktioner til en beskeden årlig omkostning.)

---

Endelige anbefalinger — prioriteret handlingsliste (kort)

1. Opdater AddFunc Head & Footer Code til 2.4+ nu.
2. Hvis du ikke kan opdatere med det samme, skal du blokere eller deaktivere plugin'et og anvende WAF virtuelle patch-regler.
3. Scann og fjern ondsindede brugerdefinerede feltindgange.
4. Gennemgå brugere og håndhæve adgangskode/2FA for privilegerede konti.
5. Hærd gemme-tid sanitization og output-tid escaping for brugerdefinerede felter.
6. Brug WP­Firewall eller en administreret WAF for at få øjeblikkelig beskyttelse og overvågning.

---

Afsluttende tanker

Denne sårbarhed er en påmindelse om, at selv tilsyneladende lavprivilegerede roller og små plugins kan udgøre en uforholdsmæssig risiko, hvis data gemmes og senere gengives uden korrekt sanitization og escaping. WordPress er fleksibel, hvilket er dens største styrke — og også dens mest hyppige kilde til risiko, når kode antager tillid, hvor den ikke hører hjemme.

Anvend opdateringen, scann for og fjern mistænkelige meta-værdier, og sæt en WAF foran din side — ikke som en permanent erstatning for sikker kode, men som en væsentlig kompenserende kontrol, der giver dig tid, mens du løser roden til problemet. Hvis du ønsker hjælp til at implementere WAF-regler, virtuel patching eller en oprydning efter hændelsen, specialiserer WP­Firewall's team sig i hurtig, WordPress-bevidst afbødning.

Hvis du ønsker en trin-for-trin revision eller assistance, så kontakt din sikkerhedsudbyder eller benyt WP­Firewall's gratis plan for at få øjeblikkelig grundlæggende beskyttelse, mens du udbedrer.

Hold dig sikker, og betragt brugerdefinerede felter som ikke-pålidelige input — sanitér, undslip og gennemgå.

— WP­Firewall Sikkerhedsteam