# Negozio online hackerato? Sicurezza IT per i rivenditori

> Negozio online hackerato o a rischio per PHP2Shell? Come i rivenditori proteggono account cliente, checkout e fatturato nelle prime ore.

Fonte: https://phpsos.de/it/branchen/onlineshops/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** se il Suo negozio online è stato hackerato o gira su una versione di PHP non aggiornata, sono in gioco tre cose allo stesso tempo: i dati dei clienti, il checkout e il Suo fatturato. Metta lo shop in modalità manutenzione in modo controllato, salvi i log dal 20/10/2026 e chiarisca chi aggiorna e riavvia PHP sul Suo server.

## Che cosa è in gioco in un negozio online

Uno shop è più di un sito web. Gestisce account cliente con hash delle password, indirizzi di consegna e di fatturazione, storico degli ordini, buoni e spesso anche interfacce verso gestionale, corrieri e marketplace. Chi può eseguire codice sul server di norma arriva al database e alle chiavi API lì memorizzate.

I dati delle carte di norma non si trovano presso di Lei, ma presso il fornitore di pagamento. Questo rassicura solo in parte: un aggressore può introdurre nel processo d'ordine JavaScript che legge l'input nel browser. Questi script di skimming passano quasi inosservati nell'attività dello shop, perché gli ordini proseguono del tutto normalmente.

Si aggiungono le interfacce. Uno shop che trasmette gli ordini a gestionale, corrieri e marketplace memorizza di solito le chiavi di accesso in file di configurazione sul server. Chi le copia può generare etichette di spedizione a nome del commerciante, modificare le giacenze o abusare degli account dei marketplace.

## Sistemi di shop tipici e perché PHP2Shell li colpisce

