Nome del plugin	Prenotazione Hydra
Tipo di vulnerabilità	Vulnerabilità del controllo degli accessi
Numero CVE	CVE-2026-42675
Urgenza	Alto
Data di pubblicazione CVE	2026-05-17
URL di origine	CVE-2026-42675

Urgente: Controllo degli accessi compromesso (CVE-2026-42675) nel plugin Hydra Booking (<= 1.1.41) — Cosa devono fare ora i proprietari di siti WordPress

Riepilogo: Una vulnerabilità di controllo degli accessi compromesso nel plugin WordPress Hydra Booking (versioni <= 1.1.41, CVE-2026-42675) consente agli utenti non autenticati di eseguire azioni che dovrebbero essere limitate. Questo è un problema di alta gravità (CVSS 7.3). Se gestisci Hydra Booking su qualsiasi sito WordPress, dai priorità alla patch per la versione 1.1.42 o successiva. Se non puoi aggiornare immediatamente, applica patch virtuali con il tuo Web Application Firewall (WAF), restringi l'accesso agli endpoint relativi al plugin e segui i passaggi di risposta all'incidente qui sotto.

---

Sommario

• Cosa è successo (linguaggio semplice)
• Riepilogo tecnico della vulnerabilità
• Perché questo è pericoloso (scenari di attacco nel mondo reale)
• Chi è interessato
• Azioni immediate (passo dopo passo)
• Come patchare in sicurezza (aggiornamento del plugin e verifica)
• Patch virtuali con WP-Firewall (regole WAF consigliate)
• Rilevamento: indicatori e controlli dei log
• Risposta agli incidenti: cosa fare se sospetti un compromesso
• Indurimento e monitoraggio a lungo termine
• Domande frequenti (FAQ)
• Ottieni protezione gratuita immediata con WP-Firewall
• Note finali e risorse

---

Cosa è successo (linguaggio semplice)

È stata scoperta una vulnerabilità di controllo degli accessi compromesso nel plugin WordPress Hydra Booking (tutte le versioni fino e comprese 1.1.41). In breve: alcune funzionalità che avrebbero dovuto richiedere autenticazione e autorizzazione non controllavano correttamente tali permessi, consentendo ai visitatori non autenticati di attivare azioni destinate solo agli utenti autorizzati. Il fornitore ha rilasciato una correzione nella versione 1.1.42.

I problemi di controllo degli accessi compromesso sono particolarmente pericolosi perché consentono agli attaccanti di elevare i privilegi, modificare le impostazioni/dati del sito o eseguire azioni amministrative senza bisogno di accedere. Gli attaccanti spesso automatizzano lo sfruttamento contro siti vulnerabili, il che può portare a campagne di compromesso di massa.

---

Riepilogo tecnico della vulnerabilità

• Software interessato: Plugin WordPress Hydra Booking
• Versioni interessate: <= 1.1.41
• Corretto in: 1.1.42
• Identificatore CVE: CVE-2026-42675
• Classificazione: Controllo degli accessi compromesso / mancanza di controlli di capacità o nonce
• Gravità: Alto (CVSS 7.3)
• Privilegio richiesto per sfruttare: Nessuno — gli attaccanti non autenticati possono attivare l'azione vulnerabile/i

Sebbene i dettagli completi dell'exploit POC non siano pubblicati in questo avviso, il problema principale è che il plugin espone funzionalità (ad esempio, tramite endpoint AJAX o simili a REST) che manca di una corretta autenticazione/autorizzazione e/o verifica del nonce. Un attaccante può chiamare questi endpoint e causare l'esecuzione di comportamenti privilegiati (modifica dei dati, cambiamenti di configurazione o azioni riservate agli amministratori).

Nota: Evitiamo intenzionalmente di condividere payload di exploit specifici o firme di endpoint che potrebbero aiutare gli attaccanti. Invece, qui sotto forniamo strategie di mitigazione sicure e praticabili e concetti di regole WAF che puoi applicare immediatamente.

---

Perché questo è pericoloso — scenari di attacco nel mondo reale

Il controllo degli accessi compromesso è una delle debolezze più comunemente sfruttate sui siti WordPress, perché spesso consente:

• Creare o modificare contenuti (prenotazioni false, appuntamenti) che possono essere utilizzati per ingegneria sociale o diversione.
• Aggiungere opzioni a livello amministrativo o iniettare impostazioni dannose che abilitano l'esecuzione remota di codice in seguito.
• Esportare o eliminare dati, potenzialmente esponendo informazioni sui clienti o rimuovendo registri e prove.
• Attivare attività in background o operazioni simili a cron per eseguire azioni dannose arbitrarie o concatenate.
• Bypassare completamente l'autenticazione, consentendo agli attaccanti di piantare backdoor, creare utenti amministratori aggiuntivi o caricare malware.

Poiché la vulnerabilità è non autenticata, gli attaccanti possono scansionare Internet alla ricerca di siti con il plugin vulnerabile e tentare sfruttamenti automatizzati. Ciò rende essenziale una rapida mitigazione.

---

Chi è interessato

• Qualsiasi sito WordPress con il plugin Hydra Booking installato nella versione 1.1.41 o precedente.
• Siti che utilizzano il plugin ma senza aggiornamenti attivi o quelli che hanno disabilitato gli aggiornamenti automatici.
• Installazioni multisito che utilizzano il plugin a livello di rete (raggio d'azione maggiore).
• Siti che combinano questo plugin con altri componenti vulnerabili — attacchi concatenati sono comuni.

Se non sei sicuro se il tuo sito utilizza Hydra Booking, controlla la schermata dei Plugin in wp-admin o scansiona il tuo codice sorgente per una cartella chiamata simile a idra-prenotazione sotto wp-content/plugins/.

---

Azioni immediate — cosa fare nei prossimi 60 minuti

1. Controllare la versione del plugin:
   Accedi all'amministratore di WordPress → Plugin → Plugin installati → cerca Hydra Booking e annota la versione installata.
2. Se il plugin è installato e ≤ 1.1.41 — aggiorna immediatamente a 1.1.42 o successivo:
   Se puoi eseguire un aggiornamento normale del plugin tramite wp-admin, fallo ora.
   Se gli aggiornamenti automatici sono abilitati, verifica che il plugin sia stato aggiornato con successo.
   Se l'aggiornamento è bloccato o non puoi accedere a wp-admin, procedi al Passo 4.
3. Se non puoi aggiornare immediatamente, abilita la patch virtuale tramite il tuo WAF:
   Distribuisci regole WAF che mirano agli endpoint del plugin e assicurati che richiedano intestazioni di autenticazione/nonce/riferimento valide. Esempi e regole raccomandate sono di seguito.
4. Riduci temporaneamente la superficie di attacco:
   Disabilita l'accesso pubblico agli endpoint di prenotazione se possibile (modalità manutenzione, lista di autorizzazione IP).
   Disattiva il plugin tramite wp-admin se sicuro (nota: disattivare potrebbe interrompere le funzionalità del sito).
   Se non puoi accedere a wp-admin, rinomina la directory del plugin tramite SFTP/SSH (ad esempio, rinomina idra-prenotazione A disabilita-hydra-booking) — questo disattiva il codice del plugin.
5. Fai un backup fresco:
   Se possibile, crea un backup completo (file + database) prima di applicare correzioni o ulteriori rimedi. Conservalo offline.
6. Controlla gli indicatori di compromissione (IoCs) e attività sospette nei log (istruzioni di seguito).
7. Se rilevi una compromissione, segui la checklist di risposta agli incidenti in questo post.

---

Come applicare la patch in modo sicuro (aggiornamento del plugin e convalida)

1. Aggiorna tramite wp-admin (consigliato)
   Dashboard → Plugin → fai clic su “Aggiorna ora” per Hydra Booking.
   Dopo l'aggiornamento, svuota la cache degli oggetti e qualsiasi cache del server (Redis, Memcached) e cache CDN.
2. Aggiorna manualmente (quando wp-admin non è disponibile)
   Scarica la versione 1.1.42 (o successiva) dalla fonte ufficiale del plugin.
   Carica il plugin tramite SFTP in una directory temporanea e sostituisci i file esistenti, oppure utilizza la funzione di caricamento del plugin.
   Assicurati che i permessi dei file siano corretti (tipicamente 644 per i file, 755 per le cartelle).
3. Valida l'aggiornamento
   Controlla la pagina del plugin in wp-admin per confermare che la nuova versione sia attiva.
   Rivedi il changelog del plugin e conferma che la nota di correzione sia presente.
   Testa i flussi di prenotazione core in un ambiente di staging prima di applicarli in produzione, se possibile.
4. Controlli post-aggiornamento.
   Verifica che non siano stati aggiunti nuovi utenti admin.
   Rivedi i file modificati di recente (ci si aspetta che la freschezza dei file nella directory del plugin sia aggiornata dopo l'aggiornamento).
   Verifica gli eventi programmati e i cron job (usa WP-CLI: elenco eventi cron wp).
   Esegui una scansione malware e un controllo dell'integrità dei file.

---

Patching virtuale con WP-Firewall — regole WAF consigliate

Se non puoi aggiornare immediatamente, il modo più veloce per ridurre il rischio è il patching virtuale — implementa regole WAF che bloccano i tentativi di sfruttamento della funzionalità vulnerabile. Di seguito sono riportati concetti pratici di regole WAF da implementare utilizzando WP-Firewall o WAF equivalenti.

Importante: NON applicare ciecamente regole che bloccano il traffico legittimo senza testare. Usa controlli positivi (richiedi token validi) e soglie di blocco sicure.

1. Blocca POST sospetti non autenticati agli endpoint AJAX admin
   Motivazione: Molti plugin di WordPress espongono funzionalità tramite admin-ajax.php. Se un'azione deve essere autenticata, richiedi un nonce valido o X-WP-Nonce.
   Regola (concettuale):
   • SE il metodo di richiesta è POST
   • E l'URI della richiesta contiene /wp-admin/admin-ajax.php
   • 5. Di seguito sono riportate regole pratiche del firewall ed esempi che tu (o il tuo team di hosting/sicurezza) puoi applicare. Queste sono intenzionalmente generiche — dovresti ispezionare il plugin per raccogliere i nomi esatti dei parametri e adattare le regole al tuo ambiente. azione il parametro corrisponde ad azioni specifiche del plugin (ad es., inizia con idra_ O hb_) — puoi scoprire i nomi delle azioni specifiche del plugin ispezionando il codice sorgente del plugin o monitorando il traffico
   • E nessun header nonce valido (X-WP-Nonce) e nessun valido _wpnonce parametro presente
   • ALLORA blocca o sfida (captcha) la richiesta.
2. Blocca gli endpoint REST per il plugin (se presenti)
   Molti plugin registrano percorsi REST sotto spazi dei nomi prevedibili. Limita l'accesso ai percorsi REST introdotti dal plugin agli utenti autenticati e/o a ruoli specifici.
   Regola (concettuale):
   • SE l'URI della richiesta corrisponde /wp-json/hydra-booking/* o simili
   • E la richiesta non è autenticata
   • ALLORA blocca o richiedi un token di autenticazione.
3. Richiedi controlli Referer/Origin + Nonce su azioni critiche
   Regola:
   • SE la richiesta include un'azione sensibile (crea/aggiorna/elimina)
   • E l'intestazione Referer o Origin è mancante o non corrisponde al tuo sito
   • ALLORA blocca.
4. Limita la velocità e sfida gli IP sospetti
   Applica limiti di velocità più severi sugli endpoint che dovrebbero essere utilizzati solo da client autenticati.
   Aggiungi un limite di velocità temporaneo alle richieste POST agli endpoint di prenotazione per rallentare la scansione/sfruttamento.
5. Blocca indicatori di sfruttamento noti nei payload
   Se osservi specifici modelli di payload associati allo sfruttamento (ad es., nomi dei campi, stringhe di comando), crea regole basate su lunghezza del contenuto o regex per bloccare quei modelli.
   Usa cautela — evita regex ampie che causano falsi positivi.
6. Geo o IP allowlisting per azioni amministrative
   Se gli utenti amministrativi provengono da intervalli IP di uffici noti, limita gli endpoint AJAX admin a quegli IP.
7. Negare temporaneamente l'accesso diretto ai file del plugin
   Se il plugin utilizza un file front-end come booking-handler.php, blocca l'accesso diretto a quel file tranne che per utenti autenticati o referenti interni.
8. Esempio di patch virtuale (regola pseudo-WAF)
   • Corrispondenza: REQUEST_URI CONTIENE /wp-admin/admin-ajax.php
   • E: REQUEST_METHOD == POST
   • E: RICHIESTA_CORPO AZIONE == (hydra_booking_create|hydra_booking_update|hydra_booking_setting_save) (sostituire con azioni reali)
   • E: (X-WP-Nonce NON PRESENTE O NONCE NON VALIDO) O HTTP_REFERER NON CORRISPONDE A SITE_DOMAIN
   • Azione: BLOCCA e REGISTRA

Se hai bisogno di aiuto immediato per implementare queste regole, le politiche gestite di WP-Firewall possono essere attivate per proteggere gli endpoint e bloccare i tentativi di sfruttamento mentre aggiorni.

---

Rilevamento: indicatori e controlli dei log

Controlla i seguenti elementi nei log del server, nei log di WordPress e nei log specifici del plugin:

• Richieste POST o GET inaspettate a admin-ajax.php O /wp-json/* che includono nomi di azioni specifiche del plugin.
• Richieste con intestazioni Referer insolite o vuote che mirano agli endpoint del plugin.
• Aumento improvviso di errori 4xx o 5xx legati agli endpoint del plugin.
• Creazione di nuovi utenti admin o modifiche ai ruoli degli utenti admin esistenti.
• File core di WordPress modificati o file di plugin/tema al di fuori di una finestra di aggiornamento.
• Righe del database aggiunte/aggiornate nelle tabelle del plugin in orari insoliti (ad es., prenotazioni o impostazioni sospette).
• Presenza di voci WP-Cron sospette che non sono state programmate dagli admin.
• Tentativi di accesso da nuovi IP seguiti da azioni admin.
• Caricamenti di file a wp-content/caricamenti o altre directory con nomi di file insoliti o diritti di esecuzione.

Strumenti da utilizzare:

• Log di accesso al server (Apache/Nginx)
• WordPress debug.log (abilita temporaneamente in il file wp-config.php)
• WP-CLI per controlli su file e utenti
• Scanner di malware (scansione basata su file)
• Query del database per rivedere le modifiche recenti nelle tabelle dei plugin

Esempi di controlli WP-CLI:

• Elenca le modifiche recenti ai file: trova wp-content/plugins/hydra-booking -type f -mtime -7 -ls
• Controlla gli utenti admin creati di recente:
  • wp user list --role=administrator --format=csv
  • wp user get 1 --field=user_registered (sostituisci con gli ID utente)
• Ispeziona gli eventi cron attivi: wp cron event list --due-now

---

Risposta agli incidenti — se sospetti un compromesso

Se rilevi segni di sfruttamento o credi che il sito sia compromesso, segui immediatamente questi passaggi:

1. Isolare il sito
   Porta il sito offline (pagina di manutenzione) o limita l'accesso per IP se possibile. Se hai bisogno di presenza pubblica, considera di disabilitare temporaneamente solo il plugin vulnerabile.
2. Preservare le prove
   Esporta i log, un'istantanea del database e lo stato del server per analisi forensi.
   Non sovrascrivere i log; copiali in uno spazio di archiviazione sicuro.
3. Copia i log web e di sistema in un luogo sicuro.
   Forza il reset delle password per tutti gli utenti admin.
   Ruota immediatamente le chiavi API, le credenziali del database (se possibile) e qualsiasi integrazione di terze parti.
   Revoca e ricrea qualsiasi credenziale compromessa.
4. Scansiona e pulisci
   Esegui una scansione approfondita del malware su tutto il filesystem e il database.
   Cerca web shell, file di core modificati e codice PHP sospetto.
   Rimuovi i file dannosi o ripristina un backup pulito.
5. Ripristina da un backup pulito (se disponibile)
   Preferisci un backup precedente alla compromissione con integrità confermata.
   Dopo il ripristino, applica l'aggiornamento del plugin e la patch virtuale prima di riportare il sito online.
6. Applica patch e indurimento
   Aggiorna il plugin Hydra Booking alla versione 1.1.42 o successiva (obbligatorio).
   Aggiorna tutti i plugin, i temi e il core di WordPress.
   Applica le regole WAF e aumenta il monitoraggio.
7. Rivedi l'accesso e i log dopo il ripristino.
   Conferma che non rimangano backdoor, cron job o attività pianificate.
   Monitora i log per almeno 30 giorni per attività sospette.
8. Considera un aiuto professionale
   Se la violazione è significativa (esfiltrazione di dati, backdoor persistenti), collabora con uno specialista di risposta agli incidenti.

---

Indurimento e monitoraggio a lungo termine

• Mantieni aggiornato il core di WordPress, i plugin e i temi. Abilita gli aggiornamenti minori automatici; considera gli aggiornamenti automatici per i plugin critici dove è sicuro.
• Limita l'uso dei plugin: rimuovi i plugin e i temi non utilizzati. Ogni plugin aumenta la tua superficie di attacco.
• Usa il principio del minimo privilegio per i ruoli utente. Gli account admin dovrebbero essere utilizzati con parsimonia.
• Imposta password forti e abilita l'autenticazione a due fattori (2FA) per tutti gli utenti amministrativi.
• Disabilita la modifica dei file all'interno di wp-admin impostando. define('DISALLOW_FILE_EDIT', true); In il file wp-config.php.
• Implementa il monitoraggio dell'integrità dei file e scansioni periodiche per malware.
• Configura permessi di file sicuri (file 644, directory 755).
• Proteggi wp-admin con l'allowlisting IP o l'autenticazione HTTP dove possibile.
• Mantieni backup regolari e testati archiviati off-site.
• Monitora il traffico e i log di errore con avvisi automatici per anomalie.
• Usa un WAF per fornire patch virtuali per vulnerabilità zero-day mentre aggiorni.

---

Come WP-Firewall protegge il tuo sito contro questa vulnerabilità.

Come fornitore di firewall focalizzato su WordPress, WP-Firewall offre protezione a più livelli che ti aiuta a ridurre immediatamente il rischio da problemi di controllo degli accessi interrotti come CVE-2026-42675:

• Regole WAF gestite ottimizzate per gli endpoint dei plugin di WordPress per bloccare tentativi non autenticati preservando la funzionalità legittima del sito.
• Regole di validazione nonce e sessione per negare le richieste mancanti delle intestazioni WordPress attese.
• Limitazione della velocità e difese contro i bot per rallentare o fermare la scansione di massa e lo sfruttamento automatizzato.
• Patching virtuale (mitigazione rapida) che può essere distribuito istantaneamente su siti protetti, guadagnandoti tempo per eseguire aggiornamenti.
• Monitoraggio dell'integrità dei file e scansioni programmate per malware per individuare cambiamenti sospetti.
• Registrazione dettagliata e avvisi per le richieste in arrivo agli endpoint relativi ai plugin, in modo da poter rilevare tentativi e indagare.

Se stai già utilizzando WP-Firewall, abilita la nostra mitigazione gestita per le vulnerabilità dei plugin e mantieni il monitoraggio attivo fino a quando ogni sito non è aggiornato.

---

Esempi di rilevamento e regole WAF (codice sicuro, non sfruttabile)

Di seguito sono riportati concetti di esempio che puoi tradurre direttamente in regole WP-Firewall o in altri strumenti WAF. Questi sono pseudocodici e richiedono adattamenti al tuo ambiente.

1. Blocca le azioni del plugin admin-ajax non autenticate

   SE REQUEST_URI CONTIENE "/wp-admin/admin-ajax.php" E REQUEST_METHOD == "POST" E PARAM action IN ["hydra_booking_create","hydra_booking_update","hydra_booking_save_settings"]  # Sostituisci con azioni reali se conosciute E (HTTP_X_WP_NONCE MANCANTE O HTTP_REFERER NON CONTIENE "yourdomain.com") ALLORA AZIONE BLOCCA REGISTRA

2. Proteggere gli endpoint REST

   SE REQUEST_URI CORRISPONDE "^/wp-json/hydra-booking/.*" E USER_AUTHENTICATED == FALSE ALLORA SFIDA (captcha) O BLOCCA

3. Limita la velocità delle POST agli endpoint dei plugin

   SE REQUEST_URI CONTIENE "hydra-booking" E REQUEST_METHOD == "POST" ALLORA LIMITA 10 richieste al minuto per IP; supera -> 403 per 10 minuti

4. Sfida il referer mancante per azioni sensibili

   SE REQUEST_METHOD IN ["POST","PUT","DELETE"] E NON HTTP_REFERER CONTIENE "yourdomain.com" E REQUEST_URI CONTIENE "hydra-booking" ALLORA SFIDA CAPTCHA O BLOCCA

Nota: Sostituisci yourdomain.com e nomi delle azioni con il tuo dominio effettivo e nomi delle azioni del plugin verificati. Testa sempre le regole in modalità solo monitoraggio per ridurre al minimo i falsi positivi.

---

Domande frequenti (FAQ)

D: Ho aggiornato il plugin — ho ancora bisogno delle protezioni WAF?

R: Sì. Mantenere il software aggiornato è fondamentale, ma i WAF forniscono uno strato di difesa aggiuntivo: patching virtuale per correzioni sconosciute o ritardate, protezione contro attacchi concatenati e mitigazione dei tentativi di sfruttamento delle vulnerabilità.

D: Il mio sito è stato offline durante la finestra di vulnerabilità. Questo significa che sono al sicuro?

R: I siti offline non sono raggiungibili, quindi non possono essere sfruttati. Se hai ripristinato da un backup o spostato il sito online successivamente, assicurati che il plugin sia stato aggiornato prima della ri-esposizione.

D: Posso rinominare in sicurezza la cartella del plugin per disabilitarlo?

A: Sì — rinominare la directory del plugin (tramite SFTP/SSH) disattiverà il plugin e rimuoverà i suoi hook. Tuttavia, questo potrebbe compromettere la funzionalità del sito. Fai sempre dei backup prima di apportare modifiche e testa su staging quando possibile.

Q: Cosa succede se non posso aggiornare perché la versione patchata rompe le funzionalità?

A: Se il plugin aggiornato causa problemi, torna a un backup pulito mentre coordini con lo sviluppatore del plugin e WP-Firewall può applicare patch virtuali per ridurre il rischio immediato.

---

Ottieni protezione gratuita immediata con WP-Firewall

Proteggi il tuo sito ora — Inizia con il piano gratuito di WP-Firewall

Se sei preoccupato per questa vulnerabilità o vuoi un modo veloce per proteggere il tuo sito WordPress mentre aggiorni i plugin, considera il piano Base (Gratuito) di WP-Firewall. Include protezioni essenziali come un firewall gestito, larghezza di banda illimitata, regole WAF, scansione malware e mitigazione contro le minacce OWASP Top 10 — tutto ciò di cui hai bisogno per ridurre rapidamente il rischio senza costi iniziali. Aggiorna in qualsiasi momento per la rimozione automatizzata del malware, gestione degli IP, patching virtuale proattivo delle vulnerabilità e supporto premium. Inizia a proteggere il tuo sito ora: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Piani a colpo d'occhio:

• Base (gratuito): firewall gestito, larghezza di banda illimitata, WAF, scanner di malware, mitigazione OWASP Top 10.
• Standard ($50/anno): tutto in Base più rimozione automatica del malware e controlli blacklist/whitelist IP.
• Pro ($299/anno): tutto in Standard più report di sicurezza mensili, patching virtuale automatico e servizi gestiti premium.

---

Note finali e risorse

Le vulnerabilità di controllo degli accessi compromesso come questa sono una causa ricorrente di compromissione del sito perché a volte passano inosservate agli autori dei plugin e sono facili da sfruttare. Le tre azioni chiave da intraprendere ora sono:

1. Verifica se il plugin Hydra Booking è presente e la sua versione.
2. Aggiorna alla versione 1.1.42 o successiva immediatamente.
3. Se non puoi aggiornare subito, utilizza WP-Firewall (o un altro WAF capace) per distribuire patch virtuali e bloccare l'accesso non autenticato agli endpoint del plugin.

Se hai bisogno di assistenza pratica, il nostro team di WP-Firewall può aiutarti a valutare i siti interessati, distribuire rapidamente patch virtuali e guidarti nel recupero e nel rafforzamento. Dai priorità al patching e al monitoraggio — la velocità conta. Gli attaccanti eseguono scansioni continuamente e la finestra tra divulgazione e sfruttamento è spesso misurata in ore.

Se desideri un elenco di controllo che puoi utilizzare subito, ecco un elenco minimo immediato:

• ☐ È installato Hydra Booking? (Sì / No)
• ☐ Se sì, la versione è ≤ 1.1.41? (Sì → aggiorna immediatamente)
• ☐ Esegui il backup dei file e del database
• ☐ Aggiorna il plugin a 1.1.42 o successivo
• ☐ Distribuisci regole WAF per bloccare l'accesso non autenticato agli endpoint del plugin
• ☐ Scansiona per indicatori di compromissione (nuovi utenti, file modificati, cron job sospetti)
• ☐ Ruota le password di amministrazione e le chiavi API se si sospetta una compromissione

Rimani al sicuro, rimani vigile e contatta se hai bisogno di assistenza nell'implementazione delle regole WAF o nella conduzione di un'indagine su compromissioni.