Linux Kernel Vulnerability Alert: Fragnesia and the TCP Flaw Server Owners Should Patch Now
Two Linux kernel flaws are in the news this week: Fragnesia (CVE-2026-46300), now on CISA's known-exploited list, and a new TCP bug (CVE-2026-98432). Here is what each one means for a business running Linux servers, and a practical patch checklist.
Every Linux kernel vulnerability sounds abstract until it lands on your own server. If your website, web app or internal system runs on Linux, two flaws deserve a few minutes of your attention this week. One is already being exploited. The other is newly disclosed, still being patched by several distributions, and rated very differently depending on who you ask.
This guide explains both in plain language, tells you who is realistically at risk, and gives you a checklist you can hand to whoever manages your servers.
Fragnesia (CVE-2026-46300): now on CISA’s known-exploited list
Fragnesia is a local privilege escalation bug in the kernel’s XFRM ESP-in-TCP code. According to the kernel CVE team, a page-handling mistake lets IPsec decryption write over memory that backs the page cache. It carries a CVSS 3.1 score of 7.8 (High), and the vulnerable code goes back to Linux 3.9. A public proof-of-concept has existed since the May 2026 disclosure.
What changed this week: according to third-party reporting, CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on 28 October 2026 with a federal remediation deadline of 31 October. The KEV entry reportedly notes it can be chained with the recent PHP2Shell PHP vulnerabilities: an attacker who lands a PHP webshell uses the kernel flaw to become root.
Why the chain matters for ordinary businesses
“Local” sounds reassuring, but on a web server it is not. A vulnerable PHP application (WordPress plugin, Laravel app, old CMS) gives an attacker code execution as the web user. A local privilege escalation turns that foothold into full control of the machine, including every other site and database on it. That is why patching the PHP layer and the kernel layer both matter.
CVE-2026-98432: the TCP use-after-free
The second issue is a race condition in the kernel’s IPv4 TCP connection setup that can lead to a use-after-free. It dates back to Linux 4.4, and IPv6 is not affected. Upstream fixed it on 5 October, and the fix landed in stable kernels 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3.
The severity picture is genuinely mixed, and it is worth being honest about that:
- The kernel CVE team scored it 9.8.
- Red Hat, Oracle and SUSE use 8.1 (Red Hat’s own CVE page also showed 5.9 “Moderate”), arguing the race is hard to win.
- Amazon lists 7.0.
Anthropic published a write-up saying Claude produced a working remote exploit against a server with an MPTCP listener, after initial prompting, and that it has not released the code. Reports so far say there is no confirmed exploitation in the wild, and it was not in the CISA KEV data as of 28 October. Whether servers without MPTCP are exploitable the same way is not yet known, so treat it as a “patch soon” item rather than a panic.
Are you affected? A quick comparison
| Fragnesia (CVE-2026-46300) | TCP flaw (CVE-2026-98432) | |
|---|---|---|
| Attack type | Local privilege escalation | Remote race condition (use-after-free) |
| Severity | 7.8 High | 7.0 to 9.8 depending on source |
| Exploited in the wild | Yes, per CISA KEV (reported) | Not reported as of 29 October |
| Fix status | Fixed kernels available in major distributions | Fixed upstream; Ubuntu and RHEL still in progress at time of writing |
| Priority | Patch this week | Patch as soon as your distribution ships it |
A practical Linux kernel vulnerability patch checklist
- List what you run. Run
uname -ron every server, including forgotten staging boxes and VPS instances from old projects. - Check your distribution’s advisory for the exact fixed kernel package. Do not rely on upstream version numbers alone, because distributions backport fixes under their own version strings. The kernel team also advises against cherry-picking individual fixes.
- Look for signs of compromise first. The Fragnesia technique modifies only the in-memory copy of files, so a reboot can erase evidence. Check web roots for unfamiliar PHP files, review recent logins, and preserve logs before you reboot.
- Install the updated kernel and reboot. Confirm with
uname -rafterwards. If your provider offers live patching, use it, but still schedule the reboot. - If you cannot patch yet, Red Hat and Ubuntu document blocking the
esp4andesp6modules for Fragnesia. This breaks IPsec, so only do it if you do not use IPsec VPNs. Disabling unprivileged user namespaces is another option that can break rootless containers. - Patch the layer above too. Move PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and keep PHP session upload progress disabled until the next regular release.
- Write it down. Record the date, kernel version and who patched each server. Auditors, insurers and clients increasingly ask.
Lessons for small and mid-sized businesses
Most breaches of small business servers are not clever zero-days. They are known bugs sitting unpatched for weeks, usually because nobody owns the job. Three habits close most of the gap:
- Name an owner for server updates, in writing, with a backup person.
- Patch on a schedule (monthly, plus emergency windows for anything on the KEV list) instead of “when we remember”.
- Keep a tested backup so that a bad update or a compromise is an inconvenience, not a disaster. See our guide on business software backup and disaster recovery.
Frequently asked questions
Is this Linux kernel vulnerability exploitable remotely?
Fragnesia is not, on its own. It needs local code execution first. In practice that is often obtained through another bug, such as a vulnerable PHP application, which is why it is being discussed together with PHP2Shell. The TCP flaw is network-reachable in principle, but no attacks have been reported.
Do I have to reboot after a kernel update?
Yes, unless you use a live-patching service that covers the specific fix. Until the new kernel is running, the old vulnerable one is still in memory.
Does a cloud provider or managed host patch this for me?
Managed platforms often patch the host, but on a VPS or dedicated server the guest kernel is usually your responsibility. Check your provider’s documentation rather than assuming.
Is CVE-2026-98432 a 9.8 or an 8.1?
Both numbers are published by credible sources. The gap reflects disagreement about how hard the race is to win. Either way, the fix is the same: install your distribution’s updated kernel when it is released.
Need a second pair of eyes on your servers?
At Shkulaku we build and maintain custom software, WordPress and PHP systems, and the servers they run on. Our maintenance and retainer service includes patching, monitoring and incident response, so someone who already knows your stack is on call when the next advisory lands. If you want a quick review of your servers or a patch plan, contact us and tell us what you run.
Sources: The Hacker News: Linux kernel TCP flaw with 9.8 CVSS, Rescana: Fragnesia CVE-2026-46300 in CISA KEV. Details can change as vendors update their advisories; always confirm against your distribution’s security notice.
I take on a small number of projects at a time. Tell me what you are building and I will tell you honestly whether I am the right person for it.
Get in touch →