CVE-2026-105312: bug nel Console Red Hat Kafka espone il control-plane a tenant non attendibili

Pubblicato il 20 ottobre 2026, CVE-2026-105312 è una vulnerabilità di privilege escalation nel Red Hat StreamsHub Console for Apache Kafka con CVSS 9.9. Un tenant Kubernetes con il solo permesso di creare una Console custom resource può iniettare un'immagine container arbitraria che l'operator esegue con privilegi cluster-wide sul control-plane Strimzi. Il bug non riguarda Kubernetes né Apache Kafka in sé: è nel management console operator. Per chi gestisce cluster multi-tenant, il rischio è concreto: l'isolamento tra namespace viene compromesso.

Come funziona l'attacco: da custom resource a control-plane

Le meccaniche sono lineari. Secondo shattered.io, "a tenant who can create one custom resource can take over Kafka control-plane objects across every namespace on the cluster". L'input malevolo passa attraverso il campo spec.containers.api.spec.image di una Console custom resource: il tenant con permesso create o update vi scrive il riferimento a un'immagine container arbitraria. L'operator, senza validazione aggiuntiva, la distribuisce in un pod nuovo.

Il pod gira con un ServiceAccount il cui binding è cluster-scoped. Strix.ai documenta i permessi effettivi: get, list, watch su tutti gli Strimzi CRDs (Kafka, KafkaConnect, KafkaMirrorMaker2, KafkaTopic, KafkaUser e altri), patch su Kafkas e KafkaRebalances, più cluster-monitoring-view. L'attaccante legge il projected ServiceAccount token e ottiene accesso cross-tenant al control-plane Strimzi. Non è un leak di credenziali esterne: è l'operator stesso che materializza il privilege escalation.

La classificazione CWE-269 (Improper Privilege Management) è coerente con il pattern: il componente vulnerabile (Console operator) accetta input da un principal a basso privilegio e lo esegue con identità ad alto privilegio, senza intermediazione. È il classico confused deputy, ma con conseguenze cluster-wide su infrastruttura critica.

Perché il CVSS 9.9 con Scope Changed non è un dettaglio

Il vector CVSS 3.1 completo — confermato da shattered.io, strix.ai e Rapid7 — è CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L. Il punteggio base di 9.9 è eccezionale per un bug che richiede autenticazione (PR:L): l'attaccante deve avere un account nel cluster, anche se non privilegiato. L'accelerazione verso il massimo della scala arriva da S:C, Scope Changed.

