wireshark 4 6 9 19 vulnerabilita protocolli capture file

Wireshark 4.6.9 corregge 19 falle e aggiorna protocolli e capture file

🛡️ Executive Summary

  • Wireshark 4.6.9 corregge 19 vulnerabilità tra dissector, parser di capture file, Sharkd e importazione dei profili.
  • CVE-2026-96419 è il problema più delicato: un profilo di configurazione manipolato può provocare un crash o potenzialmente l’esecuzione di codice.
  • La release aggiorna numerosi protocolli, tra cui QUIC, SMB, OpenFlow, IEEE 802.11 e LoRaWAN, oltre ai formati pcapng, BLF e Network Monitor.

Wireshark 4.6.9 è una release di manutenzione solo in apparenza. L’aggiornamento del network protocol analyzer corregge 19 vulnerabilità, interviene su numerosi dissector e parser di file di cattura e chiude anche una falla che può arrivare alla possibile esecuzione di codice tramite un profilo di configurazione manipolato. Parallelamente vengono aggiornati protocolli centrali per analisi enterprise, wireless e telecomunicazioni, tra cui QUIC, SMB, OpenFlow, IEEE 802.11, LoRaWAN e ZigBee, insieme al supporto per capture file pcapng, BLF, Network Monitor, Toshiba e TTL. Il punto operativo è evidente: un analizzatore di pacchetti deve considerare ostile non soltanto il traffico catturato, ma anche i file e le configurazioni utilizzate durante l’analisi.

Wireshark 4.6.9 corregge 19 vulnerabilità in parser e dissector

Annuncio

La pagina ufficiale degli advisory di sicurezza di Wireshark associa alla versione 4.6.9 una sequenza di 19 problemi, da wnpa-sec-2026-92 a wnpa-sec-2026-110. Gran parte delle falle produce crash, infinite loop o consumo anomalo di memoria, ma la superficie interessata è ampia: ZigBee ZCL, SCTP, SPDY, CSN.1, USB HID, TIFF, X11, RF4CE, MBIM, IEEE 802.11, Synchrophasor e Catapult DCT2000, oltre ai parser di diversi formati di cattura. Non risultano, secondo gli advisory pubblicati dal progetto, exploit osservati per le vulnerabilità indicate. La distinzione è importante: si tratta di problemi documentati e corretti, ma non di una campagna di exploitation attiva. In numerosi casi un attaccante dovrebbe riuscire a far analizzare alla vittima un packet trace manipolato oppure immettere traffico malformato nella rete monitorata. È lo stesso modello di rischio già emerso con Wireshark 4.6.8, che aveva corretto decine di problemi distribuiti tra parser, dissector e motore di analisi. La frequenza delle correzioni evidenzia quanto il parser di protocolli rappresenti una superficie particolarmente esposta: Wireshark deve interpretare dati provenienti per definizione da sorgenti potenzialmente non affidabili.

Leggi anche: PipeWire 1.6.8 e Wireshark 4.6.7 migliorano stabilità e sicurezza su Linux

CVE-2026-96419 rende pericoloso anche un profilo di configurazione

Il problema con l’impatto potenzialmente più grave è CVE-2026-96419, documentato nell’advisory wnpa-sec-2026-106. L’importazione di un profilo di configurazione appositamente manipolato può provocare il crash di Wireshark oppure, secondo il progetto, arrivare alla possibile esecuzione di codice arbitrario. Le versioni vulnerabili comprendono Wireshark 4.6.0-4.6.8 e 4.4.0-4.4.18; la correzione arriva rispettivamente con 4.6.9 e 4.4.19. Il progetto precisa di non essere a conoscenza di exploit attivi. Il prerequisito è inoltre differente dalle classiche vulnerabilità dei dissector: la vittima deve essere indotta a importare un profilo malformato. La distinzione amplia però il trust boundary dello strumento. Un analyst non deve considerare potenzialmente ostile soltanto il PCAP ricevuto durante un’indagine, ma anche materiale accessorio come profili e configurazioni scambiate tra colleghi, repository, laboratori o ambienti di test. Un problema analogo legato alla possibile code execution durante l’importazione dei profili era già comparso nella serie 4.6.5, ulteriore indicazione della complessità di questa specifica superficie.

QUIC, SMB, OpenFlow e pcapng ricevono aggiornamenti di parsing

Le release note ufficiali di Wireshark 4.6.9 mostrano che il lavoro non si limita alla sicurezza. La release aggiorna il supporto per AKP, Bencode, Bluetooth AVCTP, DICOM, IEEE 802.11, LoRaWAN, OpenFlow 1.3, 1.4 e 1.5, PKCS12, QUIC, RTPS, SMB, SPDY, X11 e ZigBee ZCL, oltre a numerosi protocolli delle reti mobili. Non vengono introdotti nuovi protocolli: l’obiettivo è aumentare precisione e resilienza di quelli già presenti. Ricevono aggiornamenti anche i formati di capture BLF, Network Monitor, pcapng, PEAK TRC, Toshiba e TTL. Quest’ultimo è coinvolto anche in CVE-2026-95386, una condizione nella quale un file manipolato può portare il parser in un loop infinito e consumare risorse CPU. Tra i bug corretti figurano inoltre problemi DICOM, RTPS e due segnalazioni ZDI relative a LBMC Fragment Reassembly e LoRaWAN Decryption, entrambe associate nelle release note a possibili condizioni di Remote Code Execution. La serie 4.6 aveva già progressivamente ampliato la copertura dei protocolli nelle release precedenti dedicate a networking, capture e sicurezza, ma la 4.6.9 mostra come l’estensione della capacità di decodifica aumenti inevitabilmente anche la quantità di codice esposto a input arbitrari.

Extcap cambia percorso e può richiedere interventi ai pacchetti Linux

Le note chiariscono inoltre una modifica introdotta già con Wireshark 4.6.0 ma non adeguatamente documentata all’epoca. Sui sistemi Unix, con l’eccezione di macOS quando viene utilizzato l’app bundle ufficiale, gli eseguibili extcap vengono ora cercati di default sotto libexec, ad esempio in /usr/libexec/wireshark/extcap, anziché nei precedenti percorsi legati a lib64. La scelta segue la convenzione secondo cui gli helper binari non necessitano della stessa gestione multiarch delle librerie. Il percorso resta modificabile tramite la variabile WIRESHARK_EXTCAP_DIR, ma i maintainer di estensioni e pacchetti di terze parti possono dover adattare installazione e packaging. Alcune distribuzioni, come Alpine Linux, non adottano libexec e continuano quindi a utilizzare il comportamento precedente.

Continua con:

Un packet analyzer deve trattare anche i file di analisi come input ostili

Wireshark 4.6.9 conferma un principio importante per SOC, incident responder e ricercatori: aprire una cattura di rete è un’operazione di parsing di contenuto potenzialmente ostile. Un PCAP proveniente da un incidente, un protocollo costruito deliberatamente in modo anomalo o un profilo ricevuto da terzi possono raggiungere componenti molto complessi dello strumento. L’aggiornamento dovrebbe quindi essere considerato prioritario soprattutto sulle workstation utilizzate per network forensics, malware analysis e incident response, dove Wireshark viene esposto con maggiore frequenza a contenuti non fidati. Il salto alla 4.6.9 non introduce una funzione spettacolare, ma riduce una superficie di attacco che per uno strumento di sicurezza è paradossalmente parte stessa del lavoro quotidiano: analizzare dati ostili senza permettere a quei dati di trasformare l’analizzatore nel nuovo bersaglio.

Iscriviti alla Newsletter

Non perdere le analisi settimanali: Entra nella Matrice Digitale.

Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.

Torna in alto