Nome del plugin	aggiungispaziofree
Tipo di vulnerabilità	CSRF
Numero CVE	CVE-2026-6701
Urgenza	Basso
Data di pubblicazione CVE	2026-05-04
URL di origine	CVE-2026-6701

Cross-Site Request Forgery (CSRF) concatenato a Stored Cross‑Site Scripting (XSS) in addfreespace <= 0.1.3 — Cosa devono sapere e fare i proprietari di siti WordPress

Una vulnerabilità recentemente divulgata che impatta il aggiungispaziofree plugin WordPress (versioni <= 0.1.3) è stata assegnata CVE‑2026‑6701. La vulnerabilità è un problema CSRF (Cross‑Site Request Forgery) che può essere concatenato in una condizione XSS (Cross‑Site Scripting) memorizzata. Sebbene il punteggio CVSS complessivo sia relativamente basso (4.3), il rischio nel mondo reale può essere superiore a quanto suggerisce il numero — specialmente quando gli attaccanti prendono di mira i siti in campagne di massa o si affidano a ingannare utenti privilegiati per interagire con un link o una pagina creata ad hoc.

Come team di sicurezza per WP‑Firewall, vogliamo spiegare, in linguaggio semplice e con indicazioni specifiche, cosa significa questo problema, come può essere abusato, come rilevare lo sfruttamento e — soprattutto — cosa puoi fare subito per proteggere i tuoi siti. Questa guida è scritta per proprietari di siti, amministratori, sviluppatori e team di hosting.

---

Riepilogo esecutivo (punti chiave rapidi)

• Una vulnerabilità in addfreespace (<= 0.1.3) consente a un attaccante di inviare richieste che non sono protette contro il CSRF. Se un utente privilegiato (amministratore o altro ruolo ad alta privilegio) viene ingannato a visitare una pagina malevola o a cliccare su un link malevolo, l'attaccante può memorizzare payload JavaScript nel sito (XSS memorizzato).
• L'XSS memorizzato eseguito in un contesto di amministrazione può portare a takeover dell'account, escalation dei privilegi, furto di dati o installazione di backdoor persistenti.
• Non è disponibile alcuna patch ufficiale per il plugin al momento della pubblicazione. Si consiglia vivamente di adottare misure immediate.
• Azioni immediate raccomandate: disattivare o rimuovere il plugin; limitare l'accesso alle pagine di amministrazione del plugin; applicare regole WAF o patch virtuali; scansionare per script iniettati e modifiche sospette; reimpostare le credenziali di amministrazione e ruotare le chiavi; e implementare un indurimento a lungo termine.
• Gli utenti di WP‑Firewall possono applicare patch virtuali, regole WAF gestite e scansioni attive per ridurre immediatamente il rischio.

---

Perché il CSRF concatenato con l'XSS memorizzato è pericoloso (in termini umani)

CSRF e XSS sono tipi di attacco diversi, ma quando combinati diventano potenti:

