Nome del plugin	Riaxe Product Customizer
Tipo di vulnerabilità	Iniezione SQL
Numero CVE	CVE-2026-3599
Urgenza	Alto
Data di pubblicazione CVE	2026-04-16
URL di origine	CVE-2026-3599

Iniezione SQL non autenticata nel Riaxe Product Customizer (<= 2.1.2) — Cosa devono sapere i proprietari dei siti e come WP‑Firewall protegge i tuoi siti

Un'analisi tecnica approfondita della recente iniezione SQL non autenticata (CVE-2026-3599) che colpisce il plugin Riaxe Product Customizer, come gli attaccanti possono sfruttarla, passi immediati di mitigazione, guida alla rilevazione e risposta agli incidenti, e come il WAF gestito di WP‑Firewall e la patch virtuale possono proteggere i siti ora.

Pubblicato il: 2026-04-16
Autore: Team di sicurezza WP-Firewall
Etichette: WordPress, Iniezione SQL, WAF, Vulnerabilità, Riaxe, WooCommerce, WP-Firewall

Nota: Questo post esamina una vulnerabilità di iniezione SQL non autenticata recentemente divulgata (CVE-2026-3599) che colpisce le versioni del Riaxe Product Customizer fino e inclusa la 2.1.2. Analizziamo il rischio, i vettori di attacco, le strategie di rilevazione e rimedio, e i passi pratici di mitigazione che puoi applicare immediatamente. Questo scritto è destinato ai proprietari dei siti, sviluppatori WordPress e professionisti della sicurezza. Omette intenzionalmente i dettagli di sfruttamento che consentirebbero una facile armamentizzazione.

Sintesi

È stata divulgata una vulnerabilità critica di iniezione SQL (CVE-2026-3599, CVSS 9.3) nel plugin Riaxe Product Customizer (versioni <= 2.1.2). Il problema consente agli attaccanti non autenticati di iniettare SQL attraverso chiavi appositamente create nella struttura product_data/options del plugin. Poiché è sfruttabile senza autenticazione, la vulnerabilità presenta un rischio grave: gli attaccanti possono leggere, modificare o eliminare dati nel tuo database WordPress, creare utenti amministrativi o ulteriormente pivotare nel sito.

Se il tuo sito utilizza il plugin Riaxe Product Customizer ed è in esecuzione su una versione colpita, trattalo come un'emergenza. Se una patch fornita dal fornitore non è ancora disponibile, devono essere applicate immediatamente le mitigazioni: disabilita o rimuovi il plugin, applica la patch virtuale WAF, rinforza l'accesso e valida il tuo sito per segni di compromissione. In questo articolo, faremo:

• Spiegare la vulnerabilità a un livello alto e il flusso di attacco tipico.
• Coprire metodi di rilevazione pratici e indicatori di compromissione (IoCs) da monitorare.
• Fornire passi immediati di rimedio e correzioni per sviluppatori.
• Mostrare esempi di regole WAF e indicazioni per la patch virtuale.
• Descrivere la risposta agli incidenti e il rinforzo post-incidente.
• Spiegare come WP‑Firewall può proteggerti oggi e dove andare dopo.

Perché questa vulnerabilità è grave

Cosa rende questa vulnerabilità particolarmente pericolosa:

• Non autenticato: Non è richiesta alcuna login valida di WordPress per attivare il problema.
• Iniezione SQL: Un attaccante può manipolare le query SQL eseguite dal plugin, portando a esfiltrazione di dati, manomissione o escalation dei privilegi.
• Superficie di attacco comune: Molti siti WooCommerce ed eCommerce utilizzano plugin di personalizzazione dei prodotti; campagne di scansione automatizzate e di sfruttamento di massa tentano rapidamente di sfruttare tali difetti.
• Potenziale per compromissioni automatizzate su larga scala: Una volta pubblicati, gli attori criminali e i bot tenteranno di sfruttare automaticamente migliaia di siti.

Date queste circostanze, una strategia di mitigazione efficace e immediata è essenziale per tutti i siti interessati.

Panoramica tecnica di alto livello (non sfruttabile)

