Wireshark End of Life (EOL) Dates and End of Support (EOS) Dates

Wondering when your copy of the network packet analyzer stops getting fixes? Wireshark End of Life works differently from most commercial products: this open-source packet analyzer publishes a rolling support policy instead of one fixed date, and software that captures packets from live networks should never run on a branch nobody maintains. Here you can see which release branch you are on and when it ends.

Wireshark EOL and the Release Life Cycle Explained

The Wireshark Foundation ties every EOL decision to its release life cycle rather than to a calendar. Each branch is announced, supported for a minimum period, then superseded by a newer one. The release policy is the rulebook behind this, and it covers the Windows, macOS and Linux builds alike. As open source software, it is maintained in public, and every new version inside a branch carries a fresh protocol dissector, capture fix and analysis improvement, while unstable builds exist only for testing.

Stable Release, Old Stable and Development Release Types

The download page lists three kinds of builds. The stable release is the latest official version and what most people should install. The old stable branch is the previous official line, which is still supported, so you can stay on it if your organization has strict software approval rules. Depending on how major releases are paced, an Old Old Stable branch may briefly exist too.

A development release is for testing new features. Each development release previews the next stable branch, and a development build can break your setup, so never put a development release on a production machine. Development snapshots carry no support promise, and development work continues in the open until the next stable branch is cut.

Minimum Lifetime and the 18-Month Support Rule

Every branch gets a minimum lifetime of 18 months. That can stretch to 24 or 30 months for a release that precedes a big change. At least two branches stay supported at once. Support for branch X.Y ends when its minimum lifetime is over or when X.Y+4 ships, whichever comes later. Because a superseded branch stops receiving routine maintenance, plan your upgrade before that day arrives.

Wireshark Releases and End of Support Dates by Branch

The table below lists recent Wireshark releases and when end of support arrives for each. The end of support planning column follows the official notes, where a branch's last day is usually the day a later branch becomes stable. Wireshark's release numbers now follow a simple scheme, since 4.6 was the last release using even-stable numbering. A single long term support (LTS) branch, 3.6, was the exception to the usual cycle. The software itself is distributed under the GNU General Public License, and the installers are available through package managers such as winget.

Active Support Versus Security Support

Third-party trackers split the picture in two. Active support means a branch still receives new bug fixes on a regular schedule. Security support is the tail end, when only fixes for vulnerabilities keep arriving. For example, the 4.4 branch lost active support when 4.6 became stable but kept security patches afterward, so judge your exposure by which of the two phases you are in.

Release Dates and the Latest Version

Run wireshark --version to see what you have, then compare it against the latest version in your branch. Published release dates help here, because patch builds arrive every few weeks, for instance 4.6.9 and 4.4.19 in September 2026. Fixes to a protocol decoder or a packet capture engine ship in these patch builds, and a long capture session on an old build may miss them. Only two branches are normally current, so anything older deserves a close look.

Wireshark End of Life Cutoffs for Operating Systems

Besides branch dates, every end-of-life decision for a platform is recorded too: the project records the last release to support each platform. These notes explain why an older operating system quietly stops getting new builds even when the branch itself is still maintained. The last release lists matter most if you run Windows on aging hardware.

Windows Support Cutoffs From Windows XP to Windows 10

• Windows 10: 4.6 is the last release to officially support it; Windows Server 2016 was removed from the 4.6 line.
• Windows 8.1 and Windows Server 2012: 4.0 was the last release branch.
• Windows 7 and Windows Server 2008 R2: 3.2 was the last release.
• 32-bit Windows: support ended May 22, 2024, and 3.6 is the last release for it.
• Windows Vista: 2.2. Windows XP: 1.10. Windows 2000: 1.2.

The 4.4 line also marked the last Windows Server 2016 support, and anything newer than these baselines needs a 64-bit install.

macOS, Red Hat and Qt Cutoffs

Apple users should note that 4.4 was the last release to support macOS 11, while 4.2 was the last for macOS 10.14 and 10.15 (the 4.2 line handles macOS 10.15 through its final patch). On Linux, 3.6 was the last release for Red Hat EL 7 and Ubuntu 18.04, and 4.6 is the last for Red Hat EL 8. The 4.6 branch is also the last to use Qt 5, so a future migration to Qt 6 builds is coming. Ubuntu and other distributions follow their own packaging, and GTK+ was dropped long ago.

Wireshark Lifecycle Planning and Staying Current

A sound lifecycle habit is cheap: check your branch each quarter, track when the next stable branch lands, and schedule the upgrade before support ends. The practice of staying current beats rushing once a vulnerability is public, and a documented lifecycle plan makes audits easier. Treat end of life as a deadline you set yourself, ahead of the project's own.

Announcements, Appcast Files and Release Notes

New builds are announced on the wireshark-announce mailing list, and automated checks can read the Windows and macOS Appcast files. Read the release notes for each version to see removed platform support before it surprises you.

Release Planning and Past Releases

The roadmap shows what is proposed for upcoming branches, which is the heart of release planning. For past releases, the change logs and release notes document what changed branch by branch, and they are the quickest way to confirm which feature disappeared in which version.