In breve: l'attuale vulnerabilità di Magento si chiama PHP2Shell e non si trova in Magento, ma in PHP. Una patch di Magento non la chiude. Dopo l'aggiornamento di PHP con riavvio dovrebbe controllare app/etc/env.php, il database alla ricerca di skimmer e l'elenco degli account admin.
Che cosa significa PHP2Shell per gli shop Magento
Magento Open Source e Adobe Commerce sono grandi applicazioni PHP che girano di solito con PHP-FPM. Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 consentono, secondo il team PHP, di eseguire codice dannoso senza autenticazione. Che lo shop stesso sia aggiornato è irrilevante al riguardo.
Da anni gli shop Magento sono un bersaglio preferito dello skimming di carte di credito, in cui i dati inseriti nel checkout vengono letti. PHP2Shell apre un'ulteriore via. Palo Alto Networks ha contato oltre 22,6 milioni di istanze PHP esposte e potenzialmente vulnerabili; quali shop ne facciano parte non è noto.
Vulnerabilità Magento: stabilire correttamente lo stato di PHP
Magento non mostra la versione di PHP in modo evidente nell'admin. Verifichi quindi lo stato nel pannello di hosting per il dominio o se lo faccia confermare dal Suo hoster. php -v da riga di comando mostra solo il PHP CLI, con cui girano bin/magento e i cronjob. Il PHP web tramite FPM può essere una versione diversa, ed entrambi devono essere aggiornati.
Le versioni upstream corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35; i backport delle distribuzioni possono riportare numeri più vecchi. Quali versioni di PHP supporta la Sua versione di Magento, lo verifichi nei requisiti di sistema nella documentazione di Adobe (experienceleague.adobe.com). Per Adobe Commerce su infrastruttura Adobe chieda ad Adobe o al Suo gestore lo stato. Una guida passo passo è offerta da Verificare correttamente versione e stato delle patch di PHP.
Dove si annida il codice dannoso in Magento
| Posizione | Contenuto | Punto da controllare |
|---|---|---|
app/etc/env.php |
Database, chiave di cifratura, percorso admin | Data di modifica, rinnovare i valori in caso di sospetto |
pub/ |
Document root, pub/media, pub/static |
File PHP nelle cartelle media e static |
app/code/ |
moduli propri | moduli sconosciuti, file modificati |
vendor/ |
pacchetti Composer, anche estensioni | scostamenti dal lockfile |
generated/, var/ |
codice generato, cache, log | salvare i log, rigenerare il codice |
| Database | configurazione, blocchi CMS, utenti admin | script estranei, nuovi admin |
In Magento gli skimmer si trovano spesso nel database, ad esempio nelle impostazioni per gli script aggiuntivi nell'header o nel footer della pagina e nei blocchi CMS. Una semplice scansione dei file non li rileva. Accessi in sola lettura non invasivi aiutano per un primo sguardo (prefisso delle tabelle a seconda dell'installazione):
bin/magento info:adminuri
bin/magento module:status
SELECT username, email, created FROM admin_user;
SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '%<script%';
Un checkout bonificato non significa che non siano usciti dati. Metta al sicuro i log a partire dal 20/10/2026 e le copie del database prima di rimuovere gli script. Solo così si potrà stabilire in seguito da quando e quali ordini siano stati interessati.
Area admin ed estensioni
In Magento il percorso admin è liberamente scelto e si trova in env.php. Un percorso difficile da indovinare è sensato, ma non sostituisce l'autenticazione a due fattori né la limitazione a reti note. Controlli regolarmente gli utenti admin e i loro ruoli, così come integrazioni e token API.
Le estensioni di terze parti in Magento sono numerose: metodi di pagamento, collegamenti ERP, moduli di ricerca e marketing. Ognuna porta con sé codice che va verificato a ogni aggiornamento di PHP. Usi regolarmente composer audit e rimuova completamente i moduli disattivati.
Pensi anche ai processi in background. Magento lavora con cronjob e spesso con consumer di code che girano come processi PHP propri da riga di comando. Dopo l'aggiornamento di PHP anche questi devono essere riavviati, come PHP-FPM. Dopo un cambio della versione principale di PHP dovrebbe inoltre far ricostruire il codice generato in generated/ e i file statici e provare lo shop in un ambiente di test prima di riprendere l'esercizio in produzione. Come eseguire correttamente il riavvio è descritto in Riavviare PHP-FPM e tutti i worker.
Che cosa può fare un aggiornamento di Magento e che cosa no
Una release di Magento o una patch di sicurezza di Adobe chiude errori nel codice dello shop. Non applica patch a PHP, non riavvia i processi FPM, non rimuove script dal database e non elimina account admin estranei. Se è già stato eseguito del codice, serve un'indagine. Come riconoscere le backdoor è spiegato in Riconoscere e rimuovere le web shell.
Per i commercianti con pagamento con carta vale inoltre: verifichi le disposizioni del Suo fornitore di pagamento per gli incidenti di sicurezza e si accordi con lui prima di rinnovare le chiavi. Se sia necessaria una notifica all'autorità per la protezione dei dati, lo chiarisca con il Suo responsabile della protezione dei dati o con un avvocato.
In che modo PHP SOS aiuta concretamente?
- Chiariamo PHP web e CLI del Suo server Magento e ci facciamo confermare patch e riavvio.
- Mettiamo al sicuro log, file e database in modo tracciabile, se necessario tramite la nostra analisi forense IT.
- Controlliamo
env.php,pub/, moduli, tabelle di configurazione, blocchi CMS e account admin. - Bonifichiamo, rinnoviamo chiavi e accessi e documentiamo il periodo di possibile coinvolgimento per la protezione dei dati e il fornitore di pagamento.
Domande frequenti
Una patch di sicurezza di Magento chiude anche PHP2Shell?
No. Le patch di Magento correggono errori nel codice dello shop. PHP2Shell è nell'interprete PHP del server e si chiude solo con un aggiornamento di PHP o un backport confermato, con riavvio di tutti i processi.
Dove nascondono gli aggressori gli skimmer di carte di credito in Magento?
Spesso non nei file, ma nel database, ad esempio nelle impostazioni per script aggiuntivi nell'intestazione della pagina o nei blocchi CMS. Perciò, in caso di sospetto, occorre sempre controllare anche il database.
Chi aggiorna PHP in Adobe Commerce nel cloud?
Dipende dal Suo contratto e dal Suo ambiente. Chieda per iscritto ad Adobe o al Suo gestore lo stato di PHP e il riavvio. Estensioni proprie e contenuti del database restano sotto la Sua responsabilità.
Perché app/etc/env.php è così importante?
Il file contiene i dati di accesso al database, la chiave di cifratura e il percorso dell'area admin. Chi ha potuto leggerlo può decifrare valori cifrati e trovare l'admin. In caso di sospetto questi valori andrebbero rinnovati.