What happened — in brief
On 9 April 2026, the Photon team (a company building a framework for software agents connected to messaging platforms) published a detailed report: "We Found a Ticking Time Bomb in macOS TCP Networking". They discovered the bug on their own iMessage monitoring servers and reproduced it on 2 other machines. Tracing the issue led to a single line of code in the XNU kernel — the comparison that decides when a TCP connection in TIME_WAIT state can be closed.
Public discovery: 9 April 2026, by Photon
Photon — a company building a framework for software agents connected to messaging platforms — observed the bug on its own iMessage monitoring fleet and reproduced it on 2 other machines. They traced it to a single comparison in the XNU (macOS kernel) source code.
Exact threshold: 49 days, 17 hours, 2 minutes, 47 seconds
After that much continuous uptime, a 32-bit kernel counter overflows and "freezes" the TCP timestamp internal clock. It's exactly 2³² milliseconds (4,294,967,295 ms ≈ 49.71 days) — the mathematical limit of an unsigned 32-bit int. A classic overflow bug.
Symptoms: TCP fails, ping works
Past the threshold, connections in TIME_WAIT state never expire, ephemeral ports get exhausted one by one, and the Mac can no longer establish any new TCP connection. Browsing, email, SSH, iCloud sync — all fail. ICMP (ping) keeps working, so a quick check says "the net is up".
Apple hasn't confirmed (yet)
No official statement, no public feedback ID, the fix doesn't appear in macOS 26.4.1 (released April 2026). The community is waiting on a fix in 26.5 — unconfirmed. Adam Engst (TidBITS) found no discussion on Apple Developer Forums.
The technical mechanism — what the overflow does
The XNU kernel (used by macOS, iOS and watchOS, but TCP implementation differs on Mac) keeps an internal timestamp counter for each TCP connection — used to decide when a connection in TIME_WAIT state can be "forgotten" and resources freed. The counter is stored as an unsigned 32-bit integer, in milliseconds since system startup.
The math: 2³² milliseconds = 4,294,967,296 ms ÷ 1000 = 4,294,967 seconds ÷ 86,400 (sec/day) ≈ 49.71 days. At that exact moment (49 days, 17 hours, 2 minutes, 47 seconds), the counter wraps to 0. The cleanup logic that says "if old connection timestamp + 60 seconds < current time, close the connection" becomes permanently false — because current time (reset to 0) is always less than the old timestamp.
The consequence: old TIME_WAIT connections are never cleaned up. Each new connection opened occupies an ephemeral port from the pool (49152–65535 on macOS = ~16,000 available). Within days on an active system, the pool empties. The Mac runs out of ephemeral ports → any new TCP connection fails. The browser sees "connection refused" or timeout, even though Wi-Fi shows connected and ping to google.com works perfectly.
Technical stats — summary
| Uptime trigger | 49 days, 17h, 2m, 47s |
| Technical cause | uint32 overflow in XNU kernel |
| Underlying math | 2³² ms ≈ 4.29 billion milliseconds |
| Confirmed versions | macOS 26 (Tahoe) — possibly Catalina too |
| What breaks | New TCP connections (TIME_WAIT doesn't expire) |
| What keeps working | ICMP / ping |
| Immediate fix | Reboot — counter resets |
| Official Apple fix | Expected in macOS 26.5 (unconfirmed) |
Who is actually affected
The 49-day threshold seems big but is feasible for specific user categories. Here's who should be careful and who can ignore the bug without worry:
Mac servers that don't reboot
The most exposed category. Mac mini or Mac Studio configured as file server, build server, media server — running for months without pause. Uptime over 49 days here is the norm, not the exception.
Mac mini as AI bench / inference server
Recent trend: Mac mini with 64GB unified RAM used for running local AI models (Ollama, LM Studio). Left running for days with active sessions. Definitely affected.
Dev workstations on long projects
Programmers who don't shut down the Mac for weeks because they have complex dev environments (multi-tab, IDEs, simulators, Docker containers). A reboot means hours of re-setup. Many prefer to leave it on.
Regular users: NOT practically affected
On a regular MacBook, security updates land every 3–6 weeks and force a reboot. Plus laptops sleep daily — sleep doesn't accumulate uptime at the same rate. Hitting the 49-day threshold is very hard.
How to check and how to fix — 5 steps
The process is trivial — Terminal, one command, optionally a reboot. Under 5 minutes total.
Open Terminal
Spotlight (Cmd+Space) → type "Terminal" → Enter. Or Applications → Utilities → Terminal.
Type the uptime command and press Enter
Exact command: uptime. You'll see something like "16:42 up 23 days, 5:14, 3 users, load average...". The "days" number is how long the Mac has been running since the last reboot.
Compare with the 49-day threshold
Under 30 days — totally safe. Between 30–45 days — pay attention, schedule a reboot. Between 45–49 days — urgent reboot. Over 49 days — you probably already have symptoms (browser not loading, apps failing on connection, even though ping works).
Full reboot (not just logout/sleep)
Apple menu → Restart. DO NOT use "Sleep" or "Logout" — the kernel counter stays active. Only a full reboot or shutdown + start resets the TCP timestamp counter.
For Mac servers — schedule monthly reboots
If you use the Mac as a permanent server, set an automatic monthly reboot (under 30-day interval). This can be done with launchd / cron or via Energy Saver → Schedule. That eliminates the risk regardless of whether Apple ships the fix.
Historical context — this bug isn't new in computing
The 32-bit counter overflow at ~49.7 days is a whole class of bugs that has affected operating systems and network equipment for decades. Apple isn't the first victim — and probably not the last.
Windows 95
Almost identical bug — 32-bit uptime counter, crash at ~49.7 days. Microsoft publicly acknowledged and patched it in 1999. It became a meme among sysadmins.
VAX/VMS (Digital Equipment, 1980s)
32-bit counter but in tens of milliseconds — overflow at ~497 days. Rarer because no one kept a VAX running that long without maintenance.
Cisco IOS (certain versions)
Similar uptime overflow bug affecting production routers. Scheduled 24-day reboots became standard practice in many data centres.
Lesson for Apple: the bug could have been prevented with a 64-bit counter (~584 million year limit — practically infinite) or with explicit wrap-around logic. The fact that a modern OS still uses uint32 for time counters is a surprising choice in 2026.
Heads-up: if reboot does NOT fix it, it's a different problem
If you rebooted and the Mac still has issues — or, worse, your M2/M3 MacBook won't turn on at all after a macOS Tahoe update — this is not the 49-day bug. You may be affected by the Tahoe Bricked Fix bug, completely different, that bricks the logic board of M2 and M3 MacBooks after the macOS 26.4 / 26.4.1 update. DFU Revive fails, Apple Configurator returns errors 4013/4014. This bug does NOT fix with a reboot — it needs firmware-level service intervention. We repair it in 24h, keep the original board and your data. Read the full guide here.
✓ The Tahoe Bricked bug (M2/M3 MacBook dead after update) — our technical article, 24h repair.
✓ Other post-update issues — free diagnostic, call us at +40 739 795 800.
Frequently asked questions
How do I know for sure if I have the 49-day bug or something else?
Does sleep count as uptime?
Did macOS 26.4.1 fix the bug?
Are older macOS versions affected?
Can I do anything preventive besides reboot?
What does Radical Service do in this case?
Does this bug affect iPhone, iPad or Apple Watch too?
Is there any real risk (data loss, hardware damage)?
Sources
- Photon (primary source) — We Found a Ticking Time Bomb in macOS TCP Networking (full technical report, with direct reference to the line in XNU)
- TidBITS — Why the macOS "49-Day" Networking Bug Probably Won't Affect You (Adam Engst, 9 April 2026)
- Six Colors — Macs crash after 49 days of uptime?
- Daring Fireball — MacOS Seemingly Crashes After 49 Days of Uptime — a "Feature" Perhaps Exclusive to Tahoe
- AppleInsider — Unless you reboot every once in a while, your Mac will get kicked offline every 49 days
- Michael Tsai — Tahoe TCP Overflow Bug (suggests possible origin in macOS 10.15 Catalina)