Nome del plugin	Aggiungi codice intestazione e piè di pagina AddFunc
Tipo di vulnerabilità	Script tra siti (XSS)
Numero CVE	CVE-2026-2305
Urgenza	Basso
Data di pubblicazione CVE	2026-04-10
URL di origine	CVE-2026-2305

Plugin AddFunc Head & Footer Code XSS (CVE-2026-2305): Cosa devono sapere i proprietari di siti WordPress — e come WP­Firewall ti protegge

Data: 10 aprile 2026
Gravità (elenco Patchstack): Bassa (CVSS 6.5)
Versioni interessate: <= 2.3
Corretto in: 2.4
Privilegio richiesto: Collaboratore (autenticato)

Una recente divulgazione (CVE-2026-2305) descrive una vulnerabilità di cross-site scripting (XSS) autenticata e memorizzata nel plugin AddFunc Head & Footer Code per WordPress (versioni fino a 2.3). Questa vulnerabilità consente a un utente con accesso di livello Contributor di iniettare payload simili a script attraverso campi personalizzati che possono successivamente essere visualizzati non sanitizzati — producendo XSS memorizzato su pagine o schermate di amministrazione dove quei campi vengono visualizzati.

Come team dietro WP­Firewall (un fornitore di sicurezza WordPress e WAF gestito), voglio darti una panoramica leggibile e pratica del rischio, scenari di attacco realistici, passaggi per la rilevazione e la pulizia, e le protezioni stratificate che dovresti applicare immediatamente. Spiegherò anche come le nostre capacità di firewall ti proteggono (inclusi patch virtuali e firme WAF), e fornirò indicazioni concrete e sicure su codice e configurazione per sviluppatori e amministratori di siti.

Questo è scritto dalla prospettiva di un professionista della sicurezza WordPress — pratico, senza fronzoli, con passaggi riproducibili che puoi utilizzare oggi.

---

Sommario esecutivo — cosa è successo e perché è importante

• Il plugin AddFunc Head & Footer Code (versioni <= 2.3) consentiva ai contenuti forniti dagli utenti nei campi personalizzati dei post di essere inclusi nell'output senza una sufficiente sanitizzazione/escaping.
• Un utente autenticato con privilegi di Contributor (in grado di aggiungere o modificare post e campi personalizzati) potrebbe salvare un payload che contiene tag script o gestori di eventi.
• Quando quel contenuto viene successivamente visualizzato sul front-end o all'interno di una pagina di amministrazione senza un'adeguata escaping, lo script memorizzato viene eseguito nel browser del visitatore o dell'amministratore.
• L'impatto dipende da dove viene visualizzato il campo:
  • Se il payload viene eseguito nel front-end (pagine pubbliche), i visitatori del sito possono essere colpiti (reindirizzamenti malevoli, moduli falsi, crypto­miner, iniezione di contenuti).
  • Se il payload viene eseguito all'interno delle pagine di amministrazione (ad esempio, quando un editor o un amministratore apre il post nel dashboard), gli utenti con privilegi più elevati possono essere presi di mira portando a un takeover del sito: dirottamento dell'account, installazione di plugin/temi, modifiche alle impostazioni o installazione di backdoor.
• Il plugin è stato corretto nella versione 2.4. L'azione corretta immediata per i siti interessati è aggiornare alla versione 2.4 o successiva.

---

Perché un Contributor può essere pericoloso — modello di minaccia nel mondo reale

Molti proprietari di siti pensano che gli utenti di livello Contributor siano a basso rischio perché non possono pubblicare contenuti. Sebbene questa sia una concezione valida per la gestione dei contenuti, i contributor possono comunque tipicamente creare post, modificare le proprie bozze e aggiungere campi personalizzati (a seconda della configurazione del sito). L'XSS memorizzato tramite campi personalizzati è particolarmente pericoloso perché:

• Il contenuto malevolo è persistente: è memorizzato nel database e verrà attivato ogni volta che viene visualizzato.
• Se il sito o il tema stampa campi personalizzati nelle pagine di amministrazione (anteprime dei post, meta box) o nelle pagine front-end senza escaping, gli script vengono eseguiti con i privilegi dell'utente che visualizza nel proprio browser.
• Gli attaccanti possono creare payload che eseguono azioni per conto di un amministratore (cambiare password, creare account amministratore, installare plugin) sfruttando la sessione autenticata dell'amministratore e richieste contraffatte (CSRF combinato con XSS).

