CISA allarga il KEV, Elementor crea admin e AWS corregge Kiro e pgcollection

🛡️ Executive Summary

• CISA amplia il KEV con vulnerabilità già sfruttate contro prodotti enterprise tra cui WSO2, Adobe Commerce, SharePoint e RouterOS.
• Elementor 4.3.0 e 4.3.1 espongono WordPress a CSRF capace di creare un nuovo amministratore tramite un singolo link.
• AWS corregge Kiro IDE e pgcollection: un workspace malevolo può influenzare configurazioni globali, mentre PostgreSQL rischia RCE da utente autenticato.

Il nuovo ciclo di vulnerabilità del 25 settembre separa nettamente ciò che richiede una patch immediata da ciò che deve entrare rapidamente nella normale gestione del rischio. CISA aggiorna il catalogo KEV con falle già sfruttate in attacchi, Elementor corregge una CSRF capace di trasformare il clic di un amministratore WordPress nella creazione di un secondo account con pieni privilegi e AWS pubblica due bollettini su Kiro IDE e pgcollection. I prodotti sono molto diversi, ma il denominatore comune è preciso: autenticazione, autorizzazione e trust boundary vengono aggirati quando un componente privilegiato accetta come affidabile input che proviene da una sorgente controllabile dall’attaccante.

CISA porta nuovi exploit nel KEV e cambia la priorità di patching

Le nuove aggiunte pubblicate da CISA il 25 settembre e il secondo aggiornamento dello stesso giorno trasformano vulnerabilità già note in problemi di priorità operativa perché l’ingresso nel Known Exploited Vulnerabilities Catalog presuppone evidenze di sfruttamento reale. Tra i prodotti al centro dell’ultima sequenza figurano WSO2, Adobe Commerce, Microsoft SharePoint e MikroTik RouterOS, con vettori molto differenti: bypass di autenticazione, autorizzazioni errate, code injection e aggiramento di workflow pre-authentication. Il dato decisivo non è quindi il CVSS ma l’exploitation, perché una vulnerabilità teoricamente meno grave ma già utilizzata contro sistemi esposti assume una priorità superiore a una CVE critica rimasta confinata alla disclosure. Il caso era già evidente nel precedente aggiornamento KEV dedicato a WSO2 e Adobe Commerce, dove CVE-2026-5430 era passata da bypass dell’autenticazione JWT a rischio operativo e CVE-2026-71362 aveva portato nuovamente Adobe Commerce e Magento dentro una sequenza di exploitation reale. Anche SharePoint arriva da mesi di pressione: le precedenti catene on-premises avevano già mostrato come authentication bypass ed esecuzione di codice possano concatenarsi sui server Microsoft. Per gli amministratori la conseguenza è semplice: le nuove voci KEV devono uscire dal normale calendario di manutenzione ed entrare nella gestione urgente degli asset esposti.

Leggi anche: Elementor Pro sotto attacco con oltre 190.000 tentativi di exploit

Elementor trasforma un link in un nuovo amministratore WordPress

Il problema più immediato sul fronte WordPress è CVE-2026-62062, una vulnerabilità CSRF con CVSS 8,8 che interessa esclusivamente Elementor 4.3.0 e 4.3.1 ed è stata corretta nella 4.3.2. Secondo il report tecnico originale di Patchstack, il componente Editor Events disabilita la protezione CSRF del REST API di WordPress quando trova la stringa elementor/v1/events/ nella request URI. Il problema nasce perché il controllo viene eseguito prima che WordPress abbia realmente risolto la route e utilizza un valore nel quale è presente anche la query string controllata dal client. La conseguenza va oltre un singolo endpoint di Elementor. Un aggressore può inserire quella stringa come parametro in una richiesta destinata ad altre REST API e indurre un utente autenticato a eseguire azioni consentite dal proprio account. Nel caso di un amministratore, un singolo collegamento può creare un secondo account administrator controllato dall’attaccante, senza JavaScript, form o pagina malevola dedicata. Il payload può quindi arrivare via email, chat o commento. Elementor 4.3.2 corregge il difetto verificando la route REST effettivamente risolta anziché cercare una sottostringa nell’URI. Il caso è particolarmente rilevante perché Elementor era appena uscito da un’altra crisi: CVE-2026-32475 in Elementor Pro aveva consentito il caricamento di file PHP ed era passata rapidamente a centinaia di migliaia di tentativi di exploit. Inoltre WordPress ha appena introdotto controlli più aggressivi sugli aggiornamenti dei plugin, segnale di una supply chain nella quale la velocità di distribuzione deve ormai convivere con verifiche di sicurezza molto più strette.

