Il tuo sito hackerato? Scrivici e ce ne occupiamo noi
Se il tuo sito è stato hackerato, non cancellare ancora nulla: fai una copia di file e database, metti il sito in manutenzione, avvisa l'hosting e cambia tutte le password e le chiavi API da un computer pulito. Poi bisogna capire da dove sono entrati, ripulire o ricostruire, e aggiornare PHP, CMS e server prima di riaprire.
Vale lo stesso se il tuo fornitore ti ha avvisato di una vulnerabilità e non sai se ti riguarda. Raccontaci cosa è successo, controlliamo il server e ci occupiamo della pulizia, degli aggiornamenti e delle chiavi nuove.
Come capire se il tuo sito è stato hackerato?
Basta uno di questi segnali per controllare il server. Alcune intrusioni non si vedono da fuori: il sito si carica normalmente mentre qualcuno usa il server per inviare spam o registra quello che i tuoi clienti scrivono nei moduli.
-
Chrome o Google mostrano un avviso rosso di «sito pericoloso» o «sito ingannevole» quando si apre il tuo sito.
-
Chi arriva da Google viene reindirizzato a casinò, farmacie o pagine di spam.
-
Cerchi site:tuodominio.it e compaiono pagine che nessuno del tuo team ha creato.
-
Ci sono utenti amministratori in WordPress o in PrestaShop che non riconosci.
-
L'hosting ha sospeso l'account o ti ha scritto per malware o invio di spam.
-
Il tuo fornitore ti ha avvisato di una vulnerabilità (php2shell, una CVE di NGINX o di Node.js) e non sai se ti riguarda.
-
Le email del tuo dominio tornano indietro o finiscono nello spam dei clienti.
-
Il browser avvisa che il certificato del sito non è valido.
-
Arriva una fattura di un'API (OpenAI, Google Cloud, AWS…) molto più alta del normale: qualcuno sta usando le tue chiavi.
Sito hackerato: cosa fare nella prima ora
Questi passi valgono che tu ci scriva o no. Vanno in quest'ordine perché la copia dello stato attuale si perde appena qualcuno inizia a cancellare file.
- Non cancellare ancora nulla. Fai una copia dello stato attuale, file e database, e conservala fuori dal server. Annota l'ora e fai screenshot di quello che vedi. Quella copia serve a capire da dove sono entrati e, se sporgi denuncia, come prova.
- Proteggi i visitatori. Metti il sito in manutenzione o servi una pagina statica finché dura la pulizia. Se l'hosting ha già sospeso l'account, non chiedere la riattivazione prima che il sito sia pulito.
- Avvisa l'hosting. Ha i log di accesso del server e può vedere se anche altri siti dello stesso account sono colpiti.
- Cambia le password da un computer pulito. Pannello dell'hosting, amministratori del CMS, FTP o SFTP, SSH, database, email del dominio e registrar. Attiva la verifica in due passaggi dove possibile. Se il computer da cui gestisci il sito è infetto, anche le password nuove finiscono in mano all'attaccante.
- Revoca le chiavi API salvate nel sito. Gateway di pagamento, email transazionali, mappe, servizi di IA: genera chiavi nuove e disattiva le vecchie. Una chiave copiata continua a funzionare anche dopo aver ripulito il server.
- Controlla gli utenti amministratori. Annota nome e data di creazione di quelli che non riconosci, poi eliminali.
- Se ci sono dati personali, il tempo corre. Se il sito conserva dati dei clienti (ordini, moduli, account), un'intrusione può essere una violazione di dati personali. Con il GDPR hai 72 ore da quando ne vieni a conoscenza per notificarla all'autorità di controllo quando c'è un rischio per le persone.
Per chiedere poi la revisione a Google, il procedimento è nella guida del rapporto Problemi di sicurezza. Se la tua azienda è in Spagna, la linea 017 di INCIBE è gratuita e riservata, e l'AEPD spiega come notificare una violazione.
# Amministratori che non riconosci? (WordPress con WP-CLI)$ wp user list --role=administrator --fields=user_login,user_registered# File PHP modificati negli ultimi 7 giorni$ find . -name "*.php" -mtime -7 -type f# In uploads non dovrebbe esserci nessun .php$ find wp-content/uploads -name "*.php"# Attività pianificate che non hai creato$ crontab -lCon accesso SSH al server. Se non ce l'hai, l'hosting può darti i log di accesso e l'elenco dei file modificati.
Cosa fare se il fornitore ti avvisa di una vulnerabilità?
Verificare quale versione usi, aggiornare a quella corretta e, se la falla permetteva di eseguire codice o leggere la memoria, controllare se qualcuno è entrato prima della patch. Questi sono gli avvisi recenti che toccano più siti e server.
PHP: php2shell
CVE-2026-109618 e CVE-2026-109619, CVSS 9,2, senza autenticazione. Corrette in 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Wiz ha dimostrato l'esecuzione remota di codice contro WordPress, Drupal e Joomla.
Node.js
Dieci CVE il 21 ottobre, tra cui una scrittura fuori dai limiti nel decompressore Brotli che permette di eseguire codice. Corrette in v26.12.1, v24.22.1 e v22.23.4; la 20.x e la 25.x non ricevono più patch.
NGINX
«NGINX Rift» (CVE-2026-42945) ha avuto tentativi di sfruttamento dal 16 maggio. Il gruppo di ottobre, con request smuggling su HTTP/3 e falsificazione di sessione TLS, è corretto nella 1.31.7 e nella 1.30.6 o successive.
Certificati: GoDaddy ed eMudhra
GoDaddy ha revocato 404.607 certificati TLS il 21 ottobre per un problema di conformità; il sito che non installa il certificato sostitutivo può diventare irraggiungibile. Chrome, Apple e Microsoft non si fidano più di otto CA intermedie di eMudhra con chiavi deboli.
Segreti: LiteLLM e Railway
La versione 1.107.0 di LiteLLM pubblicata su PyPI e Docker Hub rubava credenziali all'avvio. Railway ha rilevato attività anomale nei sistemi che conservano le variabili d'ambiente dei clienti e chiede di ruotarle. In entrambi i casi le chiavi si cambiano anche se il server sembra sano.
Le versioni corrette, i comandi per verificarle e cosa ruotare in ogni caso, in un solo articolo.
Cosa aggiornare, ruotare e rinnovare →Come si ripristina un sito hackerato?
Sette passi, in quest'ordine. Ripulire senza sapere da dove sono entrati lascia aperta la stessa porta.
-
Contenimento
Prima fermiamo quello che sta ancora succedendo: reindirizzamenti, invio di spam, processi che non dovrebbero girare. Se serve, il sito resta in manutenzione mentre lavoriamo.
-
Copia e analisi di base
Conserviamo una copia dello stato compromesso e guardiamo i log di accesso, i file modificati, gli utenti e le attività pianificate per trovare il punto di accesso. Se ti serve una perizia per un processo o per l'assicurazione, la firma un perito; la copia resta conservata perché possa lavorarci.
-
Pulizia o ricostruzione
Se c'è un backup precedente all'intrusione e sappiamo come sono entrati, si ripristina e si ripulisce. Altrimenti si reinstalla il CMS dalle fonti ufficiali e si migra solo il contenuto controllato.
-
Aggiornare PHP, CMS e server
PHP a una versione con patch, core del CMS, plugin e tema, e il software del server (NGINX, Apache, Node.js) se lo gestisci tu. Quello che non supporta una versione mantenuta viene sostituito o rimosso.
-
Rotazione delle credenziali
Password, chiavi SSH, chiavi API e variabili d'ambiente. Tutto ciò che stava sul server si considera compromesso.
-
Verifica e blacklist
Controlliamo che il sito serva quello che deve, chiediamo la revisione a Google da Search Console e verifichiamo se il dominio o l'IP del server compaiono nelle blacklist delle email.
-
Manutenzione
Backup periodici conservati fuori dal server, aggiornamenti e monitoraggio degli avvisi di sicurezza del software che usa il tuo sito.
- Manutenzione se serve
- Stop a reindirizzamenti e spam
- Processi e connessioni sospette
- Avviso all'hosting
- Copia dello stato compromesso, fuori dal server
- Log di accesso e di errore
- File modificati di recente
- Utenti, cron e chiavi SSH
- Punto di accesso probabile
- Ripristinare un backup precedente all'intrusione
- Oppure reinstallare il CMS dalle fonti ufficiali
- Rimuovere backdoor e file iniettati
- Controllare il database (utenti, opzioni, contenuti)
- PHP a una versione con patch
- Core del CMS, plugin e tema
- NGINX, Apache o Node.js
- Sostituire ciò che non ha supporto
- Hosting, CMS, FTP/SFTP, SSH e database
- Chiavi API e token
- Variabili d'ambiente
- Verifica in due passaggi
- Revisione in Search Console
- Blacklist email e IP
- Certificato TLS valido
- Prova che il sito funziona
- Backup periodici fuori dal server
- Aggiornamenti di PHP, CMS e plugin
- Monitoraggio degli avvisi di sicurezza
Lo stai vedendo adesso? Mandaci l'indirizzo del sito e quello che hai notato.
Scrivici →Si può ripulire o bisogna rifare il sito?
Dipende da cosa c'è sul server e dall'esistenza di un backup precedente all'intrusione.
Si ripulisce
- Sappiamo da dove sono entrati e si può chiudere.
- C'è un backup precedente all'intrusione.
- CMS, plugin e tema supportano una versione di PHP mantenuta.
Conviene ricostruire
- Non c'è nessun backup affidabile, o l'infezione torna dopo ogni pulizia.
- Il sito dipende da plugin abbandonati o da una versione di PHP senza supporto.
- Si reinstalla dalle fonti ufficiali e si migra il contenuto controllato, oppure si rifà: per un sito aziendale, per esempio un sito statico con Astro, che non esegue PHP sul server.
Domande frequenti sui siti hackerati
Cosa fare se il sito è stato hackerato?
Come capire se il sito è stato hackerato?
Basta ripristinare un backup?
Come si toglie l'avviso di sito pericoloso di Google?
Devo avvisare il Garante della privacy?
Il mio sito in PHP è colpito da php2shell?
Garantite che non succeda di nuovo?
Cosa vi serve per iniziare?
Raccontaci cosa è successo e ce ne occupiamo noi
Con l'indirizzo del sito, quello che hai visto e gli accessi che hai ancora, controlliamo il server e ti diciamo se si può ripulire, se va ricostruito e cosa bisogna aggiornare.
Raccontaci la tua sfida. Ti proponiamo la soluzione.
Senza impegno. In meno di 24 ore riceverai una proposta con ambito, tempistiche e budget. Nessuna clausola nascosta.