Nome del plugin	LambertGroup – AllInOne – Banner con miniature
Tipo di vulnerabilità	XSS
Numero CVE	CVE-2026-28108
Urgenza	Medio
Data di pubblicazione CVE	2026-02-28
URL di origine	CVE-2026-28108

Avviso di sicurezza urgente: XSS riflesso in ‘LambertGroup – AllInOne – Banner con miniature’ (<= 3.8) — Cosa devono fare ora i proprietari dei siti

Autore: Team di sicurezza WP-Firewall

Data: 2026-02-26

Etichette: WordPress, Vulnerabilità, XSS, WAF, WP-Firewall

Riepilogo: È stata divulgata una vulnerabilità di Cross‑Site Scripting (XSS) riflessa (CVE‑2026‑28108) che colpisce le versioni del plugin LambertGroup – AllInOne – Banner con miniature <= 3.8. La vulnerabilità è classificata come Media (CVSS 7.1). È sfruttabile da attaccanti non autenticati tramite link creati ad hoc che richiedono l'interazione di un obiettivo (cliccare/visitare). Fino a quando non sarà disponibile una patch ufficiale per il plugin, WP‑Firewall raccomanda vivamente misure di mitigazione immediate — inclusi patch virtuali temporanei, restrizione o rimozione del plugin, applicazione della Content Security Policy (CSP) e monitoraggio per segni di compromissione.

---

Perché è importante (TL;DR per i proprietari di siti impegnati)

L'XSS riflesso consente a un attaccante di creare un link o una pagina che, quando visitata da un utente del sito (o a volte da un amministratore del sito), fa sì che il sito rifletta uno script controllato dall'attaccante nel browser della vittima. Quello script può fare cose dannose: eseguire azioni come la vittima, rubare cookie o token di autenticazione, iniettare contenuti dannosi, dirottare sessioni o caricare ulteriore malware. In questo caso:

• Plugin colpito: LambertGroup – AllInOne – Banner con miniature
• Versioni vulnerabili: <= 3.8
• CVE: CVE‑2026‑28108
• CVSS: 7.1 (Medio)
• Privilegio richiesto: Non autenticato (l'attaccante non deve essere connesso)
• Lo sfruttamento richiede interazione dell'utente (una vittima deve cliccare su un link creato ad hoc o visitare una pagina malevola)

Se il tuo sito utilizza questo plugin e servi visitatori (soprattutto utenti amministrativi), devi agire ora.

---

Cos'è l'XSS riflesso e perché è pericoloso per i siti WordPress

L'XSS riflesso si verifica quando i dati da una richiesta HTTP (stringa di query URL, dati POST, intestazioni) vengono inclusi nell'HTML generato dal server senza una corretta validazione o escaping. L'attaccante crea un URL contenente JavaScript malevolo. Quando un utente clicca su quell'URL e il server risponde con una pagina che riecheggia il contenuto iniettato direttamente in HTML/JS, il browser della vittima esegue il codice dell'attaccante.

Conseguenze sui siti WordPress:

• Dirottamento di sessione (se i cookie di autenticazione non sono SameSite/HttpOnly e accessibili)
• Escalation dei privilegi tramite abuso in stile CSRF quando uno script controllato dall'attaccante attiva azioni di amministrazione con le credenziali della vittima
• Defacement, inserimento di spam, reindirizzamenti malevoli
• Distribuzione di ulteriore malware o script di cryptomining ai visitatori del sito
• Danno alla reputazione, penalità SEO e inserimento nella lista nera da parte dei motori di ricerca

Poiché la vulnerabilità è sfruttabile da un vettore non autenticato e colpisce un ecosistema CMS ampiamente utilizzato, merita cautela anche se i requisiti immediati includono l'interazione dell'utente.

---

Chi è a maggior rischio

• Siti che eseguono LambertGroup – AllInOne – Banner con Thumbnails <= 3.8
• Siti che consentono la navigazione aperta di pagine non registrate che possono riflettere parametri di query nell'output HTML
• Siti con più utenti amministrativi che potrebbero cliccare su link ricevuti via email o canali social
• Siti con intestazioni di sicurezza HTTP deboli (nessun CSP, mancanza di X‑Content‑Type‑Options o mancanza di flag cookie HttpOnly/SameSite)

Se tu o i tuoi utenti potreste ricevere link che potrebbero essere cliccati mentre siete connessi, ora è il momento di mitigare.

---

Conferma se il tuo sito è interessato

1. Controlla i plugin installati
   • Visita il tuo admin di WordPress: Dashboard → Plugin
   • Cerca “LambertGroup – AllInOne – Banner con Thumbnails”
   • Se presente, annota la versione del plugin. Se è <= 3.8, tratta il tuo sito come vulnerabile.
2. Usa WP‑Firewall (o un altro scanner di sicurezza) per eseguire una scansione del plugin e delle vulnerabilità
   • Il nostro scanner segnala le versioni di plugin vulnerabili note e mostrerà il CVE e i dettagli quando rilevato.
3. Cerca registri di richieste sospette
   • Cerca richieste in arrivo contenenti tag script codificati, attributi di gestore eventi sospetti o lunghe stringhe di query che sembrano tentativi di iniettare HTML/JS.
   • Qualsiasi registro che mostra richieste a pagine che includono una stringa di query e una risposta che contiene lo stesso contenuto potrebbe indicare che il plugin riflette l'input.
4. Scansiona il contenuto del sito per JavaScript iniettato
   • Cerca nei post del database, nelle opzioni e nei file del tema per 6. tag o codice offuscato insolito.
   • Controlla il codice sorgente delle pagine pubbliche per script o tag inline inaspettati.

Se uno dei controlli sopra restituisce indicatori positivi, tratta la situazione come alta priorità.

---

Mitigazione immediata (cosa fare nei prossimi 60–120 minuti)

Se scopri che il plugin è installato e vulnerabile, prendi queste mitigazioni immediate. Questi passaggi bilanciano velocità e sicurezza ed evitano di esporre eccessivamente il sito mentre pianifichi una soluzione a lungo termine.

1. Disattiva il plugin
   • L'azione a breve termine più sicura: vai su WordPress admin → Plugin e disattiva il plugin.
   • Se il plugin è necessario per la funzionalità del sito, considera di disinstallarlo temporaneamente o sostituirlo con un'alternativa sicura.
2. Se non puoi disattivarlo (rischio di interruzione del sito), limita l'accesso
   • Limita l'accesso alle pagine che utilizzano il plugin tramite autenticazione o liste di autorizzazione IP a livello di server web.
   • Imposta temporaneamente la protezione con password a livello di directory/URL per le pagine che generano output del plugin.
3. Applica patch virtuali tramite WP‑Firewall
   • Abilita la nostra regola di mitigazione preconfigurata per questa vulnerabilità (abbiamo pubblicato una patch virtuale che blocca i tentativi di sfruttamento tipici).
   • La patch virtuale bloccherà e registrerà i tentativi di attacco al confine senza alterare il codice del plugin.
4. Indurire le intestazioni HTTP
   • Aggiungi o rafforza una Politica di Sicurezza dei Contenuti (CSP) che vieti gli script inline e limiti le fonti degli script. Esempio di politica minima:
     Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.example.com; object-src 'none'; frame-ancestors 'none';
   • Assicurati che i cookie utilizzino Secure, HttpOnly e SameSite=lax/strict dove possibile.
5. Monitorare e registrare
   • Aumenta il logging per richieste sospette e cattura l'URI completo della richiesta e l'agente utente per le indagini.
   • Monitora l'attività degli utenti admin e i tentativi di accesso.
6. Notifica il tuo team e gli utenti
   • Informare gli amministratori e gli editori di non cliccare su link sospetti e di evitare di aprire pagine non affidabili mentre sono connessi.

Questi passaggi riducono rapidamente il rischio mentre ti prepari per una rimedio approfondito.

---

Rimedi consigliati e soluzioni a lungo termine

1. Aggiorna il plugin quando viene rilasciata una patch del fornitore
   • Se l'autore del plugin rilascia una versione corretta >= 3.9 (o qualunque sia la versione della patch), aggiorna immediatamente. Conferma che il changelog faccia riferimento a una correzione XSS.
2. Se non c'è ancora una patch ufficiale: sostituisci o rimuovi il plugin
   • Se il plugin non è cruciale, rimuovilo fino a quando non è disponibile una patch.
   • Se hai bisogno di funzionalità simili, distribuisci un plugin alternativo affidabile e attivamente mantenuto che segua le migliori pratiche di sicurezza di WordPress.
3. Correggi il codice del plugin (per sviluppatori / manutentori del sito)
   • Assicurati che tutti i dati che possono essere restituiti al browser siano correttamente codificati al momento dell'output:
     • Utilizzo esc_html(), esc_attr(), esc_url(), E wp_kses() per autorizzare HTML sicuro se necessario.
   • Convalida e sanitizza l'input con sanitize_text_field(), intval(), wp_filter_nohtml_kses(), ecc.
   • Preferisci la convalida dell'elenco bianco lato server degli input attesi (ad es., numeri o slug).
   • Evita di stampare raw $_GET O $_REQUEST valori in contesti HTML o JavaScript.
   • Usa nonce per azioni che cambiano stato e verifica lato server.
4. Aggiungi una convalida esplicita dell'input sugli endpoint
   • Ogni endpoint o shortcode che accetta input dell'utente dovrebbe convalidare i tipi: interi, ID post, slug, enumerazioni.
   • Rifiuta o normalizza valori inaspettati piuttosto che rifletterli parola per parola.
5. Usa CSP e intestazioni di sicurezza come difesa di secondo livello
   • Anche se CSP non è un sostituto per una corretta codifica dell'output, aumenta significativamente la difficoltà dell'attacco bloccando script inline e limitando gli host di script consentiti.
6. Rivedi il modello di privilegi utente
   • Riduci il numero di utenti amministratori.
   • Usa il principio del minimo privilegio: assegna agli utenti solo le capacità di cui hanno bisogno.
7. Tieni tutto il resto aggiornato
   • Gli aggiornamenti del core di WordPress, dei temi, di PHP e della piattaforma di hosting riducono la superficie di attacco complessiva.

---

Come capire se il tuo sito è stato sfruttato

Segni che un XSS è già stato utilizzato:

• JavaScript imprevisto nell'output della pagina, specialmente se non fa parte del tuo tema o dei plugin.
• I visitatori segnalano reindirizzamenti verso domini sconosciuti o la visualizzazione di annunci indesiderati.
• Nuovi utenti amministratori creati senza autorizzazione.
• Post/commenti insoliti o contenuti spam che appaiono in pagine o post.
• Avvisi del browser da Google Safe Browsing o segnalazioni dirette che il sito è stato contrassegnato.
• Connessioni di rete in uscita insolite originate dal tuo server (log di scansione, log del firewall).

Se sospetti sfruttamento:

• Metti il sito offline (modalità manutenzione) mentre indaghi.
• Ripristina da un backup pulito noto (prima della prima attività sospetta).
• Esegui una scansione completa del malware e confronta gli hash dei file core con i file di rilascio puliti di WordPress.
• Cambia le credenziali (password admin, chiavi API/FTP) e ruota i segreti.
• Rivedi i log per determinare la cronologia dell'attacco e l'ambito.

---

Lista di controllo pratica per la rilevazione e il contenimento (passo dopo passo)

1. Inventario e conferma
   • Conferma che il plugin esista ed è <= 3.8.
   • Fai uno snapshot del sito (file e DB) per prove forensi.
2. Isolare
   • Se puoi, metti temporaneamente il sito offline o limita l'accesso solo agli amministratori.
   • Disabilita immediatamente il plugin vulnerabile.
3. Scansiona
   • Esegui una scansione completa del malware con uno scanner affidabile.
   • Cerca nelle tabelle del DB (wp_posts, opzioni_wp, wp_postmeta) per sospetti <script tag o JavaScript offuscato.
   • Usa grep o scansione basata su host per trovare script iniettati nei file.
4. Rimedia.
   • Rimuovi il contenuto iniettato trovato nel database o nei file.
   • Se l'infezione è ampia o sconosciuta, ripristina da un backup pulito.
5. Indurire
   • Applica la regola di patching virtuale WP‑Firewall (se utilizzi WP‑Firewall) per bloccare i tentativi di sfruttamento.
   • Aggiungi CSP e stringi le intestazioni di sicurezza.
   • Imposta password forti e l'autenticazione a due fattori per gli amministratori.
6. Monitor
   • Continua a registrare e monitorare i tentativi ripetuti e i segni di compromissione.

---

Come WP‑Firewall ti protegge contro XSS riflessi come CVE‑2026‑28108

Come firewall e team di sicurezza di WordPress, affrontiamo le vulnerabilità in tre livelli:

1. Prevenzione (prima che la richiesta raggiunga il codice dell'applicazione)
   • Le nostre regole di edge rilevano e bloccano le richieste che contengono modelli XSS comuni nelle stringhe di query e nei dati POST.
   • Ispezioniamo i payload codificati, i gestori di eventi sospetti e le tecniche di sfruttamento note utilizzate per riflettere gli script nel browser.
   • Le regole di patching virtuale vengono implementate per proteggere i clienti non appena una nuova vulnerabilità viene confermata, bloccando i tentativi di attacco senza richiedere aggiornamenti del plugin.
2. Rilevamento (nell'applicazione e nei pipeline di monitoraggio)
   • La scansione continua del sito cerca cambiamenti nell'output della pagina e nuovi JavaScript inline.
   • Il monitoraggio delle attività segnala attività insolite degli amministratori, picchi di traffico che mirano a endpoint specifici o payload GET/POST sospetti ripetuti.
3. Risposta (avvisi azionabili e rimedi)
   • Se viene rilevato un attacco, WP‑Firewall può mettere in quarantena o bloccare l'IP sorgente, avvisare gli amministratori del sito e applicare regole personalizzate per ridurre l'impatto.
   • Forniamo indicazioni per la risoluzione e, per i piani a pagamento, assistenza con la pulizia e il recupero.

Esempi di ciò che implementiamo (concettuale; le nostre regole di produzione sono più robuste e ottimizzate per evitare falsi positivi):

• Blocca le richieste contenenti tag script non scappati o attributi di gestori di eventi nelle stringhe di query.
• Normalizza e scarta i payload dove i parametri contengono costrutti JavaScript codificati.
• Limita il tasso e sfida schemi sospetti per prevenire sfruttamenti di massa.

Nota: Non pubblichiamo i contenuti esatti delle firme pubblicamente per prevenire informazioni che potrebbero essere utilizzate dagli attaccanti. Se sei un utente registrato di WP‑Firewall, la nostra regola di mitigazione per questa specifica vulnerabilità del plugin è già disponibile nel set di regole e applicata automaticamente a tutti gli account attivi sui siti protetti.

---

Concetti di regole WAF sicure che puoi applicare a livello di server web

Di seguito sono riportati esempi concettuali di difese che puoi implementare sul tuo edge (server web o WAF) per ridurre il rischio. Questi sono semplificati e destinati ad amministratori o hoster che comprendono il loro ambiente — ottimizzali per evitare di bloccare il traffico legittimo.

• Blocca l'evidente iniezione di script nella stringa di query (pseudo-regola)
  • Condizione: Se QUERY_STRING contiene schemi come “<script” (non sensibile al maiuscolo) OPPURE codifiche comuni di “<script”
  • Azione: Restituisci un 403 e registra l'evento
• Non consentire attributi di gestore eventi sospetti nelle stringhe di query
  • Condizione: Se QUERY_STRING contiene “onload=” OPPURE “onclick=” OPPURE “onerror=” (in forme codificate)
  • Azione: Sfida con CAPTCHA o blocca
• Prevenire payload riflessi nelle risposte tramite ispezione della risposta (avanzato)
  • Condizione: Se l'input dalla stringa di query è ripetuto parola per parola nell'output E l'input ripetuto contiene token JS sospetti
  • Azione: Blocca la richiesta e notifica l'amministratore
• Limita il tasso delle richieste che includono caratteri sospetti o stringhe di query molto lunghe
  • Condizione: Lunghezza URI della richiesta > X e contiene caratteri come “”
  • Azione: Limitare o bloccare

Se hai bisogno di assistenza nell'implementare regole per NGINX, Apache o WAF cloud, il nostro team di servizi professionali può aiutarti a garantire che le regole siano sicure e a evitare di interrompere funzionalità legittime.

---

Guida per sviluppatori: come codificare in modo difensivo per prevenire XSS

Se sviluppi plugin per WordPress o lavori con autori di plugin di terze parti, segui questi schemi di codifica sicura:

1. Escape all'output, non all'input
   • Sanitizza i dati in arrivo, ma applica funzioni di escape quando inserisci in HTML:
     • Corpo/testo HTML: esc_html()
     • Attributi HTML: esc_attr()
     • URL: esc_url()
     • HTML limitato fidato: wp_kses() con una lista di autorizzazione rigorosa
2. Preferisci la convalida rigorosa
   • Se un parametro deve essere un intero, converti in (int) o usa absint().
   • Per gli slug o i valori enumerati, controlla contro una lista di autorizzazione.
3. Non echo mai testo fornito dall'utente in contesto JavaScript
   • Se devi passare valori lato server in JS, usa wp_localize_script() O json_encode+esc_js().
4. Usa nonce per azioni basate su moduli
   • Per qualsiasi azione che cambia stato, verifica il nonce con check_admin_referer() O controlla_referenzia_ajax().
5. Evita di riflettere l'input dell'utente nelle pagine a meno che non sia convalidato e sfuggito
   • Controlla attentamente tutti i codici brevi, i gestori AJAX, i modelli basati su query e l'output dei widget.
6. Revisioni del codice e test di sicurezza
   • Includi analisi statica e dinamica nel tuo pipeline CI/CD.
   • Esegui revisioni manuali del codice e test di penetrazione focalizzati sulla sanificazione dell'input/output.

---

Linee guida per la comunicazione per i proprietari del sito (come informare i tuoi clienti)

• Sii trasparente ma evita il panico: conferma che stai applicando misure di sicurezza e che i dati dei clienti sono al sicuro (se vero).
• Offri tempistiche chiare: quando ripristinerai la piena funzionalità e come stai migliorando le protezioni.
• Fornisci un percorso di contatto per i clienti: un'email di sicurezza o un canale di supporto.
• Se si sospetta un'esposizione dei dati, seguire le leggi applicabili sulla divulgazione degli incidenti e notificare gli utenti interessati.

---

Cronologia e attribuzione (informazioni divulgate pubblicamente)

• La vulnerabilità è stata originariamente segnalata ai ricercatori in archivio (segnalata il 26 agosto 2025).
• La divulgazione pubblica con avviso (inclusi CVE‑2026‑28108 e CVSS 7.1) è avvenuta il 26 febbraio 2026.
• Al momento della scrittura, non era disponibile alcuna patch ufficiale da parte dell'autore del plugin per le versioni <= 3.8. (Se è stata rilasciata una patch da allora, dovresti aggiornare immediatamente.)

---

Suggerimenti aggiuntivi per il rafforzamento oltre a questo incidente

• Implementa l'autenticazione a due fattori per tutti gli account di livello amministrativo.
• Limitare l'accesso admin per IP dove pratico.
• Forza backup regolari archiviati offsite e testa le procedure di ripristino.
• Usa il principio del minimo privilegio: limita i diritti di installazione di plugin/temi a specifici account.
• Mantieni aggiornati PHP, pacchetti del server e configurazioni TLS.
• Implementa scansioni automatiche (controlli di integrità dei file, scansione malware) e monitora gli avvisi.

---

Se il tuo sito è già compromesso: lista di controllo per la rimediazione

1. Metti il sito in modalità manutenzione per fermare il danno ai visitatori.
2. Fai uno snapshot dei file + DB per scopi forensi.
3. Sostituisci i file compromessi con una fonte pulita o ripristina un backup pulito.
4. Sostituisci tutte le credenziali: utenti WordPress con ruoli di amministratore, pannello di controllo dell'hosting, database e qualsiasi chiave API.
5. Riesamina e conferma che tutti gli hack siano rimossi; in caso di dubbi, coinvolgi un servizio professionale di pulizia.
6. Dopo la pulizia, riattiva le protezioni e monitora per reinfezioni.

Se sei in un piano di supporto a pagamento con WP‑Firewall, i nostri esperti di rimediazione possono assisterti nella pulizia e nel recupero e aiutarti a rafforzare il sito per prevenire ricorrenze.

---

Come questo si riflette sugli autori di plugin e sull'ecosistema

Questo incidente è un promemoria di alcuni punti sistemici:

• Gli sviluppatori di plugin devono trattare l'input controllato dall'utente come potenzialmente ostile e convalidare/evitare di conseguenza.
• I proprietari dei siti dovrebbero preferire plugin attivamente mantenuti con un chiaro storico di sicurezza.
• Un WAF ben gestito e una capacità di patching virtuale sono inestimabili per proteggere i siti live fino a quando le patch del fornitore non vengono applicate.

In qualità di fornitore di sicurezza e praticante di WordPress, continueremo a lavorare con sviluppatori e host per accelerare la divulgazione responsabile e proteggere i siti ovunque.

---

Ricerca delle minacce: query e log di esempio da controllare (fai questo in modo sicuro)

• Cerca nei log del server web caratteri codificati sospetti:
  • Cerca richieste contenenti %3Cscript O script%3E nella stringa di query.
• Cerca nel database e nei contenuti tag sospetti:
  • Query wp_posts: SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' LIMIT 100;
• Controlla l'attività recente dell'amministratore per accessi sconosciuti:
  • Controlla wp_users per account recentemente creati o cambiamenti nei ruoli.

Nota: Esegui sempre indagini su una copia o uno snapshot per evitare di modificare accidentalmente le prove forensi.

---

Perché dovresti considerare la protezione WP‑Firewall ora

Abbiamo messo insieme patching virtuale e monitoraggio specificamente per proteggere i clienti da questa classe di vulnerabilità XSS riflesse. Le nostre protezioni sono progettate per essere non invasive, evitando falsi positivi mentre prevengono modelli di sfruttamento noti.

• Un firewall gestito con regole di patching virtuale tempestive riduce il tempo tra la divulgazione pubblica e la patch del fornitore.
• La scansione continua ti avvisa proattivamente di contenuti sospetti e codice iniettato.
• Per i clienti dei livelli superiori, forniamo assistenza automatica per la pulizia, report mensili e consulenza sulla sicurezza.

---

Proteggi il tuo sito oggi — Inizia con il piano gratuito WP‑Firewall

Comprendiamo che molti proprietari di siti vogliono una protezione immediata senza costi. Il nostro piano Basic (Gratuito) ti offre difese essenziali che puoi attivare in pochi minuti:

• Protezione essenziale: firewall gestito e WAF
• Larghezza di banda illimitata attraverso il nostro edge di protezione
• Scanner malware per rilevare minacce conosciute e cambiamenti sospetti
• Regole di mitigazione per i rischi OWASP Top 10, comprese le classi XSS
• Un pannello di controllo semplice per visualizzare e applicare le protezioni

Iscriviti al piano gratuito e attiva immediatamente le regole di mitigazione delle vulnerabilità: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Nota: per i team che desiderano una remediation automatizzata, liste di autorizzazione/blacklist IP e assistenza dedicata, i nostri livelli Standard e Pro a pagamento offrono funzionalità avanzate e supporto pratico.)

---

Note di chiusura dal team di sicurezza WP‑Firewall

Le vulnerabilità XSS riflesse rimangono una delle vulnerabilità web più comuni e impattanti perché sono flessibili e facili da sfruttare per gli attaccanti tramite ingegneria sociale (URL creati, phishing). Nel mondo di WordPress, l'output dei plugin e i componenti frontend sono fonti comuni di rischio — ed è per questo che una difesa a strati (codifica sicura, scansione, WAF/patching virtuale e monitoraggio) è essenziale.

Se utilizzi il plugin vulnerabile e non puoi aggiornare immediatamente, segui la sezione Mitigazione Immediata sopra. Se sei uno sviluppatore, ti preghiamo di rivedere i tuoi schemi di escaping e validazione dell'output. Se sei un proprietario di sito e hai bisogno di aiuto, il nostro team è disponibile per assisterti con il deployment di patch virtuali, scansione e remediation.

Rimani al sicuro e proattivo — e se desideri che il nostro team esamini la tua istanza o applichi una patch virtuale per CVE‑2026‑28108, iscriviti al piano gratuito (link sopra) e apri un ticket di supporto — ci penseremo noi.

— Team di sicurezza WP-Firewall

---

Riferimenti e risorse

• CVE‑2026‑28108 (avviso pubblico)
• Linee guida e difese OWASP XSS
• Manuale per sviluppatori WordPress: Funzioni di validazione e escaping dei dati

(Abbiamo deliberatamente omesso dettagli diretti sugli exploit per evitare di condividere artefatti di attacco utilizzabili. Se sei un ricercatore di sicurezza o un autore di plugin e hai bisogno di dettagli tecnici di riproduzione per il patching, ti preghiamo di contattare il nostro team di sicurezza tramite il portale di supporto.)