Adobe Campaign Classic espone i server a RCE senza autenticazione

🛡️ Executive Summary

• Adobe Campaign Classic on-premise consente esecuzione di codice da remoto senza credenziali e richiede l’aggiornamento alla build 9397.
• AWS pubblica quattro bollettini per componenti e librerie, compreso un denial of service remoto nel runtime aws-smithy-json.
• Rails corregge Active Storage: immagini manipolate possono leggere file e segreti, aprendo la strada alla compromissione completa dell’applicazione.

Adobe, Amazon Web Services e il progetto Ruby on Rails hanno pubblicato una nuova serie di aggiornamenti destinati a server aziendali, applicazioni cloud e pipeline software. Il rischio più immediato riguarda Adobe Campaign Classic, dove una vulnerabilità con punteggio CVSS 10.0 permette l’esecuzione arbitraria di codice senza autenticazione sulle installazioni on-premise vulnerabili. AWS ha diffuso quattro bollettini separati relativi ai propri componenti software, mentre Rails ha corretto CVE-2026-66066 in Active Storage. Quest’ultima falla consente la lettura di file del server attraverso immagini manipolate e può trasformarsi in esecuzione remota quando vengono sottratte le chiavi crittografiche dell’applicazione.

Adobe Campaign Classic permette codice remoto senza credenziali

La vulnerabilità di Adobe Campaign Classic v7 deriva da un controllo di autorizzazione insufficiente e può essere sfruttata attraverso la rete senza credenziali, privilegi preliminari o interazione dell’utente. Il vettore assegnato da Adobe, AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, descrive una catena a bassa complessità capace di compromettere riservatezza, integrità e disponibilità dell’installazione. Un aggressore può quindi tentare di eseguire codice nel contesto del processo Campaign, raggiungere dati utilizzati per le attività di marketing, alterare workflow e utilizzare il server come punto di partenza verso database, sistemi di posta e reti interne. Il prodotto gestisce infatti liste di destinatari, segmentazioni, template, automazioni, credenziali applicative e integrazioni con altre piattaforme aziendali, rendendo una RCE particolarmente pericolosa anche quando il servizio non è esposto direttamente su Internet. Il problema interessa Adobe Campaign Classic 7.4.3 build 9396 e precedenti su Windows e Linux ed è corretto nella build 9397. La falla riguarda esclusivamente le installazioni completamente on-premise e i componenti locali delle configurazioni ibride; le istanze interamente ospitate da Adobe sono già state corrette e non richiedono interventi del cliente. L’aggiornamento ha priorità 1, il livello utilizzato da Adobe quando la patch deve essere distribuita rapidamente sulle installazioni esposte a un rischio elevato. La vulnerabilità segue due precedenti falle critiche di autorizzazione corrette con la build 9396 e conferma la necessità di verificare la versione effettivamente installata, senza presumere che un aggiornamento applicato poche settimane prima contenga anche la correzione più recente. Il tema si inserisce nel quadro delle vulnerabilità Adobe corrette insieme a falle critiche in WordPress, Fortinet, AWS e OpenSSL, dove prodotti esposti e componenti server richiedono una gestione delle patch più rapida rispetto al normale ciclo mensile. Nel bollettino Adobe APSB26-69 dedicato a Campaign Classic, il produttore assegna alla vulnerabilità CVE-2026-48286 il punteggio massimo e raccomanda il passaggio immediato alla build 9397.

L’aggiornamento deve includere log e credenziali del server