Shattered.io spiega la metrica con chiarezza: "the Scope Changed flag deserves the most attention. It tells scoring teams that the vulnerable component and the impacted component sit in different security authorities". Nel contesto Kubernetes, questo significa che il namespace del tenant (una security authority) e il cluster-wide control-plane Strimzi (un'altra security authority) sono confinamenti che il bug attraversa senza autorizzazione. Non è un overflow di buffer che corrompe memoria locale: è un fallimento architetturale dei boundary di sicurezza in un sistema multi-tenant.

La combinazione AV:N/AC:L/UI:N indica che l'attacco è riproducibile via rete, con bassa complessità, senza interazione utente. Una volta ottenuto il permesso create su Console resources — che in un cluster multi-tenant può essere assegnato a team di sviluppo, CI/CD service account, o namespace admin — il resto è deterministico. La scarsa disponibilità (A:L) mitiga leggermente il punteggio, ma l'impatto su confidenzialità e integrità è massimo.

Chi è esposto e chi no

Il perimetro di rischio è circoscritto ma critico per chi cade dentro. Sono esposti i deployment multi-tenant dove tenant non attendibili — o account con privilegi limitati — hanno diritti create, update o patch su Console resources. Secondo shattered.io, "deployment single-tenant or with only admin managing Console resources NOT exposed to this specific path". Questo esclude i cluster dove l'operator è gestito esclusivamente dal team platform con accesso root-equivalente.

Il prodotto affetto è il Red Hat StreamsHub Console for Apache Kafka, noto anche come Streams for Apache Kafka Console. Il bug non è nello Strimzi core operator né in Apache Kafka: è nel management console operator che fornisce l'interfaccia UI/API per la gestione. Le versioni che correggono il difetto sono 0.12.10 e 0.14.2 per l'upstream StreamsHub Console, e Streams for Apache Kafka 3.2.2 per il downstream Red Hat. CVE Brief indica un fix documentato il 22 ottobre, ma le fonti primarie non verificano indipendentemente questa data.

Cosa fare adesso

Aggiornare alle versioni 0.12.10, 0.14.2 o Streams for Apache Kafka 3.2.2 secondo shattered.io.

Verificare nei cluster multi-tenant chi detiene i permessi create, update, patch su Console custom resources: limitare questi diritti ai soli account con necessità operativa documentata.

Rivedere i ClusterRoleBinding del ServiceAccount usato dal Console operator: il privilegio cluster-wide su Strimzi CRDs è funzionalmente richiesto dal design, ma la sua esposizione a pod la cui immagine è controllabile da tenant va trattata come surface attack critica.

Valutare se il deployment corrente sia effettivamente multi-tenant: se single-tenant con gestione admin-centralizzata, il path di attacco non si applica, ma la revisione dei permessi resta pratica di hygiene.

"The operator deploys this image into a pod whose ServiceAccount is bound via ClusterRoleBinding to a ClusterRole granting cluster-wide get/list/watch on all Strimzi CRDs (including KafkaUsers), patch on Kafkas/KafkaRebalances, and cluster-monitoring-view" — strix.ai advisory summary

Il pattern operator: un problema di design, non solo di codice

La lettura tecnica va oltre il singolo bug. CVE-2026-105312 è un caso studio nel pattern ricorrente degli operator Kubernetes con privilegi eccessivi che eseguono input utente. Il principio di least privilege viene violato a livello architetturale: l'operator ha bisogno di accesso cluster-wide per funzionare, ma il pod che materializza quell'accesso non dovrebbe essere influenzabile da tenant con privilegi inferiori.

Per team platform e architetti di sicurezza, la domanda è se il modello di threat assessment per operator custom resources sia adeguato. Il campo spec.containers.api.spec.image è tecnicamente un input di configurazione, ma funzionalmente è un vettore di code execution con identità privilegiata. La separazione tra chi può creare una CR e chi può scegliere l'immagine che gira nel pod risultante è spesso inesistente nei design operator. Red Hat ha corretto il bug, ma il pattern persiste in tutti gli operator Kubernetes con CR mutabili da tenant multipli.

L'EPSS stimato allo 0.3% da CVE Brief indica bassa probabilità di exploit di massa nel breve termine: il requisito di accesso autenticato a un cluster Kubernetes e la specificità del prodotto riducono la superficie per attacchi opportunistici. Questo non attenua l'impatto per gli obiettivi mirati: in un cluster multi-tenant con dati Kafka sensibili, il bug è un ponte diretto dal namespace isolato al control-plane critico.

Domande frequenti

Bastano i permessi di lettura per sfruttare il bug?

No. Secondo le fonti tecniche, è richiesto il permesso create o equivalente (update, patch) sulle Console custom resources. La sola lettura non attiva il path di attacco.

Il bug colpisce tutte le installazioni Strimzi?

No. Colpisce specificamente chi usa il Red Hat StreamsHub Console for Apache Kafka in deployment multi-tenant. Gli utenti di Strimzi core operator senza Console, o con Console in modalità single-tenant gestita da admin, non sono esposti a questo vettore.

Perché il CVSS è così alto con autenticazione richiesta?

Il flag Scope Changed (S:C) è il moltiplicatore critico. L'impatto non resta nel namespace del tenant: attraversa i boundary di sicurezza del cluster e colpisce risorse altrui. Con confidenzialità e integrità al massimo, il punteggio sale a 9.9 nonostante PR:L.

Fonti

• shattered.io
• strix.ai
• rapid7.com