Adobe Commerce e Magento CVE-2026-48356: PolyShell sfruttata da marzo, webshell caricate dal carrello senza credenziali

Il 27 ottobre 2026 la CISA ha inserito nel catalogo KEV la CVE-2026-48356, la falla di Adobe Commerce e Magento Open Source che i ricercatori di Sansec hanno chiamato PolyShell, e il giorno dopo ACN ha aggiornato il proprio alert di luglio sugli aggiornamenti Adobe per lo sfruttamento rilevato in rete. È un caricamento di file senza restrizioni (CWE-434) con CVSS v3.1 pari a 9.3, corretto da Adobe il 14 luglio 2026 con l'advisory APSB26-73 e le relative patch isolate. L'API REST di Magento accetta file allegati alle opzioni personalizzate dei prodotti nel carrello, ma non verifica che il prodotto preveda davvero un'opzione di tipo file né blocca estensioni come .php o .phtml: l'unico controllo riguarda l'intestazione d'immagine, che si aggira con un file poliglotta, cioè un'immagine GIF o PNG valida che contiene anche codice PHP. Le chiamate più esposte sono quelle del carrello ospite (guest cart), che non richiedono alcun account. Che il file caricato diventi codice eseguito dipende dalla configurazione del server web: con molte configurazioni dei provider di hosting si arriva all'esecuzione di codice da remoto, con altre a un XSS persistente che permette di rubare la sessione. Il punteggio di Adobe presuppone l'interazione di un utente, mentre Sansec descrive un caricamento che non ne richiede, con un impatto finale legato al server.

La falla è sfruttata da molto prima della patch. Sansec ha registrato i primi tentativi il 16 marzo 2026, la scansione automatizzata di massa dal 19 marzo e tentativi di attacco contro il 79,5% dei negozi protetti dal proprio servizio; il 30 marzo un'ondata ha piazzato webshell e poi un loader JavaScript in 471 negozi nel giro di un'ora. Alle webshell travestite da immagini gli attaccanti affiancavano una seconda backdoor, accesson.php, copiata in molte cartelle dell'applicazione per sopravvivere alla pulizia. Per i rami in produzione la correzione è arrivata solo a luglio, quasi quattro mesi dopo la divulgazione. Il 24 ottobre Sansec ha collegato PolyShell a una campagna attiva da luglio 2025 che ha colpito 953 negozi, per lo più Magento: il loader sta nella tabella cms_block del database e non nei file, e dal 23 ottobre raccoglie un'impronta del browser per distinguere i clienti reali dagli scanner di sicurezza, così ai controlli automatici la pagina risulta pulita. Il payload finale non è ancora stato catturato; a dicembre 2025 ai visitatori di alcuni negozi erano stati serviti script da un dominio che storpia il nome del portafoglio di criptovalute Ledger. Per le agenzie federali statunitensi la scadenza di remediation fissata dalla CISA è il 10 novembre 2026, con l'obbligo di triage forense previsto dalla direttiva BOD 26-04: un'indicazione che vale per chiunque gestisca un negozio rimasto senza patch fra marzo e luglio.

Un negozio aggiornato non è per forza un negozio pulito. Sansec cita un sito su Magento 2.4.7-p10, senza patch mancanti, che il 23 ottobre ha ricevuto il nuovo loader un'ora dopo una scansione senza esiti: a settembre vi erano stati trovati un account amministratore abusivo e una backdoor GSocket. Togliere lo script dal blocco CMS non revoca l'accesso in scrittura al database che l'attaccante si è già procurato. Fra le 169 installazioni Magento 2 infette prive di almeno una patch, 102 mostravano file caricati con PolyShell o con SessionReaper (CVE-2025-54236). È la seconda falla di Adobe Commerce e Magento sfruttata che segnaliamo in due mesi, dopo quella descritta in un nostro precedente alert dell'8 settembre sulla CVE-2026-75650 (StyleSmuggler) di Adobe Commerce e Magento: le piattaforme di e-commerce restano un bersaglio costante, perché da lì passano dati di pagamento e credenziali dei clienti.

A doversene preoccupare è chi gestisce un negozio online su Adobe Commerce, on-premise o su Cloud, o su Magento Open Source, comprese le installazioni affidate a web agency e hosting gestiti, dove la configurazione del server web la decide il provider e chi vende non sa se la cartella dei file caricati esegue codice PHP. A maggio Sansec indicava la 2.4.9 come già corretta, ma nell'advisory Adobe la 2.4.9 compare fra le versioni affette: il riferimento sicuro sono le release con suffisso -2026-jul o la patch isolata. Chi è rimasto esposto fra marzo e luglio deve partire dall'ipotesi di una compromissione, anche se oggi è aggiornato.

• Versioni affette: Adobe Commerce 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17, 2.4.4-p18 e precedenti; Adobe Commerce B2B 1.5.3, 1.5.2-p5, 1.4.2-p10, 1.3.4-p17, 1.3.3-p18 e precedenti; Magento Open Source 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15 e precedenti; Adobe Commerce Events fino alla 1.20.0.
• Azione raccomandata: installare le release 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul, 2.4.6-2026-jul, 2.4.5-2026-jul o 2.4.4-2026-jul (per B2B le corrispondenti -2026-jul, per Commerce Events la 1.21.0), oppure la patch isolata dell'articolo KA-37421, che richiede l'ultima release -p del proprio ramo; su Adobe Commerce on Cloud la correzione arriva con l'aggiornamento cloud-patches; negare l'accesso web e l'esecuzione PHP sulla cartella custom_options dei media pubblici, ricordando che questo non impedisce il caricamento e che solo un WAF che blocca la chiamata API ferma l'attacco; cercare nella cartella custom_options e in quella customer_address file diversi da .htaccess e in tutta l'applicazione file accesson.php; controllare i contenuti delle tabelle cms_block e cms_page alla ricerca di script inattesi, verificare gli account amministratore e i processi sconosciuti; a pulizia completata cambiare le password del database, degli amministratori e delle integrazioni API; applicare anche l'advisory APSB25-88 per SessionReaper.

Fonti: ACN, Sansec, Sansec (24 ottobre), Adobe, CISA, SecurityWeek