Kiro IDE espone il confine tra repository e configurazione globale

AWS corregge invece CVE-2026-95985 in Kiro IDE, con tutte le versioni precedenti alla 1.0.242 interessate. Il bollettino AWS 2026-117 descrive un problema nel file write tool dell’IDE agentico: quando l’agente lavora dentro un workspace non affidabile, un repository costruito ad arte può inserire istruzioni nel contesto e portare Kiro a modificare percorsi di configurazione globali caricati automaticamente. L’effetto potenziale comprende l’esecuzione di comandi arbitrari, ma richiede che l’utente interagisca con l’agente all’interno del repository preparato dall’aggressore. Il punto architetturale è importante perché il workspace dovrebbe essere un dominio a fiducia ridotta, mentre ~/.kiro su macOS e Linux o %USERPROFILE%\.kiro su Windows appartengono alla configurazione persistente dell’utente. Consentire all’agente di attraversare quel confine significa trasformare contenuto proveniente dal progetto in modifica dello stato globale. AWS raccomanda l’aggiornamento almeno alla 1.0.242 e, per chi abbia utilizzato versioni precedenti con repository non affidabili, la verifica delle directory globali alla ricerca di file non riconosciuti. Non è il primo problema di questa classe. Kiro era già comparso nelle vulnerabilità AWS di settembre per esfiltrazione dei dati del workspace e problemi legati alla configurazione scritta dagli agenti e precedentemente per esecuzione di binari provenienti da directory di progetto malevole. La ricorrenza mostra che il problema non è il modello AI in sé, ma la quantità di privilegi che il runtime concede all’agente quando interpreta contenuti non attendibili.

pgcollection porta una type confusion fino all’esecuzione di codice

Il secondo bollettino AWS riguarda CVE-2026-96883 nella versione open source di pgcollection, estensione PostgreSQL utilizzata per gestire strutture icollection. Il security bulletin AWS 2026-118 attribuisce la vulnerabilità alla logica di coercizione dei tipi: richiedere un valore memorizzato utilizzando un tipo incompatibile con quello originario può portare l’estensione a interpretarne erroneamente la rappresentazione interna. Un utente database autenticato può così causare il crash del backend PostgreSQL o arrivare all’esecuzione arbitraria di codice. Sono vulnerabili pgcollection 2.0.0 fino alla 2.1.1, mentre la correzione è inclusa nella 2.1.2. AWS specifica però un dettaglio fondamentale per delimitare correttamente l’esposizione: gli attuali clienti Amazon RDS for PostgreSQL e Amazon Aurora PostgreSQL non sono interessati perché i servizi distribuiscono la versione 1.1.1, precedente all’introduzione del bug. Il rischio riguarda quindi chi ha scaricato le release vulnerabili dal repository AWS, le ha compilate e installate autonomamente nei propri ambienti PostgreSQL.

Continua con:

PostgreSQL e AWS correggono falle tra RCE, MCP e infrastrutture cloud

CISA amplia il KEV mentre GitLab, Artifactory e ScreenConnect finiscono sotto attacco

Exploitation e trust boundary decidono cosa patchare prima

La sequenza non deve essere letta come una classifica dei CVSS. Le vulnerabilità già inserite nel KEV vengono prima perché lo sfruttamento non è più ipotetico; Elementor segue immediatamente per diffusione del plugin, semplicità del vettore e possibilità di ottenere un account amministrativo attraverso l’interazione di una vittima privilegiata. Kiro e pgcollection restano importanti, ma possiedono prerequisiti più stringenti e AWS non segnala exploitation attiva nei due bollettini. La priorità operativa deriva quindi dall’intersezione tra esposizione, privilegi richiesti, interazione dell’utente e presenza di attacchi osservati. Il filo comune resta però lo stesso: un componente privilegiato accetta come affidabile qualcosa che non dovrebbe esserlo, che sia un JWT, una route REST, un repository agentico o una rappresentazione di tipo nel database. È su questi confini, più che sul numero assoluto di CVE, che continua a rompersi la sicurezza delle piattaforme moderne.