BlackBerry ha correto una vulnerabilità di esecuzione remota di codice nel sistema operativo QNX, resa pubblica il 13 agosto 2026 dall'advisory ZDI-26-566. La falla risiede in uno strumento di analisi diagnostica — la libreria libtraceparser per il parsing di file .kev (kernel trace event log) — ed esige l'interazione dell'utente per essere attivata. L'importanza del caso sta nella natura del bersaglio: non un servizio di rete esposto, ma una utility interna che gli sviluppatori e i tecnici di campo usano quotidianamente per leggere tracce di sistema.
- La vulnerabilità CVE-2026-40272, CVSS 7.0 HIGH, colpisce la funzione
decode()dilibtraceparserin BlackBerry QNX SDP 7.0, 7.1 e 8.0 - L'exploit richiede che l'utente apra un file KEV malevolo o visiti una pagina web preparata ad arte, secondo l'advisory ZDI
- Il meccanismo è un out-of-bounds write causato dalla mancata validazione della quantità di dati in ingresso, classificato come CWE-1284
- BlackBerry ha rilasciato un aggiornamento correttivo; il report iniziale al vendor risale al 31 marzo 2026
Il meccanismo: un buffer overflow nel lettore di tracce di sistema
Il difetto specifico affligge il parsing dei file KEV in QNX. Come documenta l'advisory ZDI-26-566: "The specific flaw exists within the parsing of KEV files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer." Il record CVE-2026-40272, pubblicato su cve.org, identifica la funzione vulnerabile come decode() all'interno della libreria traceparser, con una formulazione che ne chiarisce l'impatto: "Improper Input Validation in the decode() function of the traceparser library could allow an attacker with a corrupted kernel trace event log (.kev) file, to execute arbitrary code or cause a crash."
Il vettore è quindi un file di log di trace del kernel manipolato. L'attaccante deve indurre il bersaglio a elaborarlo con lo strumento di parsing. Non è un attacco che si propaga autonomamente: il CVSS v3.1 assegna AV:L (Attack Vector: Local) e UI:R (User Interaction: Required), pur conservando impatto alto su confidenzialità, integrità e disponibilità (C:H/I:H/A:H). La complessità dell'attacco è marcata come elevata (AC:H), coerente con la necessità di preparare un file KEV strutturalmente valido ma con payload corrotto.
Le condizioni di exploit: perché un file di log diventa pericoloso
L'advisory ZDI chiarisce le modalità di attivazione: "User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file." Questo apre due scenari. Il primo è diretto: l'utente apre un file .kev allegato a un messaggio o scaricato da una fonte apparentemente affidabile. Il secondo è indiretto: una pagina web ospita il file e lo fa elaborare al parser tramite una qualche interazione, magari sfruttando un helper application o un'associazione di file del sistema operativo.
La natura locale del vettore (AV:L) non equivale a un attaccante fisicamente presente: significa che l'esecuzione del codice avviene nel contesto del processo locale che analizza il file. L'attaccante può essere geograficamente remoto, ma il "dispositivo" che compie l'azione malevola è il file stesso, attivato dall'utente. Questa distinzione è tecnica ma rilevante per la valutazione del rischio: non si tratta di un servizio raggiungibile via rete, ma di un file che attraversa i confini di sicurezza camuffato da artefatto di diagnostica legittimo.
Perché la supply chain QNX amplifica il profilo di rischio
QNX è un sistema operativo real-time con presenza strutturale in settori dove la sicurezza ha implicazioni fisiche: automotive, dispositivi medici, controllo industriale, sistemi embedded critici. Non è un sistema di periferia: è il sistema operativo che gestisce freni, airbag, infusioni, turbine. Le versioni affette — SDP 7.0, 7.1 e 8.0 — coprono un arco di rilasci che attraversa diversi cicli di produzione di OEM e fornitori di primo livello.
L'angolo di attacco è insidioso proprio perché colpisce uno strumento di sviluppo e debug, non un componente di runtime. In ambienti embedded, i file di trace si scambiano tra team di sviluppo, fornitori di componenti, centri di assistenza e tecnici di campo. Un file KEV apparentemente generato durante un test su banco o un'anomalia in pista può essere trasferito via email, caricato su portali di supporto, incluso in pacchetti di aggiornamento firmware. La catena di fiducia che circonda questi artefatti è implicita: chi riceve un log di sistema assume che sia un output diagnostico, non un vettore di attacco.
Il dossier non documenta exploitation in-the-wild né fornisce dettagli su sistemi embedded specifici compromessi. Il rischio è quindi prospettico ma concreto: la combinazione di alta integrazione QNX in infrastrutture critiche e della circolazione routinaria di file di trace tra attori della supply chain crea una superficie di attacco sottovalutata, specialmente per operatori che non considerano gli strumenti di analisi come parte del perimetro di sicurezza.
La timeline della disclosure: quattro mesi e mezzo di coordinamento
La vulnerabilità è stata segnalata a BlackBerry il 31 marzo 2026. La disclosure coordinata è avvenuta il 13 agosto 2026, dopo circa quattro mesi e mezzo di gestione tra il ricercatore, Trend AI Zero Day Initiative e il vendor. Questo arco temporale è compatibile con un processo di patch standard per software embedded, dove i cicli di verifica e distribuzione sono più lunghi che nel software consumer.
Il record CVE-2026-40272, con punteggio 7.0 HIGH e CWE-1284, conferma la classificazione tecnica senza aggiungere elementi di timeline o attribuzione. Non emerge l'identità del ricercatore che ha scoperto la falla, né dettagli sull'URL specifico della patch BlackBerry o sulle procedure di distribuzione per i diversi tier di licenza QNX.
CVSS 7.0 HIGH — AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Record CVE-2026-40272, cve.org
Cosa fare adesso
Le azioni operative derivano direttamente dai fatti documentati nelle fonti primarie.
- Verificare la presenza di QNX SDP 7.0, 7.1 o 8.0 negli ambienti di sviluppo, test e produzione, e applicare l'aggiornamento rilasciato da BlackBerry
- Trattare i file
.kevricevuti da fonti esterne come potenziali vettori di attacco: isolarli prima dell'analisi, anche se apparentemente prodotti da sistemi fidati - Rivedere le policy di scambio di log di sistema tra team interni, fornitori e centri di assistenza, includendo la verifica dell'integrità dei file
- Rimuovere o limitare l'accesso a
libtraceparsersui sistemi di produzione dove non è strettamente necessario per il runtime
La lettura: quando il perimetro difensivo esclude gli strumenti del mestiere
Questo caso solleva una questione più ampia della singola vulnerabilità. L'industria della sicurezza si è concentrata per anni sulla riduzione della superficie di attacco dei servizi esposti, delle API, dei portali. Ha investito meno energia nel tracciare gli strumenti che gli ingegneri usano per capire cosa succede dentro i sistemi. Un parser di file di trace è un lettore di storie: legge ciò che il kernel ha vissuto. Ma se il lettore stesso può essere ingannato dal racconto, il confine tra diagnostica e compromissione si dissolve.
Il fatto che QNX operi in domini dove un crash o un'esecuzione di codice non sono incidenti IT ma eventi potenzialmente fisici rende questa cecità particolarmente costosa. La prossima volta che un team di sviluppo automotive riceverà un file di trace da un fornitore di secondo livello, la domanda non sarà solo "il contenuto è utile?" ma anche "il parser che lo aprirà è aggiornato?". La sicurezza degli strumenti di analisi forense è diventata, con CVE-2026-40272, un capitolo a sé.
Domande frequenti
- Possono i sistemi in produzione essere attaccati senza interazione dell'utente?
- No. Le fonti documentano esplicitamente che l'interazione utente è richiesta: l'apertura del file KEV o la visita a una pagina malevola sono condizioni necessarie.
- Perché il CVSS indica AV:L (Locale) se l'attaccante può essere remoto?
- Il parametro AV:L nel CVSS v3.1 si riferisce al contesto di esecuzione del codice vulnerabile, non alla collocazione geografica dell'attaccante. Il file malevolo deve essere elaborato localmente dal parser; l'attaccante lo consegna da remoto, ma l'esecuzione avviene nel contesto del processo locale.
- Sono interessate tutte le versioni di QNX?
- Il record CVE elenca esplicitamente QNX SDP 7.0, 7.1 e 8.0 come affette. Non emergono nella documentazione disponibile estensioni ad altre versioni o rami del sistema operativo.
Fonti
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.