Technology1 min read

Well, That Wasn't Fun: October 16 '26

By · Published by Everything Blog

In short

The vulnerability, identified as CVE-2026-99999, allowed guest environments to alter IPv4 headers to capture up to 32 bytes of adjacent host memory, risking the exposure of kernel data and neighboring network packets. To minimize disruptions during the remediation, Fly.io staggered restarts to safeguard multi-node Managed Postgres clusters from experiencing total outages. Platform operators observed no signs of an active breach throughout the deployment window. Nevertheless, users active across those dates have been urged to rotate credentials passed over unencrypted channels.

Key points

  • Fly.io completed a 10-hour fleetwide patched reboot to protect multi-node Managed Postgre…: Fly.io completed a 10-hour fleetwide patched reboot to protect multi-node Managed Postgres clusters from concurrent downtime.
  • Platform telemetry showed no evidence that customer data was compromised prior to or duri…: Platform telemetry showed no evidence that customer data was compromised prior to or during the deployment.
  • Customers active between October 15 and 17 should rotate credentials previously transmitt…: Customers active between October 15 and 17 should rotate credentials previously transmitted across unencrypted protocols or internal 6PN traffic.

Sources checked by our analysis pipeline: 1

October 16, 2026 began like any other day at Fly.io (meaning, we were anticipating only a medium amount of chaos). By that evening, we had patched and rebooted our entire fleet in response to a Linux kernel bug. The full rollout took 10 hours, but the emotional damage persists.

CVE-2026-99999

The rest of this won’t make much sense without a clear read on the bug itself, so: the Linux kernel CVE team and pwn.ai announced CVE-2026-99999 on the morning of the 15th. We heard about it that night, and started working on mitigations.

IP sleight of hand

Protocols like TCP and UDP include checksums to detect corruption on the way across the internet. Calculating one means reading the whole message, which adds up at high speeds. Linux avoids that with checksum offload: instead of calculating the checksum immediately, the kernel stores metadata saying where the checksum should read from and write to. If the checksum turns out not to be needed, the kernel never spends the CPU on it.

Not needed, for example, when sending to localhost, or when the…

Technology