macOS Tahoe networking bug after 49 days uptime

If your hosted Mac runs macOS Tahoe (26.x) and stays up for more than 49 days, new TCP connections will eventually stop working. Reboot any Tahoe host before it hits 49 days of uptime. Sequoia (15.x) and earlier are not affected. Apple has not yet shipped a fix.

What goes wrong

After 49 days 17 hours of uptime, a kernel timer freezes. Closed TCP connections stop being released and slowly fill up the outbound port pool. Once the pool is full, the Mac can no longer open new TCP connections. Ping still works, so the host looks alive while being effectively offline for network traffic like VNC or SSH.

Affected systems

  • macOS Tahoe 26.0 through at least 26.4.1

  • Earlier macOS versions (Sequoia 15.x and below) are not affected. The bug was introduced in 26.0

Symptoms

If your host has crossed the 49 day threshold and the bug has triggered, you will see:

  • Inbound connections like SSH and VNC are not working anymore

  • New outbound TCP connections fail or stay in SYN_SENT.

  • ICMP (ping) continues to work

  • The TIME_WAIT count climbs and never drops: netstat -an | grep -c TIME_WAIT

Why this goes unnoticed for most users

Anyone keeping up with updates or doing routine maintenance rarely accumulates enough uptime to reach the 49-day threshold in the first place. However, on our hosted Macs that run as servers, more than 49 days of uptime is not rare.

For hosts that do stay up past 49 days, the failure can take a while to be visible, because there are 2 stages. The kernel timer freezes at the 49 day mark. The visible symptom only follows once enough outbound TCP connections accumulate to fill the ~16,000 port outbound pool. A Mac that mostly accepts inbound connections (like a web servers), or isn't used so much, burns ports slowly and can stay reachable for days or weeks after the freeze. The host will however fail eventually.

If a Tahoe host has uptime over 49 days, preventatively reboot it, even if it currently looks fine.

Detection

For manual verification, simply run the uptime command in Terminal to see the actual uptime of your Mac

For automated detection and scripting, to calculate the time remaining until the next overflow:

boot_sec=$(sysctl kern.boottime | awk '{ for (i=1;i<=NF;i++) if ($i ~ /^[0-9]+,?$/) { gsub(",","",$i); print $i; exit } }')
now_sec=$(date +%s)
remain=$(( 4294967 - (now_sec - boot_sec) ))
echo "Time until overflow: $((remain/3600))h $((remain%3600/60))m $((remain%60))s"

Mitigation

Until Apple ships a fix, the only reliable mitigation is a reboot before the bug triggers, either manual or scripted.

The easiest is to schedule a restart using the pmset command, for example, to reboot every week on Sunday 04:00:

sudo pmset repeat restart U 04:00:00

Unfortunately, the pmset command is limited to days of the week, so you'd have to reboot at least once a week.

Alternatively, you can schedule reboots from inside the Mac with a launchd job that calculates the remaining uptime and then does a sudo shutdown -r now when reaching close to 49 days.

Manual: manually reboot your Macs every now and then to apply new software updates

Worst case (host unreachable): If a host has already crossed the threshold and is no longer accepting new TCP connections, you can trigger a hard reboot from our customer portal. The power reboot does not depend on the OS network, so it works even when the host is not reachable anymore.

Status of the Apple fix

Since the issue was introduced and reported, Apple has shipped some updates. None of these address this issue. The 26.5 beta is in testing at the time of writing with no confirmed fix in the public release notes. We will update this article when Apple ships a kernel fix and we have verified it.

References