Red Hat Quay e AWS correggono quattro falle: immagini container, credenziali e privilegi a rischio

In sintesi

• Red Hat Quay espone immagini container private e chiavi di autenticazione. CVE-2026-123710, con CVSS 9,8, consente di compromettere la firma dei token del registry; CVE-2026-110697, con CVSS 9,9, permette di sottrarre credenziali tra tenant.
• AWS corregge una vulnerabilità SSRF nel registry dei server MCP. CVE-2026-125926 consente a un utente autenticato di raggiungere servizi interni attraverso il gateway. La versione corretta è 1.35.0.
• Un’altra falla AWS riguarda Aurora PostgreSQL. CVE-2026-126793 può consentire escalation di privilegi attraverso il wrapper Go. La correzione è disponibile dalla versione 2.0.3.

Red Hat e Amazon Web Services hanno pubblicato nuovi avvisi di sicurezza che interessano componenti fondamentali delle infrastrutture cloud: registry container, gateway per agenti AI e connessioni ai database PostgreSQL. Il problema più grave riguarda Red Hat Quay, dove due vulnerabilità critiche permettono rispettivamente di compromettere il sistema di firma dei token e sottrarre credenziali appartenenti ad altri tenant. Le conseguenze comprendono accesso a immagini private, modifica dei repository e possibile distribuzione di container compromessi nelle pipeline aziendali. Sul fronte AWS emergono invece CVE-2026-125926, una server-side request forgery nel registro dei server MCP, e CVE-2026-126793, un’escalation di privilegi nel driver AWS Advanced Go Wrapper utilizzato con Aurora PostgreSQL. Le quattro vulnerabilità riguardano prodotti differenti, ma evidenziano un problema comune: quando un componente infrastrutturale non verifica correttamente autorizzazioni e confini di fiducia, un accesso limitato può trasformarsi nel controllo di risorse molto più importanti.

Red Hat Quay, CVE-2026-123710 permette di controllare i token del registry

CVE-2026-123710 è una vulnerabilità critica con punteggio CVSS 9,8 che interessa il sistema di gestione delle chiavi di firma di Red Hat Quay, piattaforma utilizzata per archiviare, distribuire e gestire immagini container. Secondo il bollettino ufficiale Red Hat, un attaccante può ottenere un token anonimo attraverso il servizio di autenticazione e utilizzarlo impropriamente per aggiungere una propria chiave all’insieme delle chiavi considerate attendibili dal registry. Il difetto deriva da una verifica insufficiente dello scopo del token: il sistema controlla che sia firmato correttamente, ma non accerta che autorizzi effettivamente la rotazione delle chiavi.

Una volta registrata la chiave malevola, l’aggressore può creare token validi per qualsiasi repository, comprese le immagini private appartenenti ad altre organizzazioni. Questo permette non soltanto di leggere dati riservati, ma anche di modificare immagini e sostituire tag utilizzati dai sistemi di distribuzione. La chiave può essere configurata senza scadenza e sopravvivere ai riavvii. Cambiare password o rigenerare i token degli account robot non elimina questa persistenza, perché l’accesso dipende da una chiave considerata affidabile dal servizio. La possibilità di alterare immagini container richiama il precedente problema di Docker Hub che consentiva di impersonare utenti e modificare repository.

CVE-2026-110697 rompe l’isolamento tra tenant attraverso gli account robot

La seconda vulnerabilità, CVE-2026-110697, raggiunge CVSS 9,9 e riguarda il meccanismo utilizzato da Quay per elencare gli account robot, identità automatizzate impiegate da applicazioni e pipeline CI/CD. Come spiega il secondo advisory Red Hat, il software costruisce un’espressione SQL LIKE utilizzando nomi di namespace controllabili dagli utenti senza gestire correttamente i caratteri jolly. Il simbolo underscore può quindi corrispondere a caratteri presenti nei namespace di altre organizzazioni, consentendo di recuperare account robot non appartenenti al richiedente.

Un utente autenticato senza privilegi amministrativi può così ottenere token decifrati di altri tenant e utilizzarli per leggere, caricare o sovrascrivere immagini container. Il rischio interessa soprattutto registry condivisi tra più aziende o gruppi di sviluppo. Negli ambienti OpenShift, dove Quay viene utilizzato nella distribuzione delle immagini, l’appropriazione di queste credenziali può trasformarsi in un attacco alla supply chain software. Un’immagine alterata potrebbe essere distribuita successivamente dai normali sistemi di automazione, senza che la compromissione inizi direttamente sui server applicativi. Lo scenario è coerente con i precedenti problemi di Gitea che avevano esposto immagini container private, sebbene il meccanismo tecnico sia differente.

Leggi anche: Oltre 10.000 immagini Docker Hub espongono segreti aziendali e token AI

Red Hat distribuisce otto aggiornamenti e chiede di controllare le chiavi

Red Hat ha pubblicato build correttive per otto rami Quay 3: 3.9.28, 3.10.28, 3.12.24, 3.14.10, 3.15.9, 3.16.7, 3.17.7 e 3.18.3. Le schede CVE indicano anche componenti Quay 5 tra quelli interessati, ma la presenza delle correzioni nelle versioni 3.x non deve essere interpretata come una conferma automatica della disponibilità di aggiornamenti equivalenti per ogni altro ramo. Gli amministratori devono controllare gli errata applicabili alla propria distribuzione, comprese le installazioni standalone, quelle gestite tramite Quay Operator e i mirror registry OpenShift.

