Blog Home

Your Artifactory is fine. Your Linux kernel hosting it might not be.

By Barak Haryati, JFrog Senior Director of Product Security

5 min read

Linux CVE - inner-image-863x300
Summary
As we’ve written, AI is shrinking the time between “a fix is public” and “someone has a working exploit” to near-zero. JFrog products are not affected by Linux kernel CVE-2026-98432. Artifactory, Xray, and the rest of the JFrog Platform do not contain this flaw, as it lives in the Linux kernel itself. We are advising every self-managed JFrog customer to check their Linux hosts and update their kernels now to protect their environments, which may include hosted versions of JFrog products. Once your OS is updated, JFrog products are not at risk.

Our goal is always to protect your systems, and in some cases that may include advice on the protection of the environments your JFrog products operate in. JFrog Cloud customers are not affected by the Linux vulnerability, but if you self-manage JFrog, read on.

Your Linux kernel may be exposed, requiring you to patch it to protect your environment.

What happened

On October 15, the Linux kernel CVE team published CVE-2026-98432. It’s a use-after-free in the code that sets up new IPv4 TCP connections, caused by a race condition. The bug dates back to Linux 4.4. Upstream fixed it on October 5 following main line patching on September 17; upstream was fixed a full ten days before the CVE went public.

The kernel team scores this vulnerability a 9.8. Red Hat, Oracle, SUSE and Amazon score it lower, between 5.9 and 8.1.

Then, Anthropic published research on October 27 saying its Claude model wrote a working exploit. A remote attacker with no credentials gets a root shell on servers with a multipath TCP (MPTCP) listener. In Anthropic’s test, leaking a kernel address took 48 minutes. Getting command execution took only five more. In this scenario, a lost race only kills that one connection, so the attacker just tries again.

Importantly, Anthropic did not publish the exploit code. As of November 2, there have been no reports of attacks in the wild. MPTCP is less exotic than it sounds: since Go 1.24, Go programs request it by default on the sockets they listen on. The Go Security Team also says the underlying bug isn’t specific to MPTCP. (Tip: JFrog deployments include several Go services within versions later than 1.24.)

As a JFrog customer…

In a self-managed deployment, you own the operating system that JFrog operates in. We are responsible for the security of our products, and you for the platform underneath (host, kernel, patching) in a shared responsibility model. A vulnerable kernel under a healthy JFrog install still puts that host, and everything on it, at risk.

As of October 30, neither Ubuntu nor RHEL had released a fixed kernel. Ubuntu 22.04 through 26.10 are marked work in progress, and older releases are plain vulnerable. RHEL 8, 9 and 10 are listed as affected, with no date. Debian, Oracle Linux, SUSE and Amazon Linux have shipped fixes for at least some kernels. Check your exact release, because coverage varies within each distro.

What we’re advising you to do as soon as possible

  1.     Find out what you’re running. Version numbers lie, because distros backport fixes without bumping them. Check the changelog instead.

On Debian or Ubuntu:

 apt changelog linux-image-$(uname -r) | grep CVE-2026-98432

On RHEL and its derivatives:

 rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-98432

If the command prints nothing, your running kernel doesn’t have the fix.

  1.     Patch where a fix exists, then reboot. A kernel update does nothing until the machine boots into it. If you build your own kernel, the fix is in 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 kernel team recommends moving to the latest stable release rather than cherry-picking the one commit.
  2.     Where there’s no fix yet, be proactive about it. Red Hat says no available mitigation meets its bar. Switching off MPTCP program by program is fragile, and the Go team says so directly: one forgotten listener and you’re exposed again. Narrow who can reach those hosts at the network layer, watch your vendor’s advisory for CVE-2026-98432, and patch the day the package is available. Another mitigation option could be using an L7 load balancer or reverse proxy with TCP termination to reduce direct exposure of vulnerable hosts. Reducing exposure doesn’t repair the bug, but it does reduce the number of people who can try to exploit it.
  3.     Make the next one simpler. If you proxy your Debian or RPM repos through Artifactory, the fixed kernel arrives in the repo your hosts already pull from. Stage it, promote it, roll it out in waves, with the same process you use for everything else. A kernel package is an artifact like any other, and it should have a system of record.

JFrog Xray scans your supply chain artifacts and images. It won’t tell you what kernel your host is running, because the kernel isn’t in either one; step one is a command you must run yourself.

The window is big, but shrinking

In an approaching-zero window from fix to exploit, rapid patching is required. The fix for this vulnerability was made public on October 5. A working exploit story hit on October 27. On October 30, two of the most widely run enterprise distros still had no update.

Our advice to protect your systems is simple:

Run the changelog check on every host that runs JFrog today. Update and reboot where a fixed kernel exists. Where it doesn’t, restrict access and subscribe to your distro’s advisory for CVE-2026-98432 so the fix doesn’t sit in a queue that could get forgotten.

Popular Tags