Adobe Commerce CVE-2026-48356: RCE da upload file nella KEV CISA

Una vulnerabilità per cui Adobe ha rilasciato la correzione a luglio — classificata "priorità 2", con il bollettino che dichiarava di "non essere a conoscenza di exploit in circolazione" — da oggi viene sfruttata attivamente. Il 2026-10-27 CISA ha aggiunto CVE-2026-48356, una falla di upload file senza restrizioni in Adobe Commerce e Magento Open Source, al suo catalogo Known Exploited Vulnerabilities. La patch ha tre mesi e mezzo. Lo sfruttamento no — il vendor Sansec, che chiama questa falla PolyShell, la traccia in ondate automatizzate di massa fin da marzo 2026. Per le migliaia di negozi che a luglio hanno letto "priorità 2, nessun exploit noto" e sono andati oltre, l'inserimento in KEV è la conferma federale, in ritardo, che gli attacchi non sono mai stati ipotetici.

Notizia in evoluzione — pubblicata alle 21:17 (20:17 UTC) del 27 ottobre 2026. Aggiornata man mano che vendor e CISA pubblicano.

Aggiornamento — 2026-10-28 03:34 CET

Il dettaglio dello sfruttamento che questo articolo segnalava come mancante è stato pubblicato, e NVD ora cita due analisi del vendor di forensics Sansec. Sansec chiama la falla PolyShell e lega CVE-2026-48356 a una campagna skimmer via blocchi CMS di lunga durata — non a un attacco nuovo iniziato con l'inserimento in KEV:

• Lo sfruttamento è vecchio di mesi ed è automatizzato. Sansec documenta un'ondata PolyShell di massa che ha compromesso 471 negozi in una sola ora il 2026-03-30, con la catena "completamente automatizzata". Questo ridimensiona la lettura UI:R più sotto: qualunque interazione presuma il vettore CVSS, non ha rallentato un'ondata scriptata che colpisce centinaia di negozi all'ora.
• Alimenta la campagna skimmer "DeepVeinDrilling". Secondo l'analisi Sansec del 2026-10-24, PolyShell (CVE-2026-48356) e SessionReaper (CVE-2025-54236) sono le falle di upload usate per piazzare web shell, dopodiché l'operatore inietta un loader JavaScript nella tabella Magento cms_block; la campagna ha toccato 953 negozi da luglio 2025. Questo risponde alla domanda sulla "sovrapposizione con le altre campagne Magento" più sotto — è un'unica operazione prolungata, e alcuni negozi già aggiornati sono stati re-infettati tramite appigli precedenti.
• Ora esistono IOC concreti — integrati nella sezione Caccia più sotto. Sansec riferisce di non aver ancora catturato il payload skimmer finale, e il gruppo resta non attribuito.

In breve