• CSRF: Un attaccante inganna un utente autenticato (spesso un amministratore) a eseguire un'azione che non intendeva — ad esempio, facendogli cliccare su un link o visitare una pagina web che effettua una richiesta al sito vulnerabile. Le azioni di amministrazione di WordPress correttamente codificate includono controlli nonce e controlli di capacità per prevenire questo. In questo caso, il plugin non è riuscito a convalidare correttamente l'origine/nonce.
• XSS memorizzato: Se un attaccante può far salvare codice JavaScript arbitrario nel database del sito web (ad esempio, in un'opzione del plugin o in un campo personalizzato), quel codice verrà eseguito ogni volta che il contenuto memorizzato viene visualizzato nel contesto di amministrazione o frontend senza una corretta escape.

Catenazione: Un attaccante non autenticato crea una pagina che invia un POST/GET all'endpoint del plugin vulnerabile in background o quando un amministratore del sito visita. Se il plugin memorizza il payload JavaScript dell'attaccante (e successivamente lo visualizza senza escape), il payload viene eseguito nel contesto del browser dell'amministratore. Da lì, un attaccante può rubare i cookie di autenticazione, eseguire azioni come quell'utente (creare post, installare plugin/temi, esportare dati) e stabilire accesso persistente.

Anche se un attaccante ha bisogno che l'amministratore esegua un'interazione (ad esempio, cliccare su un link), quel singolo clic può essere tutto ciò di cui ha bisogno per passare a un compromesso completo.

---

Cause tecniche radice (cosa è andato storto)

Dai dettagli riportati e dai modelli di sfruttamento tipici, la catena indica solitamente i seguenti fallimenti nel codice del plugin:

1. Mancanza di protezione CSRF
   • Nessun utilizzo dei nonce di WordPress (ad es., wp_create_nonce / check_admin_referer) per azioni che modificano lo stato.
   • Nessuna validazione dell'origine della richiesta o dell'intestazione referer per garantire che la richiesta provenga da un'interfaccia admin fidata.
2. Controllo delle capacità insufficiente
   • Gli endpoint del plugin potrebbero non avere controlli adeguati delle capacità utente (current_user_can) o imporre la capacità appropriata per il compito.
3. Mancanza o insufficiente sanificazione dei dati e escaping dell'output
   • Dati pericolosi forniti dall'utente vengono salvati nel database senza sanificazione (ad es., utilizzando sanitize_text_field, wp_kses_post) e vengono successivamente visualizzati senza escaping (ad es., esc_html, esc_attr, o un adeguato filtraggio kses).
4. Interfacce admin che espongono endpoint scrivibili accessibili tramite metodi HTTP non autenticati
   • Hook di azione o endpoint AJAX che accettano richieste POST senza adeguate protezioni.

Il risultato netto: un attaccante può attivare un cambiamento di stato (memorizzare contenuti) utilizzando il browser di una vittima, e il contenuto memorizzato può essere successivamente visualizzato ed eseguito.

---

Come un attacco si svolgerebbe tipicamente (livello alto)

1. L'attaccante identifica l'endpoint del plugin vulnerabile (ad esempio, un URL di azione admin utilizzato da addfreespace).
2. L'attaccante crea una pagina web che effettua un POST (o GET) a quell'endpoint con un payload contenente JavaScript (un vettore XSS memorizzato). L'invio del modulo include i parametri attesi dal plugin.
3. Un amministratore (o un altro utente privilegiato) visita la pagina malevola o clicca su un link mentre è autenticato nel sito WordPress vulnerabile.
4. Poiché il plugin manca di protezione CSRF, la richiesta viene accettata e il JavaScript malevolo viene salvato nel database (ad es., in un'opzione, post meta, o campo controllato dal plugin).
5. Quando il sito (o la pagina admin) visualizza successivamente quel valore memorizzato senza sanificazione/escaping, il JavaScript viene eseguito nel contesto del browser dell'amministratore.
6. Il JavaScript può quindi:
   • Leggere i cookie o lo storage locale (e esfiltrarli);
   • Effettuare richieste autenticate utilizzando le credenziali dell'amministratore (ad es., creare nuovi utenti admin, installare plugin);
   • Carica script esterni per eseguire ulteriori azioni o per mantenere la persistenza.

Nota: Il passo chiave è l'utente privilegiato che esegue un'azione (ad es., visitare una pagina). Senza quell'interazione, il CSRF non può normalmente essere attivato. Detto ciò, molti amministratori cliccano su link o aprono pagine, e gli attori della minaccia sfruttano quel comportamento su larga scala.

---

Impatto — cosa possono ottenere gli attaccanti

XSS memorizzato eseguito in una sessione del browser amministrativo può abilitare:

• Presa di controllo dell'account (rubare i cookie di sessione o i token OAuth).
• Creazione di nuovi utenti amministrativi.
• Installazione di backdoor (plugin/temi malevoli) o attività pianificate che mantengono la persistenza.
• Esfiltrazione dei dati: esportazione di post, media o dati utente.
• Defacement del sito o iniezione di malware drive-by per infettare i visitatori.
• Pivoting per il controllo dell'hosting o accesso al database tramite ulteriore sfruttamento.

Sebbene il CVSS sia basso, l'impatto commerciale può essere grave se l'attaccante ottiene persistenza o prende il controllo di un sito di produzione.

---

Azioni immediate che devi intraprendere (stile risposta agli incidenti)

Se gestisci siti WordPress che utilizzano addfreespace (<= 0.1.3), tratta la situazione come urgente:

1. Disattiva il plugin ora
   • Accedi a wp-admin e disattiva addfreespace. Se non puoi accedere a wp-admin, rinomina la cartella del plugin tramite SFTP/SSH (wp-content/plugins/addfreespace -> addfreespace.disabilitato).
2. Rimuovi il plugin
   • Se non ne hai strettamente bisogno, rimuovilo dal codice sorgente. A volte rimuovere il plugin è l'opzione più sicura a breve termine fino a quando non viene rilasciata una versione corretta.
3. Metti il sito in modalità manutenzione mentre indaghi
   • Riduci la superficie di attacco mentre scansioni.
4. Applica immediatamente WAF/patching virtuale.
   • Blocca le richieste agli endpoint di amministrazione del plugin e disallow POST sospetti contenenti payload simili a script.
   • Se utilizzi WP‑Firewall, abilita il set di regole WAF gestito e la patch virtuale per questa vulnerabilità per bloccare i tentativi di sfruttamento anche mentre il plugin è presente.
5. Scansiona per payload iniettati e voci DB sospette.
   • Cerca post, opzioni, usermeta e altri archivi per <script, unerrore=, carico=, o altri gestori di eventi JS che sembrano inaspettati.
   • Esempio (difensivo, esegui come amministratore tramite WP‑CLI o client di database):
     • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'"
     • wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%'"
   • Nota: Le query esatte sopra assumono prefissi di tabella standard. Regola per prefissi personalizzati e sicurezza in produzione.
6. Ruota credenziali e segreti
   • Reimposta le password per tutti gli utenti admin.
   • Ruota le chiavi API, le credenziali dell'account di servizio e le chiavi in il file wp-config.php se sospetti una compromissione.
7. Rivedi gli account utente e i ruoli
   • Cerca account amministratori inaspettati o utenti con privilegi elevati.
8. Rivedi i log del server e di accesso
   • Ispeziona i log del server web e le tracce di audit per POST sospetti o richieste agli endpoint del plugin.
9. Ripristina da un backup noto buono se rilevi modifiche che non puoi pulire in sicurezza.
   • Se trovi backdoor o modifiche inspiegabili, un ripristino pulito potrebbe essere la soluzione più rapida.
10. Rafforzare l'accesso amministrativo
    • Applica l'autenticazione a 2 fattori (2FA) per tutti gli account privilegiati.
    • Limita l'accesso all'area admin per IP se possibile.
    • Usa password forti e uniche e una politica di blocco dell'account.

---

Come rilevare un XSS memorizzato da questa vulnerabilità (indicatori di compromissione)

Cerca i seguenti segni:

• JavaScript inaspettato in post, pagine, opzioni o contenuti dei widget.
• Nuovi utenti admin o cambiamenti imprevisti nei ruoli degli utenti.
• Contenuto dell'interfaccia admin che mostra avvisi strani, popup o reindirizzamenti.
• Richieste in uscita dal sito verso domini di terze parti sconosciuti (indicando esfiltrazione o callback).
• Log del server che mostrano POST a endpoint di plugin da referrer o user agent insoliti.
• CPU elevata o cron job programmati in modo imprevisto (indicando backdoor).

Controlli difensivi utili:

• Ricerca WP‑CLI per tag script in post e opzioni:
  • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'" --limit=100
  • wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%'" --limit=100
• Scansione con uno scanner malware affidabile (lato sito o livello host) per rilevare backdoor e webshell noti.
• Confronta i file attuali con uno snapshot pulito o i file originali distribuiti del plugin per trovare file alterati.

Quando trovi contenuti sospetti, isola e non eseguirli in un browser live. Trattali come malevoli fino a prova contraria.

---

Linee guida per la remediation a livello di codice per sviluppatori

Se mantieni il plugin o sviluppi temi/plugin, queste sono le pratiche di codifica difensiva essenziali da seguire per prevenire sia CSRF che XSS memorizzati:

1. Usa nonce e verificali su ogni richiesta che modifica lo stato
   • Quando generi un modulo o un link che esegue una modifica di stato:

     $nonce = wp_create_nonce( 'my_plugin_action' );

     Includilo nei moduli o AJAX:

     <input type="hidden" name="_wpnonce" value="" />

   • Nella gestione delle richieste:

     check_admin_referer( 'my_plugin_action' ); // o check_ajax_referer per AJAX

2. Controlla le capacità dell'utente
   • Prima di eseguire azioni, verifica:

     if ( ! current_user_can( 'manage_options' ) ) { wp_die( 'Permessi insufficienti' ); }

3. Sanitizza l'input prima di salvare
   • Usa sanitizzatori appropriati:
     • sanitize_text_field(), sanitize_email(), intval(), floatval()
     • Per input HTML: wp_kses_post() o wp_kses() con un elenco di autorizzazioni sicuro
4. Uscita in uscita
   • Escape sempre i dati quando stampi:
     • esc_html(), esc_attr(), wp_kses_post() a seconda del contesto.
5. Usa l'API REST e controlla i callback di autorizzazione
   • Per gli endpoint REST, implementa permission_callback che verifica capacità e nonce.
6. Valida i tipi di dati e le lunghezze attesi
   • Imposta lunghezze massime e caratteri consentiti.

Esempio (pseudo-codice difensivo):

// Nel modulo:
wp_nonce_field( 'my_plugin_save_settings', '_wpnonce', true );

// Nel gestore di invio:
if ( ! current_user_can( 'manage_options' ) ) {;

Per input HTML che deve consentire tag limitati:

$allowed = array(;

---

WAF e patching virtuale — regole pratiche da implementare ora

Se hai un WAF (firewall per applicazioni) come WP‑Firewall, puoi creare regole difensive che bloccano i tentativi di sfruttamento anche prima che venga rilasciata una patch ufficiale per il plugin. Considera i seguenti approcci ad alto livello:

1. Blocca contenuti POST/GET sospetti agli endpoint del plugin
   • Crea una regola per ispezionare le richieste che mirano ad azioni di amministrazione del plugin o file del plugin. Se il corpo della richiesta contiene tag script o gestori di eventi XSS comuni (onerror, onload, javascript:), blocca la richiesta.
2. Imposta la presenza di referer o origin per i POST di amministrazione
   • Blocca o sfida (CAPTCHA) i POST a wp-admin/admin-post.php, admin-ajax.php, o endpoint specifici del plugin che non includono un referer valido o un parametro _wpnonce.
3. Limita il tasso e sfida le richieste anonime agli endpoint amministrativi
   • Molti tentativi di sfruttamento sono automatizzati. La limitazione del tasso riduce i grandi attacchi automatizzati.
4. Patch virtuali: intercetta modelli di sfruttamento noti
   • Blocca le richieste che corrispondono esattamente ai nomi dei parametri o ai modelli URL utilizzati dal plugin vulnerabile quando contengono contenuti sospetti.
5. Blocca le richieste che tentano di creare/modificare opzioni con contenuti script
   • Se una richiesta tenta di aggiornare wp_options o campi comunemente usati dal plugin con <script nel payload, bloccalo.

Esempio di una regola di firewall concettuale (pseudo):

SE request.path CORRISPONDE A "/wp-admin/admin-post.php" O "/wp-admin/*addfreespace*" E request.method IN (POST, GET) ALLORA

Note:

• Evita regole troppo ampie che potrebbero risultare in falsi positivi. Testa prima in modalità monitor.
• Usa regole combinate con registrazione e avvisi in modo da poter adattarti rapidamente.

Se sei un utente di WP‑Firewall, abilita il set di regole gestito che mira ai modelli di sfruttamento CSRF/XSS e abilita la patch virtuale per le vulnerabilità addfreespace. Questo fornisce protezione immediata mentre segui una risoluzione a lungo termine.

---

Lista di controllo post-risoluzione (cosa fare dopo aver rimosso il plugin o applicato una patch)

1. Conferma che il plugin sia stato rimosso o aggiornato a una versione patchata quando disponibile.
2. Riscanifica l'intero sito per codice malevolo, webshell e file modificati.
3. Controlla il database per i payload memorizzati e rimuovili o sanitizzali.
4. Ruota le credenziali: password di amministratore, chiavi SSH, chiavi API.
5. Riemetti eventuali token o chiavi trapelati che potrebbero essere stati esposti.
6. Ripristina un backup pulito se non puoi garantire completamente che il sito sia pulito.
7. Monitora i log e il rilevamento delle intrusioni per tentativi ripetuti.
8. Documenta l'incidente, le tue azioni e eventuali lezioni apprese.

---

Come comunicare ai clienti e agli stakeholder (se gestisci altri siti)

• Breve e fattuale: spiega il plugin interessato, le versioni, il livello di rischio e le azioni che hai intrapreso (disattivato/rimosso, scansionato, implementate regole WAF).
• Fornisci rassicurazioni: elenca le mitigazioni esatte (regole WAF in atto, scansione completata, credenziali ruotate, backup utilizzati).
• Fornisci indicazioni: istruisci gli utenti finali a cambiare le password se hanno effettuato l'accesso durante il periodo di esposizione e a prestare attenzione ad attività sospette.
• Offri un follow-up: programma una revisione completa della sicurezza se vengono trovati indicatori di compromissione.

---

Lista di controllo per il rafforzamento che dovrebbe essere una prassi standard (per prevenire problemi simili)

• Applica 2FA per ogni account amministrativo.
• Limita l'accesso all'area admin tramite una lista di autorizzazione IP dove possibile.
• Disabilita la modifica dei file in wp-admin:

  define( 'DISALLOW_FILE_EDIT', true );

• Applica il principio del minimo privilegio: dai agli utenti solo le capacità di cui hanno assolutamente bisogno.
• Mantieni aggiornati il core, i temi e i plugin di WordPress.
• Installa e utilizza uno scanner di siti affidabile e un WAF gestito.
• Usa password forti e uniche e una politica di gestione centralizzata dei segreti.
• Esegui backup quotidiani (o più frequenti) con backup immutabili memorizzati offsite.
• Rivedi il codice del plugin prima di installare plugin di autori sconosciuti o articoli con pochi download.

---

Se trovi JavaScript sospetto nel tuo DB — guida per una pulizia sicura.

• Non visitare pagine che mostrano contenuti sospetti in una sessione del browser admin prima di pulire.
• Esporta la(riga/e) sospetta(e) dal DB in un'area di quarantena sicura e analizzale offline o su una macchina isolata.
• Rimuovi o sanifica le voci utilizzando funzioni sicure (wp_update_post con contenuto sanificato, update_option con contenuto sanificato).
• Se non sei sicuro dell'estensione della compromissione, ripristina da un backup pulito verificato e riapplica patch e indurimenti.

---

Perché un basso CVSS non significa “non è un grosso problema”

Sfruttamento automatico di massa e ingegneria sociale si basano su passaggi concatenati a bassa complessità. Una vulnerabilità che richiede “solo” che un admin clicchi su un link può essere estremamente potente quando gli attaccanti inviano decine di migliaia di email di phishing o compromettono altri siti web per incorporare l'exploit. XSS memorizzato eseguito in un contesto admin è particolarmente sensibile. Tratta le vulnerabilità con una valutazione pratica del rischio: facilità di sfruttamento, numero di siti colpiti e il potenziale guadagno per l'attaccante. In molti casi, la patch virtuale immediata e la rimozione del plugin sono prudenti anche per punteggi CVSS bassi.

---

Rapido playbook di risposta agli incidenti (una pagina)

1. Disattiva il plugin (o rinomina la cartella del plugin).
2. Abilita la modalità di manutenzione e blocca il traffico se necessario.
3. Abilita le regole WAF/patch virtuali per il plugin.
4. Scansiona il database per tag script e voci sospette; quarantena gli elementi trovati.
5. Scansiona il filesystem per file modificati e webshell.
6. Ruota le password degli admin e le chiavi API.
7. Rivedi i log e gli account utente.
8. Ripristina da backup puliti se necessario.
9. Indurisci l'accesso admin (2FA, lista di autorizzazione IP).
10. Reinserisci il plugin solo quando è stato patchato e dopo un QA completo.

---

Prova il piano WP‑Firewall Basic (Gratuito) — Protezione essenziale senza il prezzo.

Se stai cercando una protezione immediata e pratica mentre segui i passaggi sopra, considera di iscriverti al piano WP‑Firewall Basic (Gratuito). Include protezioni essenziali che aiutano a bloccare i tentativi di sfruttamento e ridurre rapidamente la tua esposizione:

• Firewall gestito e WAF per bloccare schemi di sfruttamento noti
• Larghezza di banda illimitata — il firewall non limita il tuo traffico.
• Scanner malware per rilevare backdoor comuni e payload dannosi.
• Mitigazione per i rischi OWASP Top 10 per ridurre i vettori di attacco comuni.

Puoi registrarti per il piano gratuito e implementare rapidamente queste protezioni su: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Parole finali dal team di sicurezza di WP‑Firewall

Vulnerabilità come la catena addfreespace CSRF→stored‑XSS sono un promemoria che anche i plugin piccoli o di nicchia possono introdurre rischi eccessivi. La buona notizia: puoi agire in modo efficace subito. Disattiva o rimuovi il plugin, applica le regole WAF e le patch virtuali, scansiona per iniezioni, ruota le credenziali e rinforza l'accesso amministrativo. Se gestisci più siti web (come un'agenzia o un host), automatizza la scansione e la patching virtuale per ridurre il periodo di esposizione su tutti i siti.

Siamo impegnati ad aiutare i proprietari di siti a ridurre rapidamente e con fiducia il rischio. Se hai bisogno di assistenza pratica, ricerca di minacce o regole di patching virtuale personalizzate, WP‑Firewall è disponibile per supportare la pulizia e la difesa a lungo termine.

Rimani al sicuro e dai priorità alla mitigazione rapida quando viene divulgata una vulnerabilità: il tempo tra la divulgazione e lo sfruttamento attivo è spesso più breve di quanto ti aspetti.

— Team di sicurezza WP-Firewall

---

Appendice: Comandi di riferimento rapido (difensivi)

• Cerca tag script nei post (regola il prefisso della tabella se necessario):

  query wp db "SELEZIONA ID, post_title DA wp_posts DOVE post_content COME '%

• Cerca wp_options per contenuti simili a script:

  wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%';"

• Elenca i file modificati di recente (ultimi 7 giorni) su un host UNIX:

  find /path/to/wordpress -type f -mtime -7 -print

Ricorda: esegui questi comandi solo con accesso e backup appropriati, e evita di esporre il sito a ulteriori rischi durante l'indagine.