Per CVE-2026-123710, Red Hat raccomanda di limitare l’accesso all’endpoint /keys ai soli componenti interni attendibili, esaminare gli eventi di audit service_key_rotate e service_key_delete e identificare chiavi sconosciute prive di scadenza. L’eventuale eliminazione di una chiave sospetta non costituisce una soluzione definitiva senza aggiornamento, perché il difetto consentirebbe di registrarne un’altra. Per CVE-2026-110697, le misure temporanee comprendono limitazioni alla creazione dei namespace, rotazione delle credenziali robot potenzialmente esposte e controllo delle operazioni anomale sui repository. Quay.io risulta già corretto secondo Red Hat, mentre gli operatori di registry autonomi devono intervenire direttamente.

AWS corregge una SSRF nel registry dei server MCP

Il bollettino AWS 2026-180 riguarda CVE-2026-125926, una vulnerabilità di tipo server-side request forgery (SSRF) nella piattaforma open source mcp-gateway-registry, utilizzata per registrare e gestire server conformi al Model Context Protocol. Secondo AWS, un utente autenticato autorizzato a registrare o modificare un server può inserire un indirizzo upstream opportunamente costruito e indurre il gateway a effettuare richieste verso servizi raggiungibili dalla rete interna. In determinate condizioni, il gateway può restituire anche le risposte ottenute.

Il problema interessa le versioni dalla 1.0.3 alla 1.34.0 ed è corretto con mcp-gateway-registry 1.35.0. AWS precisa che l’aggiornamento introduce controlli sugli indirizzi registrati o modificati successivamente, ma non corregge automaticamente le configurazioni già memorizzate. Gli amministratori devono quindi verificare gli upstream esistenti, ricostruire eventuali modifiche sospette e controllare i privilegi IAM associati al servizio. Negli ambienti EC2 sono raccomandati anche IMDSv2 e restrizioni al traffico in uscita. Il problema si inserisce nella crescente attenzione verso i gateway MCP e le vulnerabilità che possono trasformare i servizi degli agenti AI in punti di accesso alle infrastrutture.

Aurora PostgreSQL, escalation di privilegi nel wrapper Go

Il secondo bollettino AWS, 2026-182, riguarda CVE-2026-126793, identificata nel componente AWS Advanced Go Wrapper utilizzato dalle applicazioni per collegarsi ai cluster Amazon Aurora PostgreSQL. La vulnerabilità interessa il rilevamento del dialetto PostgreSQL e può consentire a un utente autenticato del database, autorizzato a creare funzioni in uno schema presente nel percorso di ricerca di un altro utente, di ottenere i privilegi di quest’ultimo. In alcune configurazioni il bersaglio potrebbe appartenere anche al ruolo rds_superuser, con conseguenze particolarmente rilevanti per la gestione dei database.

Il problema interessa le release awssql/v2 dalla 2.0.0 alla 2.0.2 ed è stato risolto con la versione 2.0.3, distribuita il 29 luglio 2026. La pubblicazione dell’avviso di sicurezza risale invece al 12 novembre 2026: la vulnerabilità è quindi stata resa pubblica dopo la disponibilità della correzione. AWS raccomanda l’aggiornamento del wrapper e, quando non immediatamente possibile, la revoca dei privilegi di creazione sullo schema public agli utenti non attendibili, oltre alla restrizione dei permessi sugli altri schemi presenti nel search_path. Il problema non riguarda automaticamente tutte le installazioni di Aurora PostgreSQL, ma le applicazioni che utilizzano versioni vulnerabili del wrapper nelle condizioni indicate dal produttore.

La catena di fiducia diventa il bersaglio delle vulnerabilità cloud

Quay e AWS mostrano tre modalità differenti con cui un controllo insufficiente può compromettere l’infrastruttura. Nel registry Red Hat, una chiave di firma considerata attendibile permette di aggirare le autorizzazioni sui repository; nel servizio MCP, un indirizzo upstream non adeguatamente validato consente di raggiungere risorse interne; nel wrapper PostgreSQL, la gestione degli schemi può trasformare privilegi limitati in autorizzazioni superiori. Nessuno di questi problemi deve essere presentato automaticamente come una violazione già avvenuta: gli advisory descrivono vulnerabilità e possibili conseguenze, non dimostrano compromissioni generalizzate.

Continua con: AWS, le vulnerabilità MCP e i rischi delle autorizzazioni concesse agli agenti AI

Per le aziende, la priorità è aggiornare Quay, mcp-gateway-registry e Advanced Go Wrapper, ma anche verificare ciò che potrebbe essere rimasto compromesso prima delle patch: chiavi di firma persistenti, token robot, immagini già distribuite, indirizzi upstream salvati e privilegi eccessivi nei database. È questa la differenza tra correggere una vulnerabilità e ripristinare realmente la fiducia nell’infrastruttura. Una patch chiude il difetto; non sempre elimina gli accessi o le modifiche che il difetto potrebbe avere già consentito.