AWS corregge due falle: root su FPGA Developer Kit e command injection in CodeCatalyst

🛡️ Executive Summary

• CVE-2026-85028 colpisce AWS FPGA Development Kit prima della 2.3.4 e può permettere a un utente locale di eseguire codice con privilegi root.
• CVE-2026-85012 interessa CodeCatalyst blueprints SDK fino alla 0.3.155: un utente con permessi di commit può iniettare comandi durante la resynthesis.
• Il servizio gestito Amazon CodeCatalyst non richiede interventi: AWS applica validazione server-side. Devono invece aggiornare i consumatori diretti dei pacchetti vulnerabili.

Amazon Web Services corregge due vulnerabilità classificate come Important che interessano strumenti destinati agli sviluppatori, ma con condizioni di sfruttamento profondamente differenti. CVE-2026-85028 riguarda AWS FPGA Development Kit e consente a un utente locale di sfruttare un file temporaneo prevedibile per arrivare all’esecuzione di codice con privilegi root. CVE-2026-85012 interessa invece il framework open source dei blueprint di Amazon CodeCatalyst e permette a chi possiede già il diritto di effettuare commit in un repository di inserire metacaratteri shell in un file di progetto e far eseguire comandi arbitrari durante la resynthesis. In entrambi i casi AWS ha già pubblicato versioni corrette, senza segnalare sfruttamento attivo.

CVE-2026-85028 sfrutta un file prevedibile in /tmp per arrivare a root

Il bollettino AWS 2026-096 riguarda AWS FPGA Development Kit, toolkit hardware-software utilizzato per sviluppare acceleratori destinati alle schede ad alte prestazioni delle istanze Amazon EC2 F2. Nelle versioni precedenti alla 2.3.4, il componente di installazione degli strumenti di gestione FPGA scrive la funzione allow_non_root nel file temporaneo prevedibile /tmp/sdk_root_env.exp. Il problema nasce dal fatto che la directory temporanea è scrivibile globalmente: un utente locale può predisporre contenuto shell manipolato nel percorso atteso e attendere che la procedura di installazione, dopo avere elevato i propri privilegi, legga quel file. Il risultato può essere esecuzione arbitraria di codice come root. Non si tratta quindi di una RCE accessibile direttamente dalla rete né di una vulnerabilità sfruttabile senza accesso precedente alla macchina: l’attaccante deve già poter operare localmente sul sistema e riuscire a intervenire sul percorso temporaneo utilizzato dal processo privilegiato. Il meccanismo appartiene alla stessa famiglia di problemi di trust boundary che negli ambienti di sviluppo possono trasformare un accesso limitato in un’escalation molto più grave, come già emerso nelle precedenti vulnerabilità AWS che coinvolgevano strumenti di sviluppo e processi di build.

Leggi anche: AWS e Cisco correggono falle in agenti AI, ISE e piattaforme RoomOS

AWS rimuove completamente il passaggio attraverso il file temporaneo vulnerabile

La correzione è disponibile in AWS FPGA Developer Kit 2.3.4. AWS non si limita a modificare i permessi del file temporaneo: elimina il codice che scriveva allow_non_root in /tmp/sdk_root_env.exp e fa in modo che gli strumenti SDK importino direttamente la funzione da shared/bin/set_common_functions.sh. In questo modo viene eliminato alla radice il passaggio attraverso un percorso temporaneo prevedibile e modificabile da altri utenti locali. AWS raccomanda di aggiornare all’ultima versione e richiama esplicitamente anche chi mantiene fork o codice derivato, perché una copia del vecchio comportamento può continuare a essere vulnerabile anche se il repository principale è stato corretto. Per chi non può installare immediatamente la 2.3.4, il workaround consiste nel rimuovere o commentare da sdk_setup.sh e install_fpga_mgmt_tools.sh le righe che fanno riferimento al file /tmp/sdk_root_env.exp. Il punto operativo è quindi verificare non soltanto la versione dell’SDK principale, ma anche eventuali pipeline interne che abbiano incorporato o modificato gli script precedenti.