I sistemi di shop più diffusi nelle medie imprese europee girano su PHP: [Shopware 6](https://phpsos.de/it/plattformen/shopware-6/), [WooCommerce](https://phpsos.de/it/plattformen/woocommerce/), Magento, OXID, PrestaShop e molte vecchie installazioni di Shopware 5. PHP2Shell (CVE-2026-109618 e CVE-2026-109619, ciascuna con CVSS 9,2) si trova in PHP stesso. Gli aggressori non hanno bisogno di un account cliente né di un accesso admin.

Per i commercianti significa: l'ultimo aggiornamento dello shop non protegge. Conta se PHP sul server è alla versione 8.5.12, 8.4.27, 8.3.36 o 8.2.35 oppure se l'hoster ha applicato un backport, e se in seguito tutti i processi PHP sono stati riavviati. Per i vecchi shop con PHP 8.1 o precedente il progetto PHP non offre più aggiornamenti ufficiali. In quel caso, oltre all'emergenza, c'è da affrontare una migrazione che non vuole certo fare sotto pressione in alta stagione.

## Negozio online hackerato: che cosa comporta concretamente un incidente

Uno shop compromesso causa danni su più livelli, che si rafforzano a vicenda:

- **Fatturato:** ogni ora di modalità manutenzione costa ordini. Uno shop che continua a funzionare senza che nessuno se ne accorga può però costare molto di più.
- **Dati dei clienti:** indirizzi e ordini sottratti vengono usati per e-mail di phishing mirate, che sembrano autentiche perché citano ordini reali.
- **Visibilità:** se Google riconosce del codice dannoso, nei risultati di ricerca compare un avviso. Come eliminarlo lo spiega la guida [Rimuovere l'avviso di Google](https://phpsos.de/it/ratgeber/google-warnung-entfernen/).
- **Partner:** fornitori di pagamento e marketplace hanno regole proprie per gli incidenti di sicurezza. Chi segnala troppo tardi rischia problemi nella fatturazione.

## Chi è responsabile: agenzia, hoster o commerciante?

In molti shop la questione PHP cade tra due sedie. L'agenzia ha costruito lo shop e cura i plugin, l'hoster gestisce il server e il commerciante dà per scontato che se ne occupi uno dei due. Con l'hosting gestito di norma provvede l'hoster, con un vServer proprio nessuno lo fa in automatico.

| Attività | Di norma responsabile | Da verificare |
|---|---|---|
| Aggiornare il pacchetto PHP | Hoster o gestore del server | Conferma scritta con stato del pacchetto |
| Riavviare i processi PHP | chi amministra il server | Momento del riavvio |
| Shop e plugin | Agenzia | Contratto di manutenzione e accessi |
| Informare il fornitore di pagamento | Commerciante | Obblighi contrattuali di notifica |

> **Importante:**
> Una patch di PHP non dimostra che prima non sia successo nulla. Se lo shop è stato attaccato tra il 17/10 e il momento della patch, il codice introdotto può continuare a girare. Lo faccia verificare prima di dare il via libera.

## Le prime ore: la sequenza per i commercianti

1. Mettere lo shop in modalità manutenzione o, se non è possibile, scollegarlo temporaneamente dalla rete.
2. Salvare i log del server web, di PHP e dello shop dal 20/10/2026, prima che la rotazione li cancelli.
3. Far confermare per iscritto all'hoster lo stato del pacchetto PHP e il riavvio.
4. Rinnovare password admin, chiavi API per pagamento, spedizione e marketplace e accessi al database, e farlo solo dopo la bonifica.
5. Controllare checkout, plugin di pagamento e script incorporati per individuare modifiche.

Se ci sono indizi di una fuga di dati, decorre il [termine di 72 ore del GDPR](https://phpsos.de/it/compliance/dsgvo-meldepflicht-72-stunden/). La valutazione giuridica la effettua con il Suo responsabile della protezione dei dati e, se necessario, con il Suo avvocato.

## Come aiuta concretamente PHP SOS?

- Verifichiamo da remoto lo stato reale del pacchetto PHP, la modalità di esecuzione (ad esempio mod_php o PHP-FPM) e se tutti i worker sono stati riavviati.
- Esaminiamo file dello shop, database e checkout alla ricerca di web shell, codice di skimming e nuovi account admin e [rimuoviamo il malware trovato](https://phpsos.de/it/leistungen/malware-entfernung/).
- Ci coordiniamo con la Sua agenzia e il Suo hoster, perché manutenzione dello shop ed esercizio del server non procedano ciascuno per conto proprio.
- Documentiamo risultati e misure in modo che possa presentarli a fornitore di pagamento, assicuratore e responsabile della protezione dei dati.
- Poi rafforziamo il server e, su richiesta, ci occupiamo della sorveglianza continua.


## Domande frequenti

**Devo scollegare il mio shop dalla rete a causa di PHP2Shell?**  
Il BSI raccomanda di scollegare temporaneamente i server web dalla rete se l'aggiornamento di PHP non è subito possibile. Per uno shop, una modalità manutenzione con pagina informativa è spesso preferibile a un messaggio di errore. Una volta aggiornato PHP e riavviati tutti i processi, lo shop può riaprire.

**I dati delle carte di credito sono a rischio nel mio shop?**  
Nella maggior parte degli shop i dati delle carte non si trovano sul proprio server, ma presso il fornitore di pagamento. Pericoloso è però il codice manipolato nel checkout, che intercetta l'input prima che raggiunga il fornitore. Per questo il checkout rientra in ogni verifica successiva a un attacco.

**Basta aggiornare Shopware o WooCommerce?**  
No. PHP2Shell riguarda PHP stesso, non il sistema di shop. Un aggiornamento dello shop non chiude la vulnerabilità, e una patch di PHP non rimuove il codice dannoso già introdotto.

**Chi devo informare dopo una fuga di dati?**  
In presenza di dati personali può rilevare la notifica all'autorità di protezione dei dati entro 72 ore e, a seconda del rischio, anche l'informazione degli interessati. Si aggiungono obblighi contrattuali verso il fornitore di pagamento e l'assicuratore. La valutazione nel singolo caso la effettua con il responsabile della protezione dei dati e con un avvocato.

## Fonti

- [php.net: bollettini di sicurezza](https://www.php.net/)
- [BSI: avvisi e raccomandazioni](https://www.bsi.bund.de/)
- [GDPR art. 33: notifica all'autorità di controllo](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