CVE	CVE-2026-48356
Prodotto / versioni colpite	Adobe Commerce e Magento Open Source 2.4.4–2.4.9 (2.4.9; 2.4.8-p5 e precedenti; 2.4.7-p10 e precedenti; 2.4.6-p15 e precedenti; 2.4.5-p17 e precedenti; 2.4.4-p18 e precedenti); Adobe Commerce B2B 1.3.3–1.5.3
Corretta in	Aggiornamento di sicurezza APSB26-73 di luglio 2026 per ogni branch (release 2.4.x-2026-jul / 1.x-2026-jul; in pratica il patch level successivo)
CVSS	9.3 Critica · CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N · punteggio identico per Adobe (CNA) e NVD
Sfruttata attivamente	Sì — in CISA KEV dal 2026-10-27; Sansec (che la chiama PolyShell) documenta sfruttamento automatizzato di massa dal 2026-03-30 (471 negozi in un'ora), a sostegno della campagna skimmer DeepVeinDrilling
CISA KEV	Aggiunta 2026-10-27; scadenza federale 2026-11-10 (BOD 26-04); uso ransomware Sconosciuto; triage forense non richiesto
PoC pubblico	Nessun codice exploit pubblico; Sansec ha pubblicato gli IOC della campagna il 2026-10-24
Advisory ufficiale	Adobe APSB26-73

Che cos'è davvero CVE-2026-48356

La debolezza è CWE-434, upload senza restrizioni di file di tipo pericoloso: l'applicazione accetta un file di un tipo che avrebbe dovuto rifiutare, lo scrive in una posizione raggiungibile e finisce per eseguirlo. In Adobe Commerce e Magento questo significa codice arbitrario che gira "nel contesto dell'utente corrente" — parole di Adobe — con una via verso un accesso elevato all'account o alla sessione della vittima. Per una piattaforma che sta nel flusso di checkout e tratta dati delle carte, "esecuzione di codice arbitrario sul negozio" è l'intera partita.

Due dettagli del vettore CVSS cambiano il modo in cui va letto questo bug, e molti articoli pubblicati stanotte li sbaglieranno:

• PR:N — nessuna credenziale dell'attaccante. Chi attacca non ha bisogno di un account sul tuo negozio. Nella tabella dell'advisory Adobe il bug è marcato come privo di requisiti di autenticazione, ed è per questo che il punteggio è così alto.
• UI:R — ma serve un'azione dell'utente. La descrizione NVD è esplicita: lo sfruttamento richiede interazione dell'utente, nel senso che una vittima deve visitare un URL malevolo o interagire con una pagina compromessa. E lo scope è cambiato (S:C): il codice gira in un contesto di sicurezza diverso da quello di partenza.

Sulla carta non è il banale "fai POST di una web shell su un endpoint pubblico e ottieni RCE istantanea" di StyleSmuggler. Il vettore CVSS lo legge come una falla non autenticata ma condizionata dall'interazione: l'attaccante deve comunque portare un utente — nel caso peggiore un amministratore con sessione attiva — a innescare l'upload. Questa sfumatura conta per il punteggio. Non rende il bug innocuo, e in pratica non ha rallentato nessuno: come registra l'Aggiornamento qui sopra, Sansec ha osservato un'ondata PolyShell completamente automatizzata che colpiva centinaia di negozi all'ora. Trattalo come una falla di sfruttamento di massa in corso, non come una condizionata.

Perché una patch di luglio è un problema di oggi

Adobe l'ha divulgata in APSB26-73 il 14 luglio 2026, dentro un lotto ordinario di quattordici CVE di Commerce, con priorità 2 — la fascia "rischio elevato, patch entro 30 giorni" di Adobe, non quella "patch immediata" riservata alla priorità 1. Il testo standard del bollettino all'epoca: Adobe "non è a conoscenza di exploit in circolazione per nessuno dei problemi risolti in questi aggiornamenti".

Quella frase era vera a luglio. È una fotografia, non una previsione, e l'ecosistema Magento è l'esempio da manuale del perché le due cose sono diverse:

• Ogni patch di Adobe Commerce viene distribuita come sorgente. Entro pochi giorni da una release gli attaccanti confrontano il "prima" e il "dopo" e ricostruiscono il bug — la correzione è la specifica dell'exploit.
• I negozi Magento applicano le patch lentamente. Gli aggiornamenti toccano i flussi di pagamento, quindi i merchant li rimandano; in ogni momento una quota consistente dei negozi in produzione gira diversi patch level indietro. È la stessa dinamica che ha reso CosmicSting (CVE-2024-34102) e, a settembre, StyleSmuggler (CVE-2026-75650) eventi di sfruttamento di massa.
• EPSS ora colloca CVE-2026-48356 nel 98° percentile di tutte le CVE per probabilità di sfruttamento (secondo il modello EPSS di FIRST, punteggio aggiornato al 2026-10-27) — il modello segnalava questo CVE come probabile bersaglio già da settimane.

La lettura onesta della cronologia: un bug "priorità 2, nessun exploit noto" è diventato un bug sfruttato attivamente in quattordici settimane, esattamente la finestra che serve agli attaccanti per trasformare una patch divulgata in arma contro una flotta lenta ad aggiornarsi. Se la tua prioritizzazione dipende dall'etichetta di gravità del vendor al giorno zero, sei sempre un trimestre indietro rispetto a chi ti attacca.

Sono esposto?

Tutte le linee supportate rientrano nel perimetro. Confronta la versione in esecuzione con le release corrette:

# Dalla root di Magento/Adobe Commerce:
php bin/magento --version
# oppure ispeziona il lock di composer:
grep -m1 '"magento/product-community-edition"' composer.lock
grep -m1 '"magento/product-enterprise-edition"' composer.lock

Se il tuo branch è pari o inferiore alla riga "e precedenti" nella tabella sopra — per esempio Commerce 2.4.7-p10, 2.4.6-p15, o un qualsiasi 2.4.9 anteriore alla release di sicurezza di luglio — sei colpito e devi trattarlo come un incidente attivo, non come un ticket di manutenzione.

Remediation

1. Patch — versioni corrette esatte

Applica l'aggiornamento di sicurezza APSB26-73 di luglio 2026 per il tuo branch. Secondo l'advisory Adobe, le release corrette sono:

Prodotto	Colpite	Applica
Adobe Commerce	2.4.9; 2.4.8-p5 e precedenti; 2.4.7-p10 e precedenti; 2.4.6-p15 e precedenti; 2.4.5-p17 e precedenti; 2.4.4-p18 e precedenti	la release di sicurezza 2.4.x-2026-jul per il tuo branch (patch level successivo)
Adobe Commerce B2B	1.5.3; 1.5.2-p5 e precedenti; 1.4.2-p10 e precedenti; 1.3.4-p17 e precedenti; 1.3.3-p18 e precedenti	la release 1.x-2026-jul per il tuo branch
Magento Open Source	2.4.9; 2.4.8-p5 e precedenti; 2.4.7-p10 e precedenti; 2.4.6-p15 e precedenti	la release 2.4.x-2026-jul per il tuo branch

Verifica il nome esatto del pacchetto per il tuo branch in APSB26-73 prima di deployare — lo stesso bollettino corregge altre tredici CVE, diverse con CVSS ≥ 9, quindi non esiste un'opzione di patch parziale che valga la pena prendere.

2. Non puoi applicare la patch adesso? Controlli compensativi

Un upgrade completo di Commerce è una modifica al percorso di pagamento e spesso richiede una finestra di manutenzione. Finché non arriva:

• Blinda le superfici di upload e admin sul WAF. Blocca gli upload con estensioni eseguibili o tipi MIME incoerenti verso gli endpoint Commerce; applica rate-limit e geofencing su /admin (o sul tuo path admin personalizzato) verso le reti operative note.
• Imponi le basi su path admin e 2FA così da rendere più difficile la metà "indurre un utente autenticato" della catena: URL admin univoco, 2FA obbligatoria, durata breve della sessione admin.
• Servi pub/media senza esecuzione. Le directory di media e upload non devono mai eseguire PHP. Su nginx, assicurati che nessun location passi pub/media a fastcgi; su Apache, verifica che il pub/media/.htaccess fornito neghi l'esecuzione di script e non sia stato sovrascritto da un tema o da un'estensione.

3. Caccia alla compromissione

Poiché l'inserimento in KEV significa che lo sfruttamento è in corso, dai per scontato che il traffico di sonda ti abbia già raggiunto. Cerca lo stadio post-upload, mappato su MITRE ATT&CK:

• Web shell (T1505.003): file .php nuovi o modificati di recente sotto pub/media/, pub/static/, var/, media/, o ovunque fuori dall'artefatto di deploy. find pub/ media/ var/ -name '*.php' -newermt '2026-07-14' -type f è una prima passata rapida; confronta l'elenco con un checkout di release noto-buono.
• Sfruttamento di applicazione pubblica (T1190): richieste POST verso endpoint di upload o import da una singola sorgente, discordanze strane di Content-Type/estensione nei log di accesso, 200 su path che dovrebbero dare 403.
• Esecuzione (T1059): l'utente del web server che lancia sh, curl, wget, o processi PHP con socket di rete non giustificabili.
• Esfiltrazione dati / iniezione skimmer: connessioni in uscita inattese dal nodo web, e JavaScript iniettato nei contenuti di checkout/cms_block/cms_page — il classico epilogo Magecart una volta che l'RCE arriva su un negozio.

L'analisi DeepVeinDrilling di Sansec ha pubblicato gli indicatori concreti della campagna che sfrutta questo CVE — verifica il tuo parco direttamente su questi:

• Web shell PolyShell camuffate da immagini sotto pub/media/custom_options/quote/ e pub/media/customer_address/ — il segnale è un payload .php con intestazione PNG; l'ondata precedente lasciava anche backdoor accesson.php in più directory.
• Loader iniettato nel database, non nel filesystem: interroga cms_block.content e cms_page cercando fpCode, se_referrer e localStorage.getItem — il loader vive nei contenuti CMS che Magento rende nelle pagine del negozio, quindi un file tree pulito non significa un negozio pulito.
• Il dominio del loader deepveindrilling.com (e i predecessori additionalver.com, neswnsssn.click, manulfie.click, lanhd6549tdhse.top) che compare nell'HTML del negozio o nelle richieste in uscita.
• Persistenza oltre la shell: account admin fasulli e, su almeno un negozio già aggiornato, una backdoor GSocket — la sola patch non espelle un operatore che ha già un appiglio.

4. Bonifica e verifica

Se trovi qualcosa: prima la patch (un negozio non aggiornato viene ri-compromesso nel giro di ore), poi rimuovi gli impianti, poi ruota ogni segreto leggibile dal nodo web — la crypt/key di Magento in env.php, credenziali admin e di integrazione, token API e chiavi del gateway di pagamento. Invalida tutte le sessioni admin. Solo dopo che l'host è aggiornato e pulito si ri-testa: conferma che l'endpoint di upload ora rifiuti il tipo pericoloso e che nessuna web shell sopravviva a un redeploy dal controllo di versione. La verifica dopo la patch è il passo che la maggior parte dei post-mortem registra come saltato.

Cosa non si sa ancora

• Il payload finale. Sansec riferisce di non aver catturato il payload skimmer/di fingerprinting che il loader serve alla fine, al momento della sua analisi del 2026-10-24 — è il server a decidere per ogni visitatore cosa restituire. Tratta con cautela qualsiasi "lista IOC completa" che dichiari il payload finale finché non la pubblica una fonte con nome e cognome.
• L'attribuzione. Sansec descrive "un gruppo criminale" dietro la campagna DeepVeinDrilling ma non nomina un attore, e resta da stabilire se si sovrapponga alle squadre di CosmicSting.
• Il ritardo dell'SSVC. La decisione SSVC di NVD per questo CVE era in ritardo sulla realtà dello sfruttamento al momento della pubblicazione; la KEV è ora il segnale autorevole, e il record NVD è stato modificato l'ultima volta il 2026-10-27.

Aggiorneremo questo articolo man mano che le fonti primarie pubblicano.

Valida la sfruttabilità prima di applicare patch nel panico — e guarda il traffico

La domanda operativa che questo CVE impone non è "è grave" (il CVSS dice di sì) ma "dove, nel mio parco, è grave adesso" — perché l'etichetta di priorità del vendor al giorno zero si è appena rivelata una guida scadente. L'AI Remediation Advisor di Zero Hunt risponde ordinando i finding sulla sfruttabilità reale e non sulla gravità da catalogo: prima CISA KEV, poi ciò che la campagna ha davvero dimostrato sfruttabile nel tuo ambiente, poi CVSS, poi EPSS. Un bug come CVE-2026-48356 salta la coda nel momento in cui finisce in KEV — e l'advisor restituisce la release corretta esatta per il tuo branch, con note di rollout e rollback e il controllo compensativo da usare fino alla finestra di manutenzione, poi ri-verifica la correzione con la stessa prova che aveva dimostrato il problema.

Poiché il bug è condizionato dall'interazione (UI:R), "sono colpito" dipende davvero dalla tua configurazione, ed è lì che un red team autonomo con AI vale più di uno scanner che legge solo i banner di versione. Lo swarm a 10 agenti di Zero Hunt opera in gray-box sulla versione esatta installata, e il suo Exploit Forge itera un proof-of-concept sigillato finché la catena di upload o funziona dimostrabilmente sul tuo negozio o dimostrabilmente no — ogni tentativo in un container effimero che non tocca mai l'host, ogni finding firmato alla scrittura per la catena di prova. È la differenza tra "applica patch a tutto, in ordine casuale, e spera" e un piano ordinato provato sul tuo deployment. Sul fronte rilevamento, lo stesso motore con il suo modello di traffico sorveglia l'epilogo Magecart che questi negozi continuano a subire — l'esfiltrazione in uscita dei dati delle carte — sul filo, mentre accade, non nella revisione dei log dell'indomani. Per i merchant, questo è anche il dovere di test del PCI DSS Requisito 11.4 assolto in continuo invece che una volta l'anno. Gira on-premise sui modelli di Zero Hunt, con una persona che approva ogni azione che conta — nessun dato del negozio che lascia l'apparato, nessun terzo in grado di spegnere la capacità.