Your Mac Has a Networking Time Bomb That Only a Reboot Defuses

macOS Tahoe has a kernel-level bug that silently kills your Mac’s TCP networking after exactly 49 days, 17 hours, 2 minutes, and 47 seconds of continuous uptime. A 32-bit integer overflow in Apple’s XNU kernel freezes the internal TCP timestamp clock, and once it triggers, no amount of troubleshooting brings your connections back. Only a full restart works. The real kicker? Your Mac still responds to pings the entire time, so everything looks fine on the surface while nothing actually functions underneath. And if you just picked up one of Apple’s new M5 MacBook Air or M5 MacBook Pro models, there is a second networking bug targeting enterprise Wi-Fi networks — though Apple patched that one today with macOS Tahoe 26.4.1.

Two networking bugs in one operating system. One fixed, one still lurking. Here is what both do, how to tell which one bit you, and the fastest path back to a working connection.

The 49-Day Bug That Freezes Your Entire Network Stack

Engineers at a company called Photon found this one the hard way. They run a fleet of Macs that monitor iMessage services around the clock, and certain machines kept losing all network connectivity after being up for roughly seven weeks. Ping still worked. Everything else died. That disconnect between a passing ping test and a completely dead browser is what makes this bug so difficult to diagnose in the wild.

The culprit is a variable called tcp_now buried deep in Apple’s XNU kernel. This variable tracks TCP timestamps using an unsigned 32-bit integer that counts in milliseconds. It can store values up to 4,294,967,295 before running out of room and wrapping back to zero. Convert that to calendar time and you land on 49 days, 17 hours, 2 minutes, and 47 seconds.

When the counter wraps, a monotonicity protection mechanism inside the kernel compares the new near-zero value against the old near-maximum value and decides the new timestamp must be from the past. So it freezes the TCP timestamp clock at its maximum value — permanently. From that point forward, TCP TIME_WAIT connections never get cleaned up. Temporary ports that macOS uses for short-lived connections never get released back to the system. Your Mac’s TCP stack slowly chokes on its own held connections until no more ports are available and all TCP traffic stops.

How fast it falls apart depends on how much network activity your Mac handles. A MacBook you use for email might limp along for a while after the overflow. A Mac mini running a home server could seize up within minutes.

What Makes This Bug Genuinely Sneaky

Here is the part that would drive me up the wall if I hit this without knowing what it was. ICMP — the protocol behind the ping command — keeps working the entire time. So when your Mac suddenly stops loading webpages, pulling email, or connecting to file shares, the first thing you would do is open Terminal and ping your router. And it would respond perfectly. You would blame your ISP, your router, your DNS settings, maybe even your Ethernet cable. You would be wrong every time.

The standard troubleshooting playbook does not touch this bug. Toggling Wi-Fi off and on, forgetting and rejoining the network, renewing your DHCP lease — none of it reaches the frozen TCP timestamp. The bug lives below all of those layers. It exists in the kernel itself.

And the fix is anticlimactic: restart your Mac. Not a sleep-wake cycle. Not logging out. A full restart that zeros out the kernel clock. That is it.

If you have been chasing a network issue on your Mac and ended up reading about general post-update slowdowns in macOS Tahoe, this is a different problem entirely. This bug has nothing to do with Spotlight reindexing or background processes — it is a hard timer buried in kernel code that ticks toward failure from the moment you boot up.

The 802.1X Wi-Fi Fix Apple Shipped Today

The 49-day TCP bug is the dramatic one, but Apple released macOS Tahoe 26.4.1 on April 9, 2026 to patch a separate, more targeted problem. The new M5 MacBook Air and M5 Pro and M5 Max MacBook Pro models could fail to join 802.1X Wi-Fi networks when using content filter extensions.

If those terms do not ring a bell, you are probably unaffected. 802.1X is the enterprise Wi-Fi authentication protocol used by corporate offices, universities, and hospitals. Content filter extensions are the security tools IT departments install to monitor and filter web traffic. When both were active on an M5 MacBook, the machine simply refused to connect.

For anyone who unpacked a brand-new M5 MacBook at work and immediately could not get online — this was the reason. And until today, there was no workaround beyond disabling the company’s required security tools, which IT would never approve.

The update carries no published CVE entries. Apple categorizes it as a functionality bug, not a security vulnerability. Install it through System Settings, then General, then Software Update. The process takes a few minutes and requires a restart, which also resets your TCP timestamp clock if your uptime was getting long. Two birds.

How to Check Your Mac’s Uptime Right Now

Open Terminal and type uptime, then press Return. The output shows how many days your Mac has been running since its last restart. If that number is anywhere near 49, restart immediately.

Most Mac users restart more often than every 49 days because macOS updates force periodic restarts. But if you are the kind of person who puts your Mac to sleep every night and only restarts when Apple forces a software update, you could genuinely hit this window without knowing it. Mac mini and Mac Pro owners running always-on workloads are the most exposed, since those machines are specifically built to stay running for weeks or months at a stretch.

Apple has not confirmed whether macOS Tahoe 26.4.1 addresses the TCP timestamp overflow. The update’s release notes only mention the 802.1X Wi-Fi fix. The XNU kernel code responsible for the overflow is open source through Apple’s public distributions, and the problematic lines appear to have been introduced recently in macOS Tahoe — though exactly when is still being picked apart by the developer community.

Until Apple patches the TCP bug directly, a periodic restart is the best defense. If your Mac handles any always-on workload — a Plex server, a Home Assistant instance, a development environment that never sleeps — consider scheduling a weekly restart. You can set one through Energy Saver in System Settings, or drop a one-line cron job into Terminal if you prefer the command-line approach to macOS maintenance. Either way, a thirty-second reboot once a week is cheaper than debugging a phantom network failure at the worst possible moment.