L’applicazione della patch interrompe il percorso vulnerabile, ma non dimostra che il sistema non sia stato compromesso prima dell’aggiornamento. Gli amministratori devono ricostruire l’esposizione dell’istanza, verificare se le interfacce di Campaign fossero raggiungibili da Internet o da reti meno fidate e analizzare richieste anomale, processi avviati dal servizio, file creati recentemente e connessioni verso indirizzi esterni. Devono essere controllati anche account amministrativi, modifiche ai workflow, nuove attività pianificate, template alterati e accessi ai database associati. Quando il processo Adobe dispone di credenziali verso SMTP, database, storage o servizi esterni, tali segreti devono essere considerati potenzialmente esposti se emergono indicatori di esecuzione arbitraria. La segmentazione deve impedire al server di raggiungere liberamente l’intera rete aziendale e limitare le comunicazioni alle sole dipendenze necessarie. È inoltre opportuno conservare immagini del sistema e log prima della bonifica, perché il semplice aggiornamento può modificare file e timestamp utili all’analisi forense. La gestione ricorda gli interventi richiesti dopo le falle critiche in SonicWall, RabbitMQ, ShareFile, AWS e SAP, dove l’aggiornamento costituisce soltanto il primo passaggio e deve essere accompagnato da una verifica retrospettiva dell’attività. Adobe non segnala nel bollettino uno sfruttamento attivo confermato, ma il punteggio massimo, l’assenza di autenticazione e la disponibilità di un percorso remoto rendono rischioso attendere il normale ciclo di manutenzione.

AWS corregge un denial of service nel runtime Smithy per Rust

Tra i quattro avvisi AWS forniti, il bollettino 2026-067-AWS documenta CVE-2026-18140, una vulnerabilità nel crate aws-smithy-json utilizzato dai server generati attraverso Smithy-RS. Smithy è il sistema di definizione delle interfacce impiegato da AWS per generare client e server, mentre il runtime JSON gestisce la deserializzazione delle strutture ricevute nelle richieste. Nelle versioni fino alla 0.62.6, il percorso utilizzato per ignorare chiavi JSON sconosciute applica una ricorsione senza limite. Un aggressore remoto non autenticato può inviare una singola richiesta HTTP di piccole dimensioni contenente oggetti JSON profondamente annidati e provocare l’esaurimento dello stack, causando l’arresto del processo. L’impatto è quindi un denial of service remoto, non un’esecuzione arbitraria di codice, ma può risultare rilevante per API pubbliche, microservizi e piattaforme che utilizzano server generati con smithy-rs. La correzione è disponibile in aws-smithy-json 0.62.7 e non esistono workaround completi alternativi all’aggiornamento. Devono essere controllati anche fork, componenti derivati e dipendenze transitive, perché l’applicazione può utilizzare la libreria senza dichiararla direttamente nel manifest principale. L’episodio segue le vulnerabilità AWS e Cisco in AgentCore, Strands, ISE e RoomOS, che avevano già evidenziato il rischio concentrato nei framework di sviluppo e negli strumenti utilizzati per generare automaticamente codice o configurazioni. Nel bollettino AWS 2026-067 dedicato a CVE-2026-18140, Amazon raccomanda di aggiornare il runtime e qualsiasi implementazione derivata che incorpori il codice vulnerabile.

Quattro bollettini AWS impongono la revisione delle dipendenze

AWS ha pubblicato nello stesso intervallo anche i bollettini 2026-066-AWS, 2026-068-AWS e 2026-069-AWS. Le relative pagine devono essere verificate direttamente dagli amministratori che utilizzano SDK, librerie o soluzioni AWS interessate, perché l’impatto dipende dalle versioni incorporate nelle applicazioni e non soltanto dai servizi cloud gestiti. I bollettini AWS possono riguardare componenti open source distribuiti separatamente, SDK utilizzati in applicazioni locali, runtime inclusi nelle immagini container o soluzioni installate negli account dei clienti. La distinzione è essenziale: quando AWS corregge centralmente un servizio gestito non è richiesta un’azione, mentre una libreria inserita nella build rimane vulnerabile finché il cliente non aggiorna dipendenze, lockfile, immagini e artefatti già distribuiti. Le organizzazioni devono quindi associare ogni bollettino alla propria software bill of materials, verificare dipendenze dirette e transitive e ricostruire quali workload siano stati compilati con le versioni interessate. Nei cluster e nelle pipeline CI/CD non basta aggiornare il repository: immagini già presenti nei registry, funzioni serverless, layer Lambda e container in esecuzione devono essere ricostruiti e ridistribuiti. Un approccio analogo era necessario dopo le falle in WordPress, Fortinet, AWS e OpenSSL, dove la presenza di una patch upstream non garantiva automaticamente la protezione dei sistemi che incorporavano il componente.

