Adobe decompiled? Cosa rivela davvero il caso ArtCraft sulla sicurezza

Che cosa è successo davvero con Adobe decompiled?

La storia chiamata “Adobe decompiled” non riguarda, per quanto emerge dalle fonti disponibili, la decompilazione della suite Adobe, ma un progetto che prova a ricreare da zero strumenti creativi simili usando codice scritto in Rust e assistenza dell’intelligenza artificiale.

All’inizio di ottobre 2026 ha iniziato a circolare sui social una notizia sensazionale: qualcuno avrebbe decompilato Photoshop, Premiere e le altre applicazioni Adobe, riscrivendole in Rust e pubblicandole come software open source. Il messaggio ha attirato rapidamente l’attenzione perché combina tre temi che interessano molto la comunità tecnologica: AI generativa, software proprietario e alternative gratuite.

Il progetto esiste davvero e si chiama ArtCraft. Il suo sito presenta sette applicazioni dedicate, tra le altre cose, a modifica delle immagini, grafica vettoriale, video, fotografia, PDF ed editoria. La distinzione fondamentale è che il progetto dichiara di sviluppare queste applicazioni da zero, non di distribuire il codice originale di Adobe. Inoltre, le applicazioni hanno livelli di maturità differenti: alcune sono indicate come versioni alpha, altre sono ancora in sviluppo. Non è quindi corretto presentarle come sostituti completi e già equivalenti alla Creative Cloud. citeturn634738view3turn634738view1

Da un punto di vista della cybersecurity, il caso è interessante proprio perché la prima versione della storia era più spettacolare della realtà. Non serve che un software proprietario venga davvero decompilato perché emergano questioni importanti su sicurezza, fiducia e velocità di sviluppo assistito dall’AI.

Che cosa raccontano le diverse fonti?

Le fonti raccontano una vicenda in cui un progetto reale è stato descritto con una formula tecnica fuorviante, mentre le sue caratteristiche di sicurezza richiedono verifiche separate dalla narrazione virale.

1. Il post virale: una conclusione troppo rapida

Il 7 ottobre, James O'Malley ha pubblicato su Bluesky un messaggio secondo cui qualcuno avrebbe decompilato la suite Adobe e ricostruito le applicazioni in Rust. La formulazione ha contribuito a rendere virale la notizia, ma non dimostrava che fosse stato recuperato o riutilizzato il codice proprietario di Adobe. Un post molto condiviso può segnalare una notizia da approfondire; non sostituisce una verifica tecnica. citeturn634738view2

2. Tom's Hardware: il progetto e i suoi limiti

L'articolo di Tom's Hardware Italia descrive sette applicazioni sviluppate con assistenza di Claude Opus 5.5 e distribuite con licenze open source dichiarate MIT e Apache-2.0. Riporta anche la scelta di riprodurre interfacce e scorciatoie familiari, per ridurre la curva di apprendimento, e segnala dubbi sulla completezza delle funzioni e sulla qualità del codice prodotto rapidamente. Sono elementi utili per comprendere il progetto, ma non equivalgono a un audit indipendente della sicurezza di ogni applicazione. citeturn634738view1

3. Clear Press: la correzione della narrazione

L'analisi pubblicata da Clear Press l'8 ottobre mette al centro la differenza tra decompilare un programma esistente e realizzare un'implementazione alternativa. Evidenzia anche un problema di comunicazione: la versione più clamorosa della storia si è diffusa prima che le precisazioni tecniche diventassero altrettanto visibili. È un promemoria utile per chi lavora nella sicurezza: anche una comunità tecnologica può amplificare una ricostruzione non verificata quando questa conferma ciò che vorrebbe fosse vero. citeturn634738view0

4. Il sito ArtCraft: che cosa dichiara il progetto

La pagina ufficiale presenta le applicazioni come strumenti open source scritti da zero in Rust, utilizzabili localmente e, per alcune, anche nel browser. Un dettaglio importante per la sicurezza è la possibilità dichiarata di controllarle tramite riga di comando, canale JSON e server MCP, cioè un'interfaccia che può permettere agli agenti AI di interagire con strumenti esterni. Questa scelta apre possibilità interessanti per l'automazione, ma rende essenziale verificare quali operazioni siano consentite e con quali autorizzazioni. Le dichiarazioni del sito descrivono l'intento del progetto, non costituiscono una certificazione di sicurezza. citeturn634738view3

La conclusione dell'analisi è semplice: ArtCraft è un progetto concreto da valutare per ciò che offre, ma la storia della suite Adobe “decompilata” non va trattata come un fatto tecnico accertato.

Decompilazione, ricostruzione e AI: quali differenze contano?

La decompilazione cerca di ricostruire una rappresentazione leggibile del funzionamento di un programma a partire dal suo codice compilato, mentre una reimplementazione crea un nuovo programma che riproduce alcune funzionalità osservabili.

