Atlassian sfruttata finisce nel KEV, AWS corregge Neptune e KVM

🛡️ Executive Summary

• CISA inserisce CVE-2026-21589 nel KEV, portando Atlassian dalla fase dei tentativi osservati alla conferma dell’exploitation attiva.
• AWS identifica CVE-2026-99999 nel percorso virtio-net/TAP di KVM: richiede privilegi nel guest, ma può colpire la memoria del kernel host.
• Amazon Neptune corregge CVE-2026-110812, vulnerabilità autenticata nel motore Gremlin che richiede permessi data-plane già disponibili.

CISA ha inserito CVE-2026-21589 nel catalogo delle vulnerabilità note come sfruttate, trasformando il caso Atlassian da rischio già osservato nei tentativi di attacco a priorità operativa confermata. Nello stesso giorno AWS ha pubblicato due bollettini che riguardano superfici completamente diverse: Amazon Neptune, dove un principal autenticato con permessi data-plane può far processare input non affidabile al motore Gremlin, e il percorso virtio-net/TAP del kernel Linux usato negli hypervisor KVM, dove un attore con privilegi nel guest può corrompere memoria dell’host. Il punto comune non è il vendor ma il livello di prova: exploitation confermata, accesso autenticato necessario e isolamento guest-host non sono condizioni equivalenti e richiedono priorità differenti.

Atlassian passa dai tentativi alla exploitation confermata nel KEV

CVE-2026-21589 è il caso che cambia più nettamente stato. La vulnerabilità interessa Bitbucket Data Center, Confluence Data Center, Jira Software e Jira Service Management Data Center, Bamboo, Crowd, Crucible e Fisheye e permette a un attaccante non autenticato di leggere file specifici presenti nella web application root quando ne conosce nome e percorso. L’avviso CISA del 15 ottobre la inserisce nel KEV sulla base di evidenze di sfruttamento attivo. Il delta rispetto alla situazione osservata pochi giorni prima è sostanziale: scansioni e tentativi sui honeypot non sono più l’unico segnale disponibile. CISA considera ora la falla sfruttata in attacchi reali e fissa per le agenzie federali statunitensi una scadenza di remediation al 18 ottobre 2026. Per gli amministratori la conseguenza è immediata: la patch non va più pianificata sulla sola severità teorica, ma sulla presenza di exploitation. Il fatto che l’attacco richieda la conoscenza del nome e del percorso del file riduce la libertà dell’aggressore, ma non annulla il rischio quando configurazioni e file sensibili seguono percorsi prevedibili.

Leggi anche: CISA e FBI esortano gli amministratori a correggere immediatamente Atlassian Confluence

Il presunto zero-day KVM ora ha CVE, versioni coinvolte e patch

Il secondo sviluppo chiude invece un’incertezza aperta sul fronte della virtualizzazione. Il 6 ottobre il possibile zero-day KVM associato al ricercatore Paulos Yibelo era stato descritto pubblicamente come un full VM escape, ma mancavano CVE, versioni coinvolte e una procedura di patching, motivo per cui il caso era stato trattato come vulnerabilità ancora sotto qualificazione. Il bollettino AWS 2026-137 identifica ora CVE-2026-99999 nel percorso virtio-net/TAP del kernel Linux e delimita il problema agli hypervisor KVM che utilizzano versioni non corrette del kernel dalla 4.4 alla 6.18. Un attore con accesso privilegiato all’interno di una macchina virtuale guest può inviare pacchetti costruiti per corrompere la memoria del kernel host, con possibile disclosure della memoria o denial of service. AWS precisa che i servizi gestiti Amazon EC2, Lambda e Fargate non sono interessati; il rischio riguarda chi gestisce autonomamente VM con virtio-net e KVM, compresi ambienti che utilizzano Firecracker. Amazon Linux 2 e Amazon Linux 2023 dispongono già dei kernel corretti e non esiste un workaround alternativo all’aggiornamento: dopo l’installazione dei pacchetti è necessario riavviare l’host, mentre le altre distribuzioni devono applicare gli aggiornamenti forniti dal rispettivo vendor.

Neptune espone il query engine ma richiede già accesso autenticato

Amazon Neptune presenta un profilo ancora diverso. CVE-2026-110812 nasce da un problema di deserializzazione di input non affidabile nel percorso graph-import di Gremlin collegato ad Apache TinkerPop e interessa le versioni Neptune dalla 1.2.0.0. Il bollettino AWS 2026-136 chiarisce che l’attacco richiede un principal già autenticato con permessi data-plane, cioè autorizzato a inviare query al database. In determinate condizioni una richiesta può indurre il query engine a processare input non attendibile in modo non sicuro e produrre attività non prevista all’interno del suo ambiente. AWS ha corretto il problema nelle versioni 1.4.7.1, 1.4.8.1 e 1.5.0.0 e raccomanda l’upgrade del cluster; chi ha abilitato l’auto minor version upgrade riceverà l’aggiornamento durante la successiva finestra di manutenzione. Fino ad allora la mitigazione indicata è applicare il minimo privilegio e concedere i permessi neptune-db soltanto a principal fidati. È un problema distinto dalla precedente vulnerabilità nel connettore Athena Federated Query per Neptune: allora il confine esposto era tra query e proprietà della funzione Lambda, qui il difetto riguarda il modo in cui il motore Gremlin tratta input non affidabile.

Continua con:

Cloudflare, KVM e Cisco espongono sandbox, host Linux e reti enterprise

Zero-day e vulnerabilità critiche tra VeloCloud, SharePoint, KVM, Defender e D-Link

La priorità reale nasce da exploit status, privilegi e confine colpito

I tre casi mostrano perché il CVSS, da solo, continua a essere insufficiente per ordinare il lavoro dei difensori. Atlassian viene prima perché esiste exploitation confermata e il vettore non richiede autenticazione; CVE-2026-99999 richiede invece privilegi già ottenuti dentro il guest, ma colpisce il confine di isolamento tra macchina virtuale e host e non dispone di workaround; Neptune necessita di accesso autenticato e può essere contenuto temporaneamente restringendo i principal autorizzati. Operativamente significa partire dall’inventario delle installazioni Atlassian Data Center ancora vulnerabili, verificare poi quali host self-managed eseguano KVM con virtio-net su kernel compresi nell’intervallo indicato e infine incrociare versione dei cluster Neptune e policy IAM. La stessa distinzione è emersa nei precedenti bollettini AWS dedicati a Firecracker, Athena e componenti utilizzati dai clienti: una vulnerabilità associata ad AWS non equivale automaticamente a una compromissione dei servizi gestiti, perché responsabilità e remediation cambiano in funzione di chi controlla host, runtime e permessi. Il dato operativo più importante del 15 ottobre resta quindi il cambio di stato: Atlassian è ormai nel KEV, mentre Neptune e KVM hanno patch e prerequisiti chiari ma, sulla base dei bollettini AWS, non vengono presentati come vulnerabilità attivamente sfruttate.