La vulnerabilità deriva da una gestione impropria dei dati di configurazione del prodotto inviati al plugin — una struttura dati spesso chiamata product_data che contiene sottochiavi come opzioni O impostazioni. Nelle versioni interessate, il plugin deserializza o interpreta in altro modo le chiavi all'interno di questa struttura dati in un modo che consente a caratteri speciali o stringhe create nei nomi dei parametri di influenzare il SQL che il plugin costruisce o esegue.

Punti tecnici chiave (mantenuti a livello alto):

• Il vettore pericoloso è il parametro product_data (o una struttura POST/GET in arrivo con un nome simile) con chiavi annidate come opzioni.
• Piuttosto che convalidare o sanificare il parametro nomi (le chiavi), il plugin costruisce SQL utilizzando quei nomi di chiave o non riesce a trattarli in modo sicuro prima di formare le query.
• Poiché l'iniezione può verificarsi nelle chiavi dei parametri (non solo nei valori), molte protezioni standard che si concentrano sui valori sono insufficienti.
• Il risultato è un'iniezione in un'istruzione SQL eseguita tramite il livello di database di WordPress, dando a un attaccante lo stesso impatto di un classico SQLi.

Omettiamo intenzionalmente le stringhe di sfruttamento e i dettagli di riproduzione passo dopo passo per evitare di abilitare sfruttamenti automatizzati.

Chi è colpito

• I siti WordPress che hanno installato il plugin Riaxe Product Customizer e aggiornato a versioni <= 2.1.2 sono vulnerabili.
• I siti in cui il plugin è attivo sono a rischio immediato.
• Anche se un plugin è inattivo, se ha hook del database o attività pianificate che elaborano product_data dalle richieste, potrebbe essere comunque a rischio — ma le installazioni attive sono la massima priorità.

Azioni immediate per i proprietari dei siti (ordinate per priorità)

1. Conferma la presenza
     – Controlla la pagina dei plugin dell'amministratore di WordPress per “Riaxe Product Customizer” e verifica la versione installata.
2. Se il plugin è attivo e non puoi immediatamente aggiornare a una versione sicura:
     – Disattiva immediatamente il plugin. Questa è la mitigazione più veloce e affidabile.
     – Se non puoi disattivare immediatamente (ad esempio, la funzionalità del sito dipende da esso), applica le regole WAF, limita l'accesso e isola il sito (vedi i prossimi punti).
3. Se esiste una patch ufficiale da parte dell'autore del plugin:
     – Applica immediatamente l'aggiornamento. Preferisci aggiornamenti automatici solo quando hai un backup.
4. Se non è disponibile alcuna patch:
     – Rimuovi completamente il plugin, o sostituiscilo con un'alternativa sicura che fornisca funzionalità simili.
     – Applica una patch virtuale (regola WAF) per bloccare i vettori di attacco fino a quando non viene rilasciata e verificata una versione corretta del plugin.
5. Verifica il tuo sito per compromissioni (vedi Risposta agli Incidenti qui sotto).
6. Ruota le credenziali:
     – Reimposta tutte le password degli amministratori di WordPress.
     – Ruota le chiavi API e qualsiasi credenziale memorizzata in il file wp-config.php o sistemi connessi se sospetti un'esfiltrazione di dati.

Rilevamento: cosa cercare (indicatori di compromissione)

Poiché gli attaccanti potrebbero aver scansionato e cercato di sfruttare questa vulnerabilità prima della divulgazione, controlla i log e il tuo sito per segni di sfruttamento:

• Log del server web e WAF:
  • Richieste con il parametro product_data o payload POST/GET strutturati in modo simile contenenti chiavi insolite o metadati codificati. Cerca schemi anomali in ARGS e ARGS_NAMES nei log del server.
  • Richieste con nomi di parametri insoliti che contengono spazi, punteggiatura o parole chiave SQL nell'area del nome del parametro.