Sono attività differenti, con implicazioni tecniche e legali differenti. In una ricostruzione indipendente, gli sviluppatori possono partire da specifiche pubbliche, comportamenti osservabili e file di test, implementando poi nuove funzioni. L'obiettivo può essere simile a quello di un prodotto commerciale, senza che il codice sorgente originale sia stato recuperato.

L'AI generativa può accelerare alcune fasi di questo lavoro: generare codice, creare test, spiegare errori, proporre strutture software e ripetere cicli di correzione. Non elimina, però, il bisogno di progettazione, revisione e validazione. Un'applicazione che apre un file di esempio non è necessariamente compatibile con tutti i documenti reali; un menu che mostra una funzione non dimostra che quella funzione sia implementata correttamente.

Anche il linguaggio di programmazione va interpretato con attenzione. Rust offre caratteristiche utili per ridurre alcune classi di errori di gestione della memoria, ma non rende automaticamente sicura un'applicazione. Restano possibili problemi di autorizzazione, validazione degli input, gestione delle credenziali, dipendenze vulnerabili e logica applicativa.

La domanda corretta, quindi, non è «è stato ricreato Photoshop?», ma «che cosa è stato effettivamente implementato, come viene verificato e quali rischi introduce quando lo installiamo o lo colleghiamo ad altri strumenti?».

Come funziona il rischio, passo dopo passo?

Il rischio nasce quando un software nuovo, generato o accelerato dall'AI, viene adottato prima che provenienza, comportamento e confini di autorizzazione siano stati verificati.

Un possibile percorso di esposizione si sviluppa così:

1. Il progetto attira attenzione. Una notizia virale promette strumenti gratuiti o un'alternativa immediata a un prodotto conosciuto. La pressione a provare qualcosa di nuovo può ridurre le verifiche preliminari.
2. L'utente cerca un download. Se non distingue il sito ufficiale da copie, fork o pagine imitate, può finire su un pacchetto alterato o su un programma diverso da quello annunciato.
3. Il programma ottiene accesso al dispositivo. Un editor può avere bisogno di leggere e salvare file; se viene eseguito con privilegi eccessivi, oppure gli vengono concessi accessi più ampi del necessario, l'impatto di un eventuale difetto aumenta.
4. Il software elabora documenti non fidati. Immagini, PDF, progetti e file multimediali provengono spesso da clienti, fornitori o collaboratori. Un parser difettoso o una dipendenza vulnerabile può trasformare un documento apparentemente innocuo in un punto d'ingresso.
5. L'automazione amplia il perimetro. Se l'applicazione è controllabile da un agente AI, una configurazione permissiva potrebbe consentire azioni indesiderate sui file o su altre risorse accessibili all'agente.
6. Il problema diventa operativo. Un incidente può coinvolgere documenti riservati, account, workstation o processi aziendali, a seconda dei permessi disponibili e delle vulnerabilità effettivamente presenti.

Questa sequenza descrive un modello di rischio, non afferma che ArtCraft sia malevolo o che siano state sfruttate vulnerabilità nel progetto. Per formulare simili conclusioni servirebbero prove tecniche specifiche.

Quali segnali aiutano a riconoscere un software da verificare?

I segnali più utili sono le incongruenze nella provenienza, le promesse non verificabili, le richieste di privilegi sproporzionate e l'assenza di informazioni sufficienti per valutare il programma.

Prima di installare un'alternativa a un software conosciuto, controlla questi aspetti:

• Provenienza poco chiara: il download arriva da un dominio diverso da quello del progetto o da un archivio pubblicato da un account non verificabile.
• Promesse assolute: il programma viene descritto come perfettamente equivalente a un prodotto professionale, senza limiti, test o documentazione verificabili.
• Richieste anomale: un editor grafico pretende privilegi amministrativi, disattivazione dell'antivirus o accesso a risorse non necessarie alle sue funzioni.
• Istruzioni sospette: per installarlo bisogna eseguire comandi opachi, uno script sconosciuto o un eseguibile ottenuto da una fonte non ufficiale.
• Automazioni poco trasparenti: non è chiaro quali file possa leggere, modificare o eliminare un agente AI collegato al programma.
• Aggiornamenti non verificabili: mancano un canale di distribuzione affidabile, informazioni sulle versioni o un processo comprensibile per correggere i problemi.
• Pressione a fidarsi: la popolarità sui social viene usata come prova di sicurezza, oppure le domande tecniche vengono liquidate come inutili.

Nessuno di questi segnali, preso isolatamente, dimostra la presenza di malware. Sono motivi per sospendere l'installazione e fare ulteriori verifiche.

Come difendersi: una checklist pratica per persone e aziende

La difesa più efficace consiste nel verificare la provenienza del software, limitare i permessi e provare le nuove applicazioni in un ambiente controllato prima di affidare loro dati importanti.