CVE-2026-85012 trasforma il file .ownership-file in una command injection

Il secondo avviso, AWS 2026-095, riguarda CVE-2026-85012 nel pacchetto npm open source @amazon-codecatalyst/blueprints.blueprint, framework utilizzato dagli autori dei blueprint di Amazon CodeCatalyst per generare progetti software. Il problema interessa le versioni fino alla 0.3.155 e si manifesta durante la fase di resynthesis, quando il framework legge il file .ownership-file già presente nel progetto per stabilire quali file possano essere modificati da un blueprint. Nelle entry che utilizzano una strategia di merge [local], il campo owner veniva passato a un comando del sistema operativo attraverso una shell senza adeguata validazione. Un utente autorizzato a effettuare commit nel repository poteva quindi inserire metacaratteri shell in quel campo e far eseguire comandi arbitrari nell’ambiente incaricato della resynthesis, con i privilegi e le credenziali disponibili a quel processo. Il rischio è particolarmente rilevante negli ambienti CI/CD, dove il processo di build può disporre di token repository, credenziali cloud o accessi di deployment. La superficie richiama i problemi già osservati nelle compromissioni npm capaci di trasformare workstation e pipeline di build in punti di raccolta delle credenziali, pur trattandosi qui di una vulnerabilità e non di un pacchetto deliberatamente malevolo.

Il servizio Amazon CodeCatalyst non è vulnerabile allo stesso scenario

AWS introduce però una distinzione fondamentale. Gli utenti del servizio gestito Amazon CodeCatalyst non devono effettuare alcuna azione. La resynthesis eseguita dalla piattaforma avviene in un ambiente isolato per singolo progetto, con credenziali circoscritte, e il servizio applica una validazione server-side che rifiuta i comandi associati alle strategie [local] quando non rispettano una forma consentita. Questa protezione viene applicata anche ai blueprint pubblicati con versioni anteriori alla 0.3.156. La vulnerabilità interessa invece chi consuma direttamente il pacchetto npm open source al di fuori delle protezioni fornite dal servizio. In questi ambienti AWS specifica che l’aggiornamento è l’unica mitigazione: il file .ownership-file è una parte normale del progetto e la strategia vulnerabile non richiede configurazioni aggiuntive particolari per attivarsi. La release 0.3.156 elimina l’interpretazione shell del campo owner, esegue direttamente il comando e rifiuta valori che non rispettano una allowlist. È un intervento concettualmente simile alle correzioni già necessarie per command injection e validazione insufficiente negli strumenti AWS destinati agli sviluppatori: il confine di sicurezza deve essere applicato prima che dati controllabili dal repository raggiungano una shell o un processo privilegiato.

Continua con:

• CISA mette PaperCut nel KEV e AWS corregge una RCE critica in OpenSearch
• WordPress, Fortinet, AWS e OpenSSL colpiti da nuove vulnerabilità critiche

Le due falle colpiscono soprattutto il confine tra codice fidato e ambiente privilegiato

CVE-2026-85028 e CVE-2026-85012 non risultano indicate da AWS come vulnerabilità sfruttate attivamente, e nessuna delle due rappresenta un accesso remoto non autenticato ai servizi cloud. Il rischio nasce invece dal modo in cui ambienti di sviluppo e installazione attribuiscono fiducia a input controllabili da utenti con privilegi inferiori. Nel primo caso un file in una directory temporanea viene letto dopo l’elevazione a root; nel secondo un valore proveniente dal repository raggiunge una shell durante una fase automatizzata della build. Le priorità operative sono quindi chiare: AWS FPGA Development Kit deve essere portato almeno alla 2.3.4, mentre i consumatori diretti del pacchetto CodeCatalyst blueprints devono utilizzare almeno la 0.3.156. Per Amazon CodeCatalyst come servizio gestito AWS non richiede interventi. Le due correzioni ricordano soprattutto che nelle software factory moderne il perimetro non coincide più con la sola applicazione: script di installazione, repository, SDK e pipeline CI/CD possono diventare punti di escalation quando eseguono input controllabili con privilegi superiori a quelli dell’utente che li ha forniti.