• Log di WordPress e modifiche al sito:
  • Nuovi account amministratori o editor inaspettati in utenti wp.
  • Modifiche a post, pagine o dati di prodotto non eseguite dal tuo team.
  • Nuovi eventi programmati (voci cron), iniezione di JavaScript malevolo nelle pagine, o file PHP non autorizzati negli upload o contenuto wp 8. location ~* ^/wp-content/uploads/.*\.(php|php5|phtml)$ {.
  • Modifiche a opzioni_wp che fanno riferimento a valori sconosciuti o anomalie nei dati serializzati.
• Comportamento del database:
  • Query inaspettate, errori nei log che puntano a SQL malformati costruiti da plugin.
  • Tabelle di database appena create o nuove voci privilegiate.
• Segnali esterni:
  • Connessioni in uscita dal tuo sito verso host sconosciuti.
  • Attività email di spam o insolita proveniente dal tuo dominio.

Esempi di query di database per indagine (solo lettura; non eseguire SQL non fidati):

• Elenca utenti e ruoli:
  SELECT ID, user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 20;
• Cerca opzioni sospette o voci serializzate (ispeziona manualmente):
  SELECT option_id, option_name FROM wp_options WHERE option_name LIKE '%riaxe%' OR option_value LIKE '%product_data%' LIMIT 50;
• Cerca file modificati di recente (tramite accesso shell):
  trova /percorso/verso/il/tuo/sito -tipo f -mtime -14 -printf '%TY-%Tm-%Td %TT %p
' | ordina -r

Esegui sempre letture forensi su backup o copie del database per evitare di disturbare prove attive.

Mitigazione immediata con regole del firewall e patch virtuali

Se non puoi aggiornare o rimuovere il plugin immediatamente, applicare una regola WAF (patch virtuale) è la soluzione temporanea più sicura. L'obiettivo è bloccare i tentativi di sfruttamento riducendo al minimo i falsi positivi.

Strategie generali di blocco raccomandate:

• Blocca le richieste in cui ARGS_NAMES (nomi dei parametri) includono parole chiave SQL o caratteri sospetti.
• Blocca le richieste POST che includono product_data e dove le chiavi annidate includono metacaratteri SQL o sequenze sospette.
• Limita o blocca gli IP che attivano richieste ripetute simili a exploit.

Esempio di regola in stile ModSecurity (concettuale — adatta alla sintassi del tuo WAF e testa per falsi positivi):

SecRule REQUEST_METHOD "POST" "fase:2,catena,nega,log,status:403,msg:'Blocca le chiavi del parametro product_data sospette',id:1001001"

Spiegazione:

• La prima regola corrisponde alle richieste POST.
• La regola concatenata ispeziona i nomi degli argomenti e i valori degli argomenti per parole chiave SQL o caratteri meta-SQL tipici nei nomi dei parametri.
• Se corrisponde, nega la richiesta (403) e registrala.

Importanti suggerimenti per la regolazione del WAF:

• Testa in modo aggressivo in modalità di rilevamento/logging per prima cosa per comprendere i modelli di traffico legittimo.
• Usa un periodo di apprendimento e inserisci nella whitelist i nomi dei parametri noti come sicuri per evitare di interrompere le azioni legittime di amministrazione o API.
• Monitora i log per falsi positivi e adatta i modelli regex di conseguenza.

Il WAF gestito di WP‑Firewall può creare e distribuire patch virtuali altamente mirate per questa specifica vulnerabilità, sintonizzate sulla firma esatta senza bloccare il traffico legittimo.

Guida per gli sviluppatori: Correzioni che gli autori dei plugin dovrebbero applicare

Se mantieni il plugin o sei uno sviluppatore a cui è stato chiesto di aiutare, queste sono le correzioni di codifica appropriate e i passaggi di indurimento:

1. Valida e sanifica i nomi dei parametri così come i valori
     – Tratta i nomi dei parametri (chiavi) come input non attendibili; convalidali rispetto a un insieme consentito e normalizzali.
     – Rimuovi o rifiuta qualsiasi chiave contenente caratteri di controllo, caratteri meta-SQL o punteggiatura inaspettata.
2. Usa query parametrizzate / $wpdb->prepare
     – Non concatenare mai input non attendibili in SQL. Usa $wpdb->prepare e passa i valori come segnaposto.
     – Esempio:
   $sql = $wpdb->prepare( "SELECT * FROM {$wpdb->prefix}table WHERE id = %d", (int) $id );
3. Evita SQL dinamico basato sui nomi dei parametri
     – Se la tua logica deve ramificarsi in base a chiavi conosciute, usa una whitelist:
   $allowed_keys = array( 'dimensione', 'colore', 'quantità' );
foreach ( $product_data as $key => $value ) {
    if ( ! in_array( $key, $allowed_keys, true ) ) {
      continue; // ignora chiavi inaspettate
    }
    // elabora il valore in modo sicuro
}
4. Usa controlli di capacità e nonce di WordPress sugli endpoint
     – Gli endpoint che modificano i dati del prodotto dovrebbero richiedere capacità appropriate e implementare nonce quando vengono chiamati tramite admin-ajax o moduli front-end.
5. Evitare valutare/unserialize su input non fidati
     – Se devi unserializzare i dati, usa alternative sicure e valida i tipi di dati e la struttura dopo la decodifica.
6. Implementa il logging e l'allerta per payload anomali
     – Registra i payload rifiutati con dettagli sufficienti per il debug ma evita di registrare l'input completo dell'utente nei log di produzione.

Lista di controllo per la risposta agli incidenti (dettagliata)

Se scopri sfruttamenti o non sei sicuro:

1. Isolare:
     – Metti il sito in modalità manutenzione o blocca temporaneamente tutto il traffico in entrata mentre indaghi.
     – Se ospitato, coordina con il tuo host per mettere offline il sito in modo elegante.
2. Conservare le prove:
     – Fai backup completi di file e snapshot del database per analisi forensi.
     – Raccogli i log del server web, i log di PHP-FPM e eventuali log di WAF.
3. Identifica indicatori di compromissione:
     – Cerca nuovi account amministratore creati in utenti wp.
     – Ispeziona wp_posts E opzioni_wp per contenuti iniettati.
     – Scansiona le directory di upload, temi e plugin per file PHP sconosciuti o web shell.
4. Rimuovi le backdoor:
     – Sostituisci i file core di WordPress con copie pulite.
     – Reinstalla plugin e temi da fonti fidate dopo la validazione.
     – Rimuovi manualmente i file iniettati, ma assicurati di comprendere l'ambito — preferisci un ripristino pulito quando possibile.
5. Ripristina e rinforza:
     – Ripristina da un backup pulito effettuato prima dell'incidente, se disponibile.
     – Ruotare le password per tutti gli account WordPress, le credenziali del database e qualsiasi integrazione esterna.
     – Aggiornare WordPress, i temi e i plugin alle ultime versioni sicure.
6. Monitorare:
     – Intensificare il monitoraggio per diverse settimane — controllare i log, il monitoraggio dell'integrità dei file e le connessioni in uscita.
7. Notificare le parti interessate se necessario:
     – Se i dati dei clienti sono stati esposti, controllare gli obblighi legali e normativi per la notifica della violazione.

Cosa evitare

• Non fare affidamento solo sull'oscurità: rinominare i file dei plugin o nascondere le pagine di amministrazione non è una soluzione adeguata per le vulnerabilità di iniezione.
• Non ritardare la riparazione perché il sito sembra “funzionante” — gli attaccanti potrebbero silenziosamente raccogliere dati o installare backdoor persistenti.
• Evitare di creare le proprie correzioni di sicurezza senza testare — regole WAF ben progettate e patch per sviluppatori dovrebbero essere validate in staging.

Come un WAF gestito come WP‑Firewall aiuta (cosa facciamo di diverso)

Come fornitore di firewall WordPress gestito, seguiamo un approccio a strati:

1. Patch virtuali rapide
     – Quando viene divulgata una vulnerabilità come CVE-2026-3599, il nostro team di ricerca sulla sicurezza crea firme mirate per bloccare il vettore di sfruttamento entro poche ore.
     – Queste firme vengono testate in un ambiente di staging per ridurre i falsi positivi, quindi vengono inserite nel nostro set di regole gestito.
2. Rilevamento consapevole del contesto
     – Analizziamo il contesto della richiesta (metodo HTTP, referrer, modelli di user agent, tasso, reputazione IP) per differenziare la scansione malevola dall'attività legittima di personalizzazione del prodotto.
3. Regolazione granulare delle regole
     – Piuttosto che un blacklisting grossolano, creiamo regole che mirano ai modelli di uso improprio specifici all'interno dei nomi dei parametri product_data e delle chiavi annidate.
     – Whitelistiamo anche i flussi di lavoro di amministrazione noti come sicuri per prevenire interruzioni.
4. Assistenza per incidenti
     – Per i clienti con piani attivi, forniamo indicazioni per la pulizia post-sfruttamento, l'ispezione del database e assistenza con i passaggi di recupero.
5. Monitoraggio e reporting continui
     – Manteniamo registri e avvisi continui per comportamenti anomali, consentendo una risposta rapida se gli attaccanti cambiano tecniche.
6. Funzionalità del servizio gestito (cosa ottieni)
     – Il nostro piano Basic (Gratuito) include un firewall gestito, larghezza di banda illimitata, WAF, scanner malware e mitigazioni per i rischi OWASP Top 10.
     – I livelli a pagamento aggiungono rimozione automatica del malware, blacklist/whitelist IP, report di sicurezza mensili, patch virtuali automatiche per vulnerabilità e supporto dedicato per i livelli superiori.

Un frammento WAF sicuro che puoi utilizzare per i test (esempio, adatta e testa in staging)

Di seguito è riportato un esempio concettuale per una regola WAF che si concentra sui nomi dei parametri. Testa sempre prima in modalità di rilevamento.

Esempio ModSecurity (concettuale):

# Rileva nomi di argomenti sospetti che includono parole chiave SQL o metacaratteri SQL"

Importante:

• Adatta i modelli di rilevamento all'uso legittimo del tuo sito.
• Aggiungi whitelist esplicite per nomi di parametri noti come sicuri e chiamate API di amministrazione.
• Inizia in modalità audit e ispeziona i registri per comportamenti attesi/falsi positivi prima di applicare il diniego.

Comunicare con il tuo host, sviluppatore o agenzia

Se utilizzi un host o uno sviluppatore esterno, condividi quanto segue:

• Nome e versione del plugin interessato (<= 2.1.2).
• Identificatore CVE: CVE-2026-3599 (per tracciamento).
• Finestra temporale in cui è stata osservata attività sospetta.
• Copie delle richieste problematiche e registri server/WAF (oscurare token/password privati).
• Chiedi all'host di abilitare temporaneamente la patch virtuale WAF e di eseguire una scansione malware a livello di file/sistema.

Prevenzione a lungo termine e igiene della sicurezza

• Mantieni aggiornati il core, i temi e i plugin di WordPress.
• Applica principi di minimo privilegio agli account utente: limita gli account admin e rivedi le assegnazioni di ruolo mensilmente.
• Rafforza l'accesso admin: limita l'accesso a wp-admin dove possibile, utilizza una forte 2FA e limita i tentativi di accesso.
• Applicare pratiche di codifica sicura per i plugin: convalida dell'input, dichiarazioni preparate e nonce.
• Mantieni backup regolari e testa le procedure di ripristino.
• Eseguire scansioni periodiche delle vulnerabilità e test di penetrazione.
• Utilizzare un WAF gestito con capacità di patch virtuale per bloccare lo sfruttamento zero-day mentre gli sviluppatori producono correzioni.

Esempio di cronologia per la remediation (piano d'azione raccomandato)

• Giorno 0 (divulgazione)
  Identificare se il plugin vulnerabile è installato e attivo.
  Se attivo, disattivare immediatamente o applicare la patch virtuale WAF.
• Giorno 1
  Se non è disponibile alcuna patch, rimuovere il plugin o sostituirlo con un'alternativa sicura.
  Se si sospetta un compromesso, avviare la risposta all'incidente e la raccolta di prove.
• Giorno 2–7
  Eseguire una scansione completa del sito e una revisione forense dei log e del database.
  Ruotare le credenziali, aggiornare i sali e indurire l'ambiente.
• Giorno 7–30
  Monitorare i log e il traffico per la riapparizione di schemi sospetti.
  Convalidare i backup e implementare un monitoraggio e un allerta più robusti.

Scenari del mondo reale: cosa fanno gli attaccanti con l'accesso SQL injection

Anche se non forniamo dettagli sugli exploit, comprendere gli obiettivi degli attaccanti aiuta a dare priorità alla risposta:

• Esfiltrazione dei dati: rubare dati dei clienti, registrazioni degli ordini o chiavi API memorizzate nel DB.
• Accesso persistente: creare un nuovo utente admin o aggiungere una backdoor tramite wp_options.
• Movimento laterale: piantare web shell o modificare il codice del plugin/tema per ottenere persistenza.
• Riscatto o estorsione: esfiltrare dati e richiedere un pagamento, o deturpare il sito.
• Avvelenamento SEO e spam: iniettare contenuti spam nascosti o reindirizzare il traffico.

Domande frequenti

Q: Il plugin è disattivato — sono ancora a rischio?
UN: I plugin disattivati sono meno suscettibili di essere invocati durante le normali operazioni del sito, ma se il plugin ha registrato endpoint REST o attività pianificate, potrebbe comunque verificarsi qualche elaborazione. In caso di dubbi, rimuovi il plugin o assicurati che i suoi endpoint siano inaccessibili.

Q: Posso fare affidamento sui backup automatici per il ripristino?
UN: I backup sono essenziali, ma assicurati che il backup sia pulito. Ripristina da un backup effettuato prima della prima attività sospetta. Dopo il ripristino, correggi la vulnerabilità e ruota le credenziali.

Q: Quanto dura la patch virtuale?
UN: Le patch virtuali rimangono efficaci fino a quando la vulnerabilità sottostante non viene risolta e il sito può aggiornarsi in sicurezza a una versione non vulnerabile. La patch virtuale è intesa come una mitigazione di emergenza, non come un sostituto delle correzioni del codice.

Come WP‑Firewall ti aiuta in questo momento

(Breve riepilogo per decisori e amministratori di siti)

• Patch virtuali rapide per firme di exploit conosciute per fermare gli attacchi sul nascere.
• Blocco consapevole del contesto sintonizzato sui modelli di WordPress per ridurre i falsi positivi.
• Monitoraggio e reporting continui in modo da poter vedere le attività di exploit tentate e le azioni difensive intraprese.
• Linee guida per la risposta agli incidenti e supporto alla rimediazione per i clienti con piani gestiti.

Proteggi il tuo sito ora con il piano gratuito di WP‑Firewall

Vuoi una protezione immediata e senza costi mentre valuti i prossimi passi? Il piano Base (Gratuito) di WP‑Firewall offre una protezione essenziale che può fermare i tentativi di sfruttamento di massa e mantenere il tuo sito più sicuro oggi:

• Protezione essenziale: firewall gestito e WAF sintonizzati per i contesti di WordPress.
• Larghezza di banda illimitata protetta attraverso il nostro WAF edge.
• Scansione malware per rilevare file e codice sospetti.
• Mitigazione per i rischi OWASP Top 10, inclusi i modelli di iniezione SQL.

Iscriviti ora al piano gratuito e ottieni una mitigazione virtuale automatica per molti modelli di exploit noti:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Se hai bisogno di ulteriore aiuto pratico, i nostri piani Standard e Pro aggiungono rimozione automatica del malware, blacklist/whitelist IP, report mensili, patch virtuali automatiche per vulnerabilità e servizi di sicurezza gestiti.

Considerazioni finali dal team di WP‑Firewall

Le vulnerabilità come quella divulgata in questo plugin Riaxe Product Customizer ci ricordano che la sicurezza di WordPress è una responsabilità dell'ecosistema: plugin, temi, host e proprietari di siti devono tutti agire. Quando viene pubblicata un'iniezione SQL critica non autenticata, il tempo è il nemico. Agire rapidamente — disattivando i plugin vulnerabili, applicando patch virtuali WAF e facendo una revisione forense accurata — riduce drasticamente la possibilità di danni a lungo termine.

Se hai bisogno di aiuto: il nostro team è disponibile per assisterti con la rilevazione, le patch virtuali e la risposta agli incidenti. Anche se sei un piccolo proprietario di sito, il piano Basic (Gratuito) fornisce una significativa prima linea di difesa mentre coordini una completa rimediazione.

Rimani vigile, valida gli aggiornamenti prima di applicarli in produzione e se il tuo flusso di lavoro richiede funzionalità del plugin simile a quella interessata, considera alternative attentamente verificate che seguono pratiche di codifica sicura.

— Team di sicurezza WP-Firewall

---

Riferimenti e ulteriori letture

• CVE: CVE-2026-3599
• Guide generali per il rafforzamento di WordPress e migliori pratiche per lo sviluppo di plugin sicuri
• OWASP Top 10 — iniezione e validazione dell'input

(Se desideri aiuto per applicare una patch virtuale o per auditare il tuo sito per indicatori di compromissione, il nostro team può guidarti attraverso i passaggi e fornire un piano di rimediazione coordinato.)