Per uso personale:

• Scarica il programma dal sito ufficiale o dal repository indicato dal progetto; controlla che dominio e autore corrispondano.
• Leggi le istruzioni di installazione e verifica quali componenti aggiuntivi vengono installati.
• Non disattivare antivirus, protezioni del sistema o controlli di sicurezza per far funzionare un programma sconosciuto.
• Mantieni aggiornati sistema operativo, browser e strumenti di protezione.
• Prova le prime versioni su file non sensibili e conserva copie di backup separate.
• Evita di concedere accessi amministrativi se non sono realmente necessari.

Per aziende e professionisti:

• Definisci una procedura di approvazione per nuovi software, comprese le applicazioni open source e quelle sviluppate con assistenza AI.
• Esegui le prove in sandbox o macchine virtuali, senza credenziali aziendali e senza accesso ai dati di produzione.
• Verifica dipendenze, aggiornamenti e provenienza dei pacchetti in base al rischio e alla criticità del software.
• Applica il principio del privilegio minimo: gli strumenti creativi non devono poter accedere automaticamente a ogni cartella, account o sistema.
• Controlla gli strumenti agentici. Limita i comandi disponibili, gli accessi ai file e le operazioni che possono modificare o cancellare dati; richiedi conferma per le azioni ad alto impatto.
• Definisci una procedura per le eccezioni, così che un dipendente non debba scegliere tra bloccare il proprio lavoro e installare un programma non verificato.
• Forma il personale a distinguere popolarità, funzionalità dichiarate e sicurezza dimostrata.

Per organizzare questi controlli può essere utile un security assessment, soprattutto quando i nuovi strumenti entrano nei flussi di lavoro di un'azienda.

Che cosa fare se hai già installato un programma sospetto?

Se hai installato un'applicazione di provenienza dubbia, la priorità è ridurre l'esposizione, preservare le informazioni utili e verificare se il dispositivo o gli account siano stati compromessi.

Procedi con calma:

1. Smetti di usare il programma e non aprire altri file al suo interno.
2. Se sospetti un'intrusione attiva, disconnetti il dispositivo dalla rete seguendo, in azienda, la procedura di risposta agli incidenti. Non cancellare subito tutto: potresti eliminare elementi utili alle verifiche.
3. Avvisa il referente IT o il responsabile della sicurezza, se il dispositivo contiene dati aziendali o accede a servizi di lavoro.
4. Esegui una verifica con strumenti di sicurezza affidabili e controlla applicazioni installate, processi insoliti e modifiche recenti al sistema.
5. Da un dispositivo considerato sicuro, proteggi gli account potenzialmente esposti. Cambia le password coinvolte e revoca sessioni o token sospetti; abilita l'autenticazione a più fattori dove disponibile.
6. Valuta i dati accessibili al programma. Se poteva leggere documenti riservati, credenziali o dati personali, coinvolgi i responsabili competenti per stabilire se sia necessario notificare un incidente.
7. Reinstalla o ripristina il dispositivo solo dopo una valutazione adeguata, utilizzando fonti ufficiali e copie di backup attendibili.

Non basta disinstallare un'applicazione per dimostrare che il dispositivo sia pulito. Se ci sono indizi concreti di compromissione, la risposta deve essere proporzionata a ciò che il software poteva fare e ai dati a cui aveva accesso.

La lezione per la cybersecurity: fiducia verificabile, non entusiasmo o paura

Il caso Adobe decompiled mostra che l'AI può rendere più accessibile la creazione di software complesso, ma non elimina il bisogno di verificare il codice, le autorizzazioni, la provenienza e il comportamento reale delle applicazioni.

Per le persone, il rischio pratico non è che ogni alternativa open source nasconda una minaccia. È installare un programma senza sapere chi lo distribuisce, quali permessi richiede e come tratta i propri file. Per le aziende, il problema è più ampio: gli strumenti sviluppati o orchestrati con AI possono entrare nei processi interni molto velocemente, prima che esistano controlli adeguati.

L'open source può offrire trasparenza e opportunità di verifica, ma la disponibilità del codice non garantisce che qualcuno lo abbia controllato in modo completo. Allo stesso modo, l'uso dell'AI non rende automaticamente insicuro un progetto: rende ancora più importante distinguere la velocità con cui si produce software dalla qualità con cui lo si valida.

Il mio consiglio è evitare sia l'allarmismo sia la fiducia automatica. Prima di adottare un nuovo strumento, chiediti chi lo mantiene, quali accessi richiede, quali test sono disponibili e come puoi limitarne l'impatto se qualcosa va storto.

Se vuoi valutare in modo concreto i rischi legati a nuovi software, strumenti AI e automazioni nella tua attività, puoi contattarmi per una consulenza di cybersecurity.