# Vulnerabilità Shopware 6 PHP2Shell: come mettere in sicurezza il Suo shop > Shopware 6 e PHP2Shell: perché un aggiornamento dello shop non basta, dove si nasconde il codice dannoso (.env, custom/plugins, public) e come verificare le integrazioni. Fonte: https://phpsos.de/it/plattformen/shopware-6/ 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:** la vulnerabilità di Shopware 6 che molti commercianti cercano in questi giorni è in realtà una vulnerabilità di PHP. Gli aggiornamenti di Shopware non la chiudono. Serve un PHP aggiornato con riavvio di tutti i processi e, subito dopo, vanno controllati `.env`, `custom/plugins`, la cartella `public` e le integrazioni API. ## Che cosa significa PHP2Shell per Shopware 6 Shopware 6 si basa sul framework PHP Symfony e gira di solito con PHP-FPM dietro Nginx o Apache. Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 riguardano proprio questa modalità di esecuzione. Secondo il team PHP consentono di eseguire codice dannoso da remoto, senza accesso allo shop. Un aggressore con esecuzione di codice sul server raggiunge tutto ciò a cui accede lo shop stesso: dati dei clienti, ordini, documenti di fatturazione, credenziali del gestionale e dei fornitori di pagamento. Il contesto tecnico è spiegato in [Che cos'è PHP2Shell?](https://phpsos.de/it/php2shell/was-ist-php2shell/). ## Verificare la vulnerabilità di Shopware 6: quale PHP gira davvero? Shopware 6 viene gestito in gran parte da riga di comando, ad esempio con `bin/console`. Qui è facile commettere un errore: `php -v` mostra la versione del PHP a riga di comando, non necessariamente quella di PHP-FPM, che elabora le richieste dello shop. Su molti server sono installate in parallelo più versioni di PHP. Sono affidabili l'indicazione nel pannello di hosting per il dominio specifico e la conferma dell'hoster sullo stato dei pacchetti. Le versioni upstream corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35; i backport possono riportare numeri più vecchi. Quali versioni di PHP supporta la Sua versione di Shopware, lo verifichi nei requisiti di sistema della documentazione su shopware.com. Come controllare da soli è spiegato in [Verificare correttamente versione e stato delle patch di PHP](https://phpsos.de/it/php2shell/php-version-pruefen/). Un punto viene spesso trascurato in Shopware 6: molti shop elaborano la coda dei messaggi e le attività pianificate tramite processi in background sempre attivi, ad esempio `bin/console messenger:consume` sotto un gestore di processi. Questi processi caricano PHP una sola volta all'avvio. Dopo l'aggiornamento vanno quindi riavviati non solo PHP-FPM, ma anche questi worker. Altrimenti una parte dello shop continua a lavorare in memoria con il vecchio PHP vulnerabile. ## Directory e file da conoscere | Posizione | Contenuto | Perché è rilevante | |---|---|---| | `.env`, `.env.local` | Accesso al database, `APP_SECRET`, altre chiavi | Da rinnovare in caso di sospetto | | `public/` | Document root con `index.php`, media, file del tema | File PHP aggiuntivi sono sospetti | | `public/theme/` | File JavaScript e CSS compilati della storefront | Luogo per skimmer introdotti | | `custom/plugins/`, `custom/apps/` | Estensioni | Codice del plugin modificato | | `files/` | File privati come fatture e bolle di consegna | Dati personali | | `var/log/` | Log dello shop | Mettere al sicuro le tracce | Primi controlli non invasivi: ```bash # Mostrare i plugin installati con versione e stato bin/console plugin:list # Elencare i file PHP nella directory pubblica find public -type f -name "*.php" # Mostrare le vulnerabilità note nelle dipendenze di Composer composer audit ``` Nella cartella `public/` dovrebbero esserci solo pochi file PHP, noti. Tutto ciò che è sconosciuto va messo al sicuro ed esaminato, non eliminato subito. > **Consiglio:** > Nell'amministrazione, in Impostazioni > Sistema, controlli le sezioni «Utenti e permessi» e «Integrazioni». Utenti o integrazioni API sconosciuti sono una backdoor che qualsiasi scansione dei file non rileva. ## Accesso admin, plugin e app come rischio L'amministrazione si trova per impostazione predefinita in `/admin`. La protegga con account personali, un'autenticazione robusta e, se possibile, con una limitazione dell'accesso a reti note. Le integrazioni per gestionale, marketplace o corrieri dovrebbero avere solo i diritti di cui hanno davvero bisogno. I plugin dello store e gli sviluppi su misura portano con sé codice PHP proprio, le app in più webhook verso server esterni. Più estensioni ci sono, maggiore è la superficie di attacco e più laborioso è ogni aggiornamento di PHP. Rimuova completamente i plugin non più utilizzati. ## Che cosa può fare un aggiornamento di Shopware e che cosa no Un aggiornamento di Shopware o di un plugin chiude errori noti in quel codice. Non può: - applicare la patch a PHP sul server, - riavviare i vecchi processi PHP-FPM, - rimuovere in modo sicuro file estranei in `public/` o file del tema manipolati, - eliminare utenti o integrazioni estranei, - dimostrare che prima della patch non sia successo nulla. Dopo un aggiornamento di PHP a una nuova versione principale dovrebbe rigenerare cache e tema e verificare lo shop in un ambiente di test. Il passaggio di PHP con relativa documentazione lo svolge, su richiesta, il nostro [servizio di patch PHP](https://phpsos.de/it/leistungen/php-patch-service/). Presso i commercianti più grandi Shopware 6 gira spesso su più server applicativi. In tal caso ogni server deve essere aggiornato e riavviato, anche quelli che eseguono solo attività in background. Se un fornitore di servizi gestisce lo shop come piattaforma gestita, dovrebbe confermarLe lo stato per tutti i nodi. ## In che modo PHP SOS aiuta concretamente? - Stabiliamo quale PHP usi davvero il Suo shop tramite FPM e chiariamo patch e riavvio con hoster o agenzia. - Mettiamo al sicuro i log a partire dal 20/10/2026, il database e i file. - Controlliamo `public/`, i file compilati del tema, plugin, utenti e integrazioni alla ricerca di anomalie. - In caso di riscontro bonifichiamo lo shop insieme alla Sua agenzia e rinnoviamo in modo ordinato chiavi e accessi. ## Domande frequenti **Shopware 6 stesso è interessato da PHP2Shell?** Le vulnerabilità sono in PHP, non nel codice di Shopware. Ogni shop Shopware 6 su un PHP non aggiornato è quindi potenzialmente attaccabile, indipendentemente dalla versione di Shopware. Un aggiornamento di Shopware non cambia nulla al riguardo. **Quale file di Shopware 6 è particolarmente critico dopo un attacco?** Il file .env o .env.local con i dati di accesso al database e APP_SECRET. Chi ha potuto leggerlo conosce le Sue credenziali. In caso di sospetto questi valori andrebbero rinnovati, in accordo con la Sua agenzia. **Che cosa sono le integrazioni in Shopware 6 e perché verificarle?** Le integrazioni sono accessi API per sistemi esterni come gestionali o marketplace. Un'integrazione estranea con diritti di amministratore consente l'accesso completo allo shop tramite l'API, senza che sul server ci sia alcun file. ## Fonti - [php.net: bollettini di sicurezza](https://www.php.net/) - [Shopware](https://www.shopware.com/) - [Versioni di PHP supportate](https://www.php.net/supported-versions.php) - [OWASP Top 10](https://owasp.org/www-project-top-ten/)