In breve: i contributi degli utenti di cui ti fidavi per il contenuto possono essere sfruttati per compromettere il sito se la sanitizzazione/escaping è assente.

---

Flusso di sfruttamento tipico (alto livello, non azionabile)

1. L'attaccante registra o utilizza un account con privilegi di Collaboratore (o compromette uno).
2. L'attaccante modifica una bozza o crea un post e aggiunge contenuto malevolo in un campo personalizzato (ad esempio, <script>…</script> o payload basati su attributi come onerror=… all'interno di un tag consentito).
3. Il sito memorizza quel contenuto in postmeta.
4. Quando il post viene caricato in un contesto in cui il plugin o il tema restituisce quel campo personalizzato non sanitizzato (pagina front-end, anteprima admin o meta box), il browser esegue il codice iniettato.
5. Se un amministratore visualizza la pagina o il post interessato nell'interfaccia di amministrazione (o se i visitatori sono mirati), lo script iniettato può:
   • Rubare i cookie dell'amministratore (se non HttpOnly — anche se le moderne migliori pratiche riducono il furto di cookie ma non tutti i siti le seguono),
   • Utilizzare i privilegi di amministratore per creare un nuovo account amministratore tramite REST API / endpoint admin,
   • Modificare file o impostazioni di plugin/tema,
   • Installare una backdoor o persistere ulteriormente malware,
   • Esfiltrare dati.

Poiché lo sfruttamento richiede spesso che un amministratore interagisca (visualizzi il post in admin o faccia clic su un link di anteprima specifico), Patchstack elenca “Interazione Utente Richiesta”, ma questa interazione può essere semplice come aprire l'editor del post o un link di anteprima creato ad hoc.

---

Passi pratici per proteggere il tuo sito — azioni immediate (lista di controllo)

1. Aggiorna il plugin
   – Se stai utilizzando AddFunc Head & Footer Code, aggiorna immediatamente alla versione 2.4 o successiva. Questa è la correzione canonica.
2. Se non puoi aggiornare immediatamente
   – Rimuovi o disabilita temporaneamente il plugin.
   – Blocca gli account dei collaboratori dall'editing o dall'aggiunta di campi personalizzati fino a quando il plugin non è aggiornato.
   – Applica patch virtuali a livello di WAF (vedi le indicazioni WAF qui sotto).
3. Scansiona contenuti dannosi nei campi personalizzati
   – Usa WP­CLI o query DB dirette per trovare valori meta contenenti <script, unerrore=, javascript:, o HTML sospetto.
       – Esempio (esegui prima il backup del tuo DB):
          wp db query "SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script%';"
       – Cerca anche unerrore=, carico=, javascript: modelli.
   – Rivedi le voci e rimuovi o sanitizza i valori meta sospetti.
4. Audit degli account utente
   – Verifica tutti i Collaboratori e gli Editor: sono legittimi? Rimuovi account obsoleti o sospetti.
   – Applica password forti e 2FA per ruoli privilegiati (Editor, Amministratore).
5. Controlla i segni di compromesso
   – Cerca account admin sconosciuti, file plugin/tema inaspettati, file modificati di recente, attività pianificate e connessioni in uscita dal server.
   – Esegui una scansione malware (scanner di WP­Firewall o altro scanner affidabile).
6. Ruota le credenziali e le chiavi API se si sospetta una compromissione
   – Cambia le password admin e qualsiasi chiave API esposta.
   – Invalidare le sessioni se necessario (forza il logout per tutti gli utenti).
7. Esegui un backup prima della pulizia
   – Esegui un backup completo del sito (file e DB) prima della correzione. Questo preserva le prove e ti dà un punto di ripristino.
8. Rinforza i campi personalizzati in futuro
   – Richiedi sanitizzazione al salvataggio e escaping all'output — vedi le raccomandazioni sul codice qui sotto.

---

1. Come trovare in modo sicuro voci XSS memorizzate malevole

2. Cercare contenuti sospetti nel database è cruciale ma deve essere fatto con cautela:

• 3. Crea sempre un backup prima di eseguire query o apportare modifiche.
• 4. Inizia con query di sola lettura per identificare voci sospette, poi esaminale manualmente.
• 5. Esempio di query di rilevamento WP­CLI:

6. # Trova postmeta che contiene <script"

wp db query "SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';".

---

# Cerca gestori di eventi inline

wp db query "SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%onerror=%' OR meta_value LIKE '%onload=%';"

• 7. Esporta valori meta sospetti e ispezionali, poi decidi se sanitizzare o rimuovere. 6. 8. Pulizia delle voci sospette.
• 9. Se identifichi valori meta malevoli:

10. Se la voce è ovviamente malevola (blocco completo), rimuovi la riga meta.

11. Se la voce contiene dati utili ma anche tag iniettati, sanitizza il contenuto:.

---

12. <?php

// Esempio: sanitizza un valore di campo personalizzato salvato

1. $clean = wp_kses(
2. $raw_meta_value,

array( // consenti solo un insieme restrittivo di tag/attributi

• 'a' => array( 'href' => true, 'title' => true, 'rel' => true ),

<?php

• In output, esegui sempre l'escape in base al contesto:

<?php

• Pattern migliore: registra la meta con un callback di sanitizzazione (funziona bene con REST):

<?php

• Controlla sempre la capacità prima di salvare o rendere la meta riservata agli amministratori. Usa nonce per i moduli degli amministratori.

---

WAF e patching virtuale — protezione immediata a livello di rete

Quando esiste una vulnerabilità del plugin e non è possibile aggiornare immediatamente, un Web Application Firewall (WAF) ben configurato fornisce patching virtuale. Il patching virtuale significa intercettare richieste dannose e bloccarle prima che raggiungano il codice vulnerabile.

Le mitigazioni tipiche del WAF per questo tipo di XSS memorizzato includono:

• Bloccare le richieste POST che includono payload di script sospetti in nomi di campi meta noti (ad es., contenuti postmeta, _personalizzato_*).
• Bloccare o sanitizzare le richieste che contengono 6. tag, attributi di gestori di eventi (unerrore=, carico=), javascript: URI, contenuto di script codificato in base64, o schemi di offuscamento ovvi.
• Limitare il numero di POST che creano o aggiornano post da utenti a bassa privilegio.
• Bloccare firme di exploit noti e codifiche di payload.

Esempio di pseudo-regola (per un motore WAF generico) — solo concettuale:

Pseudocodice regola WAF: blocca i tag script nei campi postmeta'

Se esegui un WAF basato su host o un WAF cloud, configura una regola che ispeziona il corpo della richiesta per questi schemi e li blocca per gli utenti con privilegi di Collaboratore/Autore. Ciò fornisce una mitigazione immediata mentre aggiorni.

Presso WP­Firewall forniamo regole di patching virtuale mirate che rilevano e bloccano schemi utilizzati nei tentativi di XSS memorizzato, combinati con monitoraggio e notifica quando si è verificato un tentativo bloccato.

---

Esempi di regole WAF — stile ModSecurity (esempio, adatta al tuo ambiente)

Di seguito sono riportati esempi di modelli da utilizzare come punto di partenza. Questi sono illustrativi — testa attentamente per evitare falsi positivi:

Esempio di regola ModSecurity per rilevare i tag  nel corpo del POST"

Esempio di regola per rilevare attributi di eventi come onerror= o onload="

Importante: testa sempre le regole in un ambiente di staging per identificare casi limite legittimi (alcuni contenuti legittimi possono includere HTML consentito) e adatta le regole di conseguenza.

---

Rilevamento — registri e indicatori di sfruttamento

Se sospetti che si sia verificato uno sfruttamento:

• Controlla i registri di accesso del server per i POST che creano o modificano post (POST a /wp-admin/post.php, /wp-json/wp/v2/posts).
• Controlla i registri dell'applicazione (se li hai) per parametri POST sospetti.
• Cerca avvisi dal tuo scanner malware che mostrano file di plugin/tema modificati, file sconosciuti o webshell.
• Controlla l'elenco degli utenti amministratori per nuovi account amministrativi creati.
• Cerca connessioni in uscita dal tuo server verso host sconosciuti.
• Rivedi i recenti cron job e i task pianificati per esecuzioni PHP sconosciute.

Se trovi contenuti iniettati in postmeta, trattalo come una potenziale compromissione: esegui una risposta completa all'incidente (quarantena, snapshot forense, ripristina da un backup pulito se necessario).

---

Dopo un'infezione — rimedio e indurimento

Se trovi prove che il sito è stato compromesso:

1. Isolare il sito (mettilo offline o blocca l'accesso in entrata) mentre indaghi.
2. Preservare le prove: esegui uno snapshot completo, conserva i registri (webserver, database).
3. Identifica i meccanismi di persistenza: controlla per utenti amministratori aggiunti, wp-config.php modificato, file di core sostituiti, plugin/temi dannosi, attività cron, eventi pianificati.
4. Pulisci: rimuovere file dannosi e voci di database. Se non sei sicuro, ripristina da un backup pulito.
5. Copia i log web e di sistema in un luogo sicuro.: reimpostare tutte le password, revocare le chiavi API, ruotare le chiavi SSH.
6. Patch: aggiornare il core di WordPress, i plugin e i temi all'ultima versione.
7. Indurire: limitare i permessi dei file, disabilitare la modifica dei file tramite wp-config.php (define('DISALLOW_FILE_EDIT', true)), applicare 2FA per tutti gli amministratori, rivedere il principio del minimo privilegio per tutti gli account.
8. Monitor: abilitare il monitoraggio della sicurezza, il monitoraggio dell'integrità dei file e l'allerta per eventi critici.

---

Controlli a lungo termine — ridurre il rischio di abuso di ruolo e HTML non affidabile

• Minimizzare il numero di account che possono modificare contenuti; applicare il minimo privilegio.
• Richiedere flussi di approvazione per i contenuti inviati dagli utenti dove possibile (revisionare prima della pubblicazione).
• Limitare quali ruoli possono aggiungere campi personalizzati o utilizzare plugin che espongono il rendering dei campi personalizzati.
• Educare i collaboratori sui rischi di incorporare HTML nei campi.
• Utilizzare intestazioni Content Security Policy (CSP) per limitare l'impatto degli script iniettati (questo può ridurre la portata di alcuni attacchi XSS).
• Per i siti con molti collaboratori, abilitare una separazione dei ruoli più forte e considerare plugin per il flusso di moderazione.

---

Come un WAF affidabile + sicurezza gestita riduce il tempo di rimedio

Un WAF gestito e un servizio di sicurezza forniscono:

• Patch virtuali rapide: bloccare immediatamente i tentativi di sfruttamento senza dover modificare il codice dell'applicazione.
• Aggiornamenti delle firme man mano che la ricerca viene pubblicata in modo che le regole catturino i payload emergenti.
• Strumenti di scansione e rimozione di malware per trovare e rimediare ai contenuti iniettati.
• Monitoraggio e allerta in modo da non dover controllare i log 24 ore su 24, 7 giorni su 7.
• Guida durante la risposta agli incidenti e assistenza al rollback quando necessario.

WP­Firewall combina queste capacità con logica specializzata per WordPress (modelli di richiesta, endpoint REST, endpoint admin) in modo da poter rilevare e mitigare attacchi che mirano a vettori comuni di WordPress come XSS memorizzato nei meta.

---

Note pratiche per la regolazione del WAF (ridurre i falsi positivi)

• Escludere gli IP degli amministratori fidati dal blocco aggressivo può prevenire interruzioni nel flusso di lavoro degli amministratori — ma bilanciare ciò con il rischio per la sicurezza.
• Utilizzare regole che corrispondono ai nomi dei parametri comunemente usati per i campi meta (meta[], postmeta, acf, campi personalizzati) piuttosto che bloccare tutti 6. i tag a livello globale.
• Registrare richieste sospette ma non chiaramente malevole (modalità solo avviso) per un periodo prima di bloccare — questo aiuta a regolare le firme in base ai modelli di utilizzo del tuo sito.

---

Esempio di piano di risposta agli incidenti (conciso)

1. Aggiornare il plugin alla versione 2.4 (se possibile).
2. Se l'aggiornamento immediato è impossibile: abilitare la regola del patch virtuale che ispeziona i corpi POST per script e attributi di evento che mirano ai parametri postmeta.
3. Eseguire una query DB per trovare valori meta sospetti; esportare i risultati per la revisione.
4. Rimuovere le voci confermate come malevole e sanificare quelle ambigue.
5. Reimpostare le password per tutti gli amministratori; applicare 2FA.
6. Scansionare il filesystem per file modificati e file PHP sconosciuti.
7. Ripristinare da un backup pulito se la remediation è incerta.
8. Monitorare i log per tentativi ripetuti; bloccare gli IP offensivi.

---

Raccomandazioni amichevoli per gli sviluppatori per eliminare questa classe di bug

• Sanificare sempre al salvataggio e sfuggire all'output.
• Utilizzare le API di WordPress: register_post_meta con callback di sanificazione, sanitize_text_field, wp_kses_post, esc_html, esc_attr.
• Utilizzare nonce e controlli di capacità per qualsiasi operazione di salvataggio lato admin.
• Evitare di memorizzare HTML grezzo a meno che non sia assolutamente necessario; se lo fai, limitare i tag e gli attributi consentiti con wp_kses.
• Rendi la sicurezza parte della pipeline CI/CD: analisi statica, controlli delle dipendenze e revisioni di sicurezza prima delle pubblicazioni di plugin/temi.

---

Come verificare che il tuo sito non sia più vulnerabile

1. Assicurati che il codice AddFunc Head & Footer sia aggiornato alla versione 2.4 o successiva.
2. Verifica che non ci siano voci postmeta con 6. o attributi di evento che potrebbero essere eseguiti.
3. Conferma che le pagine front-end e admin del sito escano l'output dei campi personalizzati.
4. Controlla i log del tuo WAF per tentativi bloccati e assicurati di avere la registrazione/alert attivata.
5. Esegui una scansione completa del malware e verifica l'integrità dei file.

---

Inizia con la protezione gratuita di WP­Firewall

Proteggere il tuo sito WordPress non dovrebbe essere complicato. Se desideri una protezione di base immediata mentre rivedi gli aggiornamenti dei plugin e pulisci eventuali contenuti sospetti, considera di iscriverti al piano Basic gratuito di WP­Firewall. Il piano gratuito include un firewall gestito attivamente, larghezza di banda illimitata, un WAF, uno scanner malware e copertura di mitigazione per i rischi OWASP Top 10 — sufficiente per bloccare molti tentativi di exploit comuni e dare al tuo team il tempo di applicare correzioni in modo sicuro. Prova WP­Firewall Basic gratuitamente qui: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Se desideri la rimozione automatica del malware e un controllo più avanzato come le blacklist IP, i nostri piani a pagamento aggiungono queste funzionalità a un costo annuale modesto.)

---

Raccomandazioni finali — elenco di azioni prioritarie (breve)

1. Aggiorna il codice AddFunc Head & Footer a 2.4+ ora.
2. Se non puoi aggiornare immediatamente, blocca o disabilita il plugin e applica le regole di patching virtuale WAF.
3. Scansiona e rimuovi le voci di campo personalizzato dannose.
4. Controlla gli utenti e applica password/2FA per gli account privilegiati.
5. Indurire la sanitizzazione al momento del salvataggio e l'escaping al momento dell'output per i campi personalizzati.
6. Usa WP­Firewall o un WAF gestito per ottenere protezione e monitoraggio immediati.

---

Pensieri conclusivi

Questa vulnerabilità è un promemoria che anche i ruoli apparentemente a bassa privilegio e i piccoli plugin possono presentare rischi eccessivi se i dati vengono memorizzati e successivamente resi senza una corretta sanitizzazione e escaping. WordPress è flessibile, il che è il suo maggiore punto di forza — e anche la sua fonte di rischio più frequente quando il codice assume fiducia dove non dovrebbe.

Applica l'aggiornamento, scansiona e rimuovi valori meta sospetti e metti un WAF davanti al tuo sito — non come sostituto permanente di codice sicuro, ma come un controllo compensativo essenziale che ti guadagna tempo mentre risolvi la causa principale. Se desideri aiuto nell'implementare le regole WAF, il patching virtuale o una pulizia post-incidente, il team di WP­Firewall è specializzato in mitigazioni rapide e consapevoli di WordPress.

Se desideri un audit passo-passo o assistenza, contatta il tuo fornitore di sicurezza o fai affidamento sul piano gratuito di WP­Firewall per ottenere una protezione di base immediata mentre risolvi i problemi.

Rimani al sicuro e tratta i campi personalizzati come input non affidabili — sanitizza, esegui l'escape e rivedi.

— Team di Sicurezza WP­Firewall