JFrog: Artifactory is safe, but Linux kernel flaw CVE-2026-98432 may expose hosts
JFrog says Artifactory, Xray and the rest of its platform are not affected by Linux kernel vulnerability CVE-2026-98432, but it is urging self-managed customers to check and update the kernels on their hosts. The company says the flaw lives in the Linux kernel itself, so a vulnerable host puts everything running on it at risk.
- JFrog says its products, including Artifactory and Xray, are not affected by Linux kernel CVE-2026-98432, and JFrog Cloud customers are not affected.
- The use-after-free bug in IPv4 TCP connection setup dates back to Linux 4.4 and is scored 9.8 by the kernel team.
- Anthropic published research on October 27 saying Claude wrote a working exploit; no attacks in the wild were reported as of November 2.
- As of October 30, Ubuntu and RHEL had no fixed kernel, while Debian, Oracle Linux, SUSE and Amazon Linux had shipped fixes for at least some kernels.
- Self-managed customers should check changelogs, patch and reboot where possible, and restrict network access where no fix exists.
What the vulnerability is
According to JFrog, the Linux kernel CVE team published CVE-2026-98432 on October 15. It is 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 the issue on October 5, following main line patching on September 17, so the fix was public ten days before the CVE was disclosed. The kernel team scores the flaw 9.8, while Red Hat, Oracle, SUSE and Amazon score it lower, between 5.9 and 8.1.
On October 27, Anthropic published research saying its Claude model wrote a working exploit. JFrog describes the scenario this way: 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, and getting command execution took five more. A lost race only kills that one connection, so an attacker can simply try again. Anthropic did not publish the exploit code, and as of November 2 there were no reports of attacks in the wild, according to JFrog.
MPTCP is less exotic than it sounds. Since Go 1.24, Go programs request it by default on the sockets they listen on, and the Go Security Team says the underlying bug is not specific to MPTCP. JFrog notes that its deployments include several Go services on versions later than 1.24.
Who is affected and where distros stand
JFrog Cloud customers are not affected. Self-managed customers are, because they own the operating system beneath the JFrog install. JFrog describes a shared responsibility model: it is responsible for its products, and customers for the host, kernel and patching.
As of October 30, neither Ubuntu nor RHEL had released a fixed kernel, per JFrog. Ubuntu 22.04 through 26.10 are marked work in progress, and older releases are plainly vulnerable. RHEL 8, 9 and 10 are listed as affected, with no date given. Debian, Oracle Linux, SUSE and Amazon Linux have shipped fixes for at least some kernels, and JFrog advises checking your exact release because coverage varies within each distribution.
What JFrog advises
First, find out what you are running. JFrog warns that version numbers can mislead because distributions backport fixes without bumping them, so the changelog should be checked instead:
- Debian or Ubuntu: apt changelog linux-image-$(uname -r) | grep CVE-2026-98432
- RHEL and derivatives: rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-98432
If the command prints nothing, the running kernel does not have the fix. Where a fix exists, patch and then reboot, since a kernel update does nothing until the machine boots into it.
For self-built kernels, JFrog lists the fix as present 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.
Where no fix is available, JFrog says Red Hat reports no available mitigation meets its bar. Switching off MPTCP program by program is fragile, and the Go team says one forgotten listener leaves a system exposed again. JFrog suggests narrowing network access to affected hosts, following the vendor advisory and patching the day a package arrives. It also names an L7 load balancer or reverse proxy with TCP termination as an option to reduce direct exposure, while stressing that this does not repair the bug.
What it means for users
JFrog frames the case as one more example of the shrinking gap between a public fix and a working exploit. In this case the fix was public on October 5, the exploit story appeared on October 27, and on October 30 two of the most widely run enterprise distributions still had no update.
The company also points to a practical step: customers who proxy Debian or RPM repositories through Artifactory can receive the fixed kernel through the repository their hosts already use, then stage, promote and roll it out in waves. JFrog adds that Xray scans supply chain artifacts and images but will not report which kernel a host is running, so the changelog check must be run manually on every host that runs JFrog.