Rails Active Storage legge file e segreti del server

CVE-2026-66066 interessa Active Storage, il componente di Ruby on Rails utilizzato per gestire allegati e upload, quando l’applicazione elabora immagini non fidate attraverso libvips. Un attaccante non autenticato può caricare un’immagine appositamente costruita e indurre la libreria ad accedere a file locali leggibili dal processo Rails. Il primo impatto è una lettura arbitraria di file, ma la gravità aumenta perché l’ambiente applicativo contiene frequentemente secret_key_base, master key, password dei database, credenziali di storage e token per servizi esterni. La sottrazione di secret_key_base permette di falsificare cookie di sessione, firmare identificatori e manipolare dati serializzati; in configurazioni vulnerabili, queste capacità possono essere concatenate fino all’esecuzione remota di codice sul server. Il problema interessa Active Storage precedente a 7.2.3.2, la serie 8.0 prima di 8.0.5.1 e la serie 8.1 prima di 8.1.3.1. Rails 6 può essere coinvolto quando Active Storage è stato configurato fuori dai valori predefiniti. Le applicazioni che utilizzano ImageMagick non risultano esposte a questo specifico vettore, mentre libvips è impiegato nelle immagini Docker ufficiali di Rails e in numerose installazioni Debian e Ubuntu. Gli sviluppatori devono aggiornare Rails e utilizzare libvips 8.13 o successivo; con ruby-vips 2.2.1 o versioni successive è possibile bloccare temporaneamente le operazioni non fidate attraverso VIPS_BLOCK_UNTRUSTED, ma per le release precedenti di libvips non esiste una mitigazione equivalente. La vulnerabilità mostra nuovamente come l’elaborazione automatica di file caricati possa trasformare un semplice allegato in un accesso ai segreti del backend, scenario simile alle catene descritte nelle patch urgenti per 7-Zip e WordPress wp2shell. Nell’advisory ufficiale del Rails Security Team su CVE-2026-66066 vengono richiesti aggiornamento, rotazione delle chiavi e verifica di ogni segreto accessibile al processo applicativo.

La rotazione dei segreti è obbligatoria dopo la patch Rails

Le organizzazioni non devono considerare conclusa la remediation dopo l’aggiornamento dei gem. Se un’applicazione vulnerabile accettava immagini da utenti esterni, occorre analizzare log degli upload, richieste insolite, errori di libvips e accessi ai file dell’applicazione. Devono essere ruotati secret_key_base, master key, password dei database, credenziali di Active Storage, token cloud e qualsiasi altro segreto leggibile dal processo. La rotazione della chiave Rails invalida sessioni e cookie firmati, ma è necessaria per impedire che un aggressore continui a generare dati considerati autentici dopo la correzione. Devono essere ricostruite anche immagini container e pipeline che mantengono versioni vulnerabili nei lockfile o nelle cache, verificando che i nodi di produzione abbiano effettivamente ricevuto la nuova release. I proof of concept pubblici riducono il tempo disponibile per intervenire e rendono insufficiente affidarsi soltanto al WAF, che può filtrare alcuni payload ma non sostituisce la correzione del componente. Le patch Adobe, AWS e Rails condividono quindi lo stesso problema operativo: il rischio non termina quando il vendor pubblica una versione corretta, ma soltanto quando l’organizzazione individua ogni istanza interessata, ridistribuisce gli artefatti e verifica che le credenziali potenzialmente raggiunte non siano ancora valide.