ZDI-26-337: bug X.Org consente escalation a root…

La vulnerabilità CVE-2026-34003 nel X.Org Server consente privilege escalation locale a root tramite buffer overflow in CheckKeyTypes(). CVSS 7.8, patch disponibile.

Lo Zero Day Initiative di TrendAI ha pubblicato il 9 giugno 2026 l'advisory ZDI-26-337, documentando una vulnerabilità nel X.Org Server che permette l'escalation di privilegi da qualsiasi utente locale fino a root. La falla, tracciata come CVE-2026-34003, sfrutta un buffer overflow nella funzione CheckKeyTypes() del sottosistema XKB — il componente che gestisce le mappature tastiera nel display server. Con un punteggio CVSS 7.8 e vettore che richiede soli privilegi locali bassi, il bug riguarda praticamente ogni distribuzione Linux e sistema Unix-like con stack grafico X11 ancora in esecuzione, inclusi i deployment ibridi XWayland dove la transizione a Wayland non ha rimosso il codice vulnerabile.

Punti chiave

CVE-2026-34003 è un buffer overflow in CheckKeyTypes() del sottosistema XKB del X.Org Server, scoperto da Jan-Niklas Sohn in collaborazione con ZDI/TrendAI
L'attacco richiede solo accesso locale con privilegi bassi (CVSS v3.1: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) e porta a esecuzione di codice arbitrario come root
La patch upstream è verificabile nel commit b85b00dd su GitLab freedesktop.org, che aggiunge bound checking tramite _XkbCheckRequestBounds(); firma Olivier Fourdan (Red Hat), ack Peter Hutterer
Il CVE Record elenca advisory Red Hat RHSA-2026:10739 e successivi per oltre 30 versioni di RHEL, indicando superficie di attacco enterprise significativa

Il meccanismo: quando la mappatura tastiera diventa arma

Il difetto risiede nel modo in cui CheckKeyTypes() elabora le richieste dei client X11 relative ai tipi di tasto (key types). La funzione scorre in loop i dati inviati dal client senza verificare che rientrino nei limiti del buffer allocato: come documenta il commit di patch firmato da Olivier Fourdan, «The function CheckKeyTypes() will loop over the client's request but won't perform any additional bound checking to ensure that the data [...] a specifically crafted request may cause CheckKeyTypes() to read past the request data». Questa mancanza di validazione della lunghezza permette a un attaccatore di costruire un payload artificioso che, copiato nel buffer, sovrescrive strutture di memoria adiacenti e dirotta l'esecuzione.

L'advisory ZDI descrive la sequenza con precisione chirurgica: «The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a buffer». Il risultato finale non è un crash marginale ma una compromissione totale della macchina: «An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of root». Il vettore è strettamente locale — non c'è superficie di attacco remota — ma in ambienti multiutente, server con accesso shell, terminali pubblici o container condivisi, questa condizione è ordinaria.

La timeline: quattro mesi di incubazione coordinata

La vulnerabilità è stata riportata al vendor il 19 febbraio 2026 e ha seguito il processo di disclosure coordinata standard dello Zero Day Initiative. La pubblicazione pubblica è avvenuta il 9 giugno 2026, dopo circa quattro mesi di sviluppo patch e distribuzione anticipata ai vendor downstream. Questa finestra riflette la complessità del sottosistema grafico: modifiche a XKB impattano l'interazione hardware-software di tutti i dispositivi di input, richiedendo test estesi prima del rilascio.

Il ricercatore Jan-Niklas Sohn, che ha lavorato con il programma ZDI, riceve credito esplicito tanto nel CVE Record («Red Hat would like to thank Jan-Niklas Sohn (TrendAI Zero Day Initiative)») quanto nel commit upstream («Jan-Niklas Sohn working with TrendAI Zero Day Initiative»). La duplice attribuzione, su fonti indipendenti e convergenti, esclude ambiguità sulla paternità della scoperta. La firma di Olivier Fourdan e l'ack di Peter Hutterer nel commit di patch confermano inoltre che la correzione è passata attraverso la review dei maintainers senior del progetto.

XWayland e il falso senso di sicurezza dei sistemi ibridi

Un aspetto critico, sottolineato dall'angolo analitico del dossier, riguarda i sistemi che hanno adottato Wayland come display server principale ma mantengono XWayland per la retrocompatibilità con applicazioni X11. XWayland è un server X11 completo che gira sotto Wayland: eredita l'intero codice del X.Org Server, inclusa la funzione CheckKeyTypes() e il sottosistema XKB. La transizione a Wayland, perciò, non elimina automaticamente questa superficie di attacco nei deployment ibridi.

Questo rende illusoria l'assunzione che «siamo su Wayland, quindi il problema non ci tocca». Finché XWayland è attivo — e lo è in molte distribuzioni desktop per default, per supportare browser, IDE, giochi e software enterprise non ancora portati nativamente — il binario vulnerabile rimane in esecuzione con i privilegi necessari a gestire l'input grafico. La questione non è teorica: il CVE Record elenca advisory Red Hat per RHSA-2026:10739 e successivi, coprendo oltre 30 versioni di Red Hat Enterprise Linux, tipicamente deployment dove Wayland è disponibile ma XWayland è pervasivo.

Cosa fare adesso

Le seguenti azioni derivano direttamente dai fatti documentati nel dossier:

Verificare la presenza del commit b85b00dd nella build del X.Org Server o di XWayland in uso; la patch aggiunge la chiamata a _XkbCheckRequestBounds() nei loop di CheckKeyTypes()
Consultare gli advisory Red Hat RHSA-2026:10739 e successivi per le versioni RHEL specifiche del proprio deployment, dato che il CVE Record li elenca come copertura ufficiale
Confermare che l'aggiornamento del sistema grafico includa la correzione emessa da X.Org, citata nell'advisory ZDI come disponibile
In ambienti multiutente o con accesso shell non privilegiato, trattare l'aggiornamento del display server come priorita di sicurezza equivalente a quella del kernel, dato il vettore locale con impatto totale sulla confidenzialita, integrita e disponibilita

Perché il display server è ancora terra di nessuno

Il bug ZDI-26-337 illumina una contraddizione strutturale della sicurezza Linux: i sottosistemi grafici, pur essendo eseguiti con privilegi elevati e interagendo direttamente con l'hardware, ricevono attenzione di sicurezza inferiore rispetto al kernel o allo stack di rete. Il codice X11 è legacy decennale, maturo nella funzionalità ma con debiti di audit moderni. La funzione CheckKeyTypes() esiste da tempo sufficiente a essere considerata «stabilizzata», eppure un controllo di bounding elementare mancava fino a questa correzione.

La persistenza di XWayland amplifica il problema: permette di posticipare la migrazione completa delle applicazioni, ma duplica la superficie di attacco senza duplicare la visibilità di sicurezza. Le organizzazioni che hanno investito nella transizione a Wayland credendo di chiudere il capitolo X11 devono ora verificare se XWayland è effettivamente patchato, non semplicemente «presente». Il display server resta, di fatto, un confine permeabile tra userland e privilegi di sistema — e questo bug dimostra che il confine si difende con il bound checking, non con l'architettura presunta.

Domande frequenti

La vulnerabilità è sfruttabile da remoto?
No. Il vettore CVSS è AV:L (Attack Vector: Local). Serve accesso locale alla macchina con privilegi utente, anche minimi.

Se il mio sistema usa Wayland, sono protetto?
Non necessariamente. Se è attivo XWayland per la compatibilità con applicazioni X11, il codice vulnerabile è in esecuzione. Il dossier non specifica versioni di XWayland interessate: verificare manualmente la presenza della patch.

Quanto è grave il punteggio CVSS 7.8?
È classificato HIGH. Con requisiti di attacco minimi (locale, privilegi bassi, nessuna interazione utente) e impatto massimo su confidenzialità, integrità e disponibilità, rappresenta una priorità di patching elevata.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti