#Linux & Open Source · 3 Min. Lesezeit · Tim Rinkel

WIRESHARK-ALARM! Ein einziges Paket killt deine Analyse-Maschine – so patchst du JETZT richtig!

WIRESHARK-ALARM! Ein einziges Paket killt deine Analyse-Maschine – so patchst du JETZT richtig!

Ein einziger Frame. Mehr braucht es nicht, um Wireshark beim Parsen abzuschießen. Die Lücke CVE-2026-0959 trifft den DECT-Dissektor und kippt jede laufende Analyse, sobald das präparierte Paket im Capture liegt.

GEFAHR! Crash mitten in der Analyse

Der Fehler ist klassisch: Der Dissektor verarbeitet verschachtelte Felder ohne saubere Längenprüfung. Wer einen passenden Frame schickt, zwingt Wireshark in einen Segfault. Auswirkungen: Tool zu, Capture-Session futsch, im schlimmsten Fall ein halber IR-Tag verloren.

Code-Ausführung ist nicht drin – aber das ist ein schwacher Trost, wenn dein Tool ausgerechnet im Forensik-Workflow stirbt.

SCHOCK: Patch ist da, aber nicht überall

Die Wireshark Foundation hat die Patches schnell ausgeliefert. Die Versionen 4.6.3 und 4.4.13 stopfen die Lücke. Trotzdem trifft die DoS gerade die Schicht, die am häufigsten frische Wireshark-Builds nicht hat: die Linux-Server, auf denen tshark in CI-Pipelines tutet.

Auch die Distributoren ziehen unterschiedlich schnell. Debian und Ubuntu haben die neuen Pakete via security.debian.org bereits in der Pipeline. Red Hat liefert über RHSA-2026:1714 nach. Bei manchen LTS-Setups muss man jedoch selbst nachhelfen.

So patchst du in 3 MINUTEN

  1. Version prüfen. wireshark --version verrät dir sofort den Build. Alles unter 4.4.13 / 4.6.3 ist Pflichtprogramm.
  2. Update ziehen. Windows-User holen das MSI von wireshark.org. Linux fährt apt upgrade wireshark oder dnf upgrade wireshark. macOS via brew upgrade wireshark.
  3. Captures aus fremder Quelle absichern. PCAPs, die du nicht selbst aufgenommen hast, im Idealfall in einer Sandbox-VM öffnen, bis das Update überall ausgerollt ist.

EXTRA-TIPP: Auch tshark-Server checken

Wer in CI/CD oder im Hunting-Stack tshark automatisiert laufen lässt, sollte zusätzlich die Container-Images prüfen. Viele Custom-Builds hängen monatelang auf einer alten Wireshark-Linie – und kippen dann genau dann, wenn das nächste verseuchte Sample reinkommt.

FAZIT: Defensiv-Tools brauchen genauso viel Pflege

CVE-2026-0959 ist nur eine DoS – aber sie zeigt, wie nervös moderne Dissektoren reagieren. Patchen, Sandboxen, automatisieren. Wer seine Defensiv-Tools so behandelt wie seine Produktionssysteme, verliert nicht den nächsten IR-Mittwoch.

Häufige Fragen

Welche Versionen sind betroffen?
Verwundbar sind alle Wireshark-Builds aus den Linien 4.4.0 bis 4.4.12 sowie 4.6.0 bis 4.6.2. Wer unter Windows oder macOS automatische Updates aktiviert hat, läuft meist schon auf einer gepatchten Version. Linux-Nutzer hängen oft an Distri-Paketen – Debian, Ubuntu und Red Hat haben die Patches bereits ausgerollt, einzelne RHEL-Stable-Releases brauchen aber Handarbeit.
Wie merke ich, ob mein System verwundbar ist?
Per wireshark --version oder tshark --version prüfst du den genauen Build. Liegt er unter 4.4.13 oder 4.6.3, ist die Installation angreifbar. Crashes mit Stack-Trace im DECT-Dissektor sind ein deutliches Indiz – wer beim Öffnen eines Captures plötzlich einen Segfault sieht, hat das Paket vermutlich live abbekommen.
Wie behebe ich das Problem konkret?
Auf den offiziellen Wireshark-Buildsever gehen, das passende 4.6.3- oder 4.4.13-Paket ziehen und installieren – ein Reboot ist nicht nötig. Linux-Nutzer fahren apt upgrade oder dnf upgrade. Wer Captures aus unbekannter Quelle bekommt, öffnet sie zusätzlich in einer Sandbox-VM, bis die Update-Welle in der eigenen Flotte komplett durch ist.
Gab es schon aktive Angriffe?
Bisher gibt es keine bestätigten Wild-Exploits. Der Angriffspfad ist allerdings trivial: Es reicht, einer Pen-Test- oder IR-Crew einen präparierten PCAP zu schicken. Sobald die Analystin den Capture öffnet, fliegt das Tool aus der Session – ein DoS, der genau dann zuschlägt, wenn er besonders weh tut.

Quellen