A May Linux bug helped root 25 servers this week. Here's the 30-second kernel check

A write-up from Dream Research, on the Hacker News front page today, describes an attack that rooted 25 servers running Palo Alto Networks' PAN-OS, including systems in a US government-affiliated environment. It took two bugs. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) gave code execution on the management web server as the low-privilege nobody user. A Linux kernel bug called Fragnesia (CVE-2026-46300) turned that into root.

Palo Alto's Unit 42 says it independently verified the attacker's tooling and results. It says patched PAN-OS devices aren't affected, and that about 0.02% of its installed base had internet-facing management interfaces and was impacted. If you run PAN-OS, the fix is the advisory's: patch, and take the management interface off the public internet.

Why builders should care anyway. Fragnesia isn't a Palo Alto bug. It's in the Linux kernel's IPsec ESP-in-TCP code, and it was disclosed in May. Per Red Hat and Ubuntu, a local user can use it to overwrite the cached contents of read-only files and become root. Ubuntu adds that on hosts running third-party containers it "may additionally facilitate container escape." That's the setup a lot of AI agent sandboxes and shared build boxes run on. In this attack, the web bug was the way in and the kernel bug was the way up.

The tip: check the running kernel, then check how ESP is built. The kernel's CVE record lists these upstream stable fixes: 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33, 7.0.10, and 7.1 and later. We wrote a short read-only script that compares uname -r against that list and reads the kernel config. It changes nothing. On our box:

kernel: 6.12.94+
upstream version: fixed (6.12.91+)
CONFIG_INET_ESP=y  built in: a modprobe blocklist can't turn this off
CONFIG_INET6_ESP=y  built in: a modprobe blocklist can't turn this off
CONFIG_INET_ESPINTCP=y  built in: a modprobe blocklist can't turn this off
CONFIG_INET6_ESPINTCP=y  built in: a modprobe blocklist can't turn this off
esp4/esp6 modules: not loaded

You can do the same by hand. Distros keep the config in /boot or /proc/config.gz; this reads whichever exists (ours is the second):

uname -r
zcat -f /proc/config.gz /boot/config-$(uname -r) 2>/dev/null | grep -E 'CONFIG_INET6?_ESP(INTCP)?='

The catch we found. The published stopgap, for systems that can't patch yet, is to block the esp4 and esp6 kernel modules with a file in /etc/modprobe.d/, then confirm with grep -qE '^(esp4|esp6) ' /proc/modules. That only works when ESP is built as a module (=m). Our kernel has it built in (=y), so there's no module to block, and the "NOT loaded" check would pass even though the code is in the running kernel. Our kernel is past the upstream fix, so we're fine. A box on an older kernel with this config wouldn't be, whatever the check printed.

Second catch: distro version numbers. Distro kernels backport fixes under their own numbering. Ubuntu's fixed builds include 6.8.0-124.124 (24.04 LTS), 5.15.0-181.191 (22.04 LTS) and 7.0.0-22.22 (26.04 LTS). The upstream list says nothing about those, so check your distro's table. A kernel update also needs a reboot before it's running.

Who it's for: anyone running Linux servers, CI runners, or agent sandboxes that execute code they didn't write.

What we didn't test. We didn't run any exploit, touch a PAN-OS device, or check PHP versions. We tested our script's version logic on sample version strings, not other machines. Attribution of the campaign is Dream's and Unit 42's reading, not ours.

Our take: don't trust a mitigation's own "you're fine" check. Make sure the patched kernel is what's actually running.

Not sponsored. No affiliate links.