Claude AI can hijack vulnerable Linux servers without a password and Ubuntu still has no fix. IA terrifying security vulnerability in the Linux kernel could allow attackers to take complete control of affected servers without knowing a password or tricking anyone into clicking a malicious link. Making matters worse, researchers at Anthropic have demonstrated that artificial intelligence can develop a working exploit capable of turning this flaw into remote root access. The vulnerability, identified as CVE-2026-98432, carries a critical severity score of 9.8 out of 10. Although fixes have reached several major Linux distributions, Ubuntu remains vulnerable as of November 1, 2026, leaving administrators waiting for Canonical to deliver patched kernels. The flaw affects the Linux kernel's IPv4 networking code, specifically the way it handles certain TCP connections. This is particularly concerning because TCP is used by countless internet services, meaning the vulnerable code can be reached before an application even gets the opportunity to authenticate someone. According to a detailed security analysis published by Atlas, the problem dates back to Linux kernel 4.4. It involves a memory-management mistake known as a use-after-free vulnerability, where the kernel attempts to access memory that has already been released. Under the right circumstances, specially crafted network traffic can exploit this behavior to corrupt kernel memory, expose sensitive information, or crash a system. A successful remote code execution attack is considerably worse, potentially giving an intruder control over the operating system itself. Anthropic proves AI can turn a Linux bug into a nightmare Perhaps the most frightening part of this story comes from Anthropic's own security research, published October 27. The company revealed that an unreleased internal Claude research model developed a functioning exploit that could remotely execute commands as root on Linux servers running a vulnerable Multipath TCP listener. Root access is essentially the highest level of privilege available on a Linux system. Someone who obtains it can potentially steal data, install malicious software, interfere with running services, or completely compromise the machine. Anthropic explained that the attack works in two stages. First, the exploit defeats a security protection designed to make kernel memory addresses difficult to predict, and then it manipulates the vulnerability to execute an attacker-chosen command with root privileges. In Anthropic's demonstration, the first stage took approximately 48 minutes, while the second required another five minutes. That is 53 minutes of exploit execution, not the time Claude needed to write the exploit, but it illustrates how an attacker could patiently work toward gaining control of a server. Even more troubling, unsuccessful attempts do not necessarily crash the target. This allows an attacker to repeatedly try exploiting the vulnerable connection until the necessary conditions occur. The demonstrated attack required a Multipath TCP listener, so it would be misleading to suggest every unpatched Linux computer can automatically be taken over remotely. However, the underlying flaw exists in ordinary IPv4 TCP processing, and researchers have not ruled out additional methods of exploitation. Ubuntu users are still waiting for protection The good news is that the Linux kernel developers have already addressed the underlying problem. Patches are available upstream, and several distributions have incorporated the correction into their supported kernel packages. Debian 12 and 13 have received fixes, while Red Hat released patched kernels for RHEL 8, 9, and 10 on November 1. Amazon Linux 2 and Amazon Linux 2023 have updates available as well, although individual systems still need to install them and reboot. Ubuntu is a different story. According to Canonical's official vulnerability tracker, Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS, and 26.10 are still listed as vulnerable, with fixes under development. That's a particularly uncomfortable position for Ubuntu, considering its popularity in cloud computing, enterprise environments, and web hosting. While Canonical is working on updates, administrators responsible for internet-facing Ubuntu servers cannot simply assume their systems are protected. There is another wrinkle involving applications written in Go. The Go Security Team has warned that Go 1.24 and later enable Multipath TCP by default for listening sockets on Linux where the feature is supported and enabled, potentially increasing exposure to the demonstrated attack. Disabling Multipath TCP can reduce certain risks, but it does not eliminate the underlying kernel vulnerability. The proper solution remains installing a fixed kernel, followed by a reboot to ensure the patched code is actually running. The bigger threat might be artificial intelligence There is an important distinction between a security researcher discovering a vulnerability and an AI system developing an exploit capable of weaponizing it. The latter suggests that sophisticated attacks, once requiring extensive specialist knowledge, could eventually become easier and faster to produce. To be clear, Anthropic conducted this research under controlled conditions using an internal model, and it has not released the Linux exploit publicly. Amazon Web Services also reports that it is unaware of exploitation of this particular vulnerability in the wild, which is reassuring for the moment. Still, the implications extend far beyond Linux. AI systems are becoming increasingly capable of examining complicated software, discovering weaknesses, and combining techniques that overcome multiple security protections. There is an obvious benefit to giving security researchers powerful tools that help them discover vulnerabilities before criminals do. The uncomfortable reality, however, is that attackers could eventually gain access to similar capabilities, potentially making the race between discovering security flaws and fixing them much more dangerous. Linux remains an excellent operating system, and this vulnerability does not somehow make Windows or macOS inherently safer. Every major operating system experiences security problems, but a critical remotely accessible kernel flaw deserves immediate attention regardless of the platform. For Linux administrators, especially those managing publicly accessible Ubuntu servers, the priority should be checking affected kernels, reviewing network exposure, and applying available updates as soon as possible. For everyone else, this incident offers a disturbing glimpse of a future in which AI does not merely help write software, but also helps find ways to take it apart. Support independent tech journalism. NERDS.xyz is independently owned and operated. If you enjoy my coverage of Linux, AI, hardware, cybersecurity, and tech culture, consider supporting the site on Ko-fi. Technology journalist and founder of NERDS.xyz Brian Fagioli is a technology journalist and founder of NERDS.xyz. A former BetaNews writer, he has spent over a decade covering Linux, hardware, software, cybersecurity, and AI with a no nonsense approach for real nerds.

Direct VM networking in AWS: Introducing BGP cloud connector on Red Hat OpenShift Service on AWS. Associate Principal Specialist Solution Architect, Cloud Services When migrating virtual machines (VMs) to the cloud, virtualization engineers hit a familiar wall: how do you route traffic directly to a Red Hat OpenShift Virtualization guest VM using that VM's own IP address? OpenShift Virtualization has long offered a solution to this problem with localnets - as long as the cluster is using an on-premise Layer 2 network. Most cloud providers only expose Layer 3 on their networks, however, forcing OpenShift Virtualization customers in cloud environments to redesign their networking architecture. Without direct IP routing in the cloud, virtualization teams were forced to treat VMs like container workloads, adding NodePort Services and Routes that obscured the VMs' IP addresses. Red Hat, Inc. is introducing a new solution: BGP cloud connector, launching for Red Hat OpenShift Service on AWS (ROSA) on cluster versions 4.22 or later. It allows customers to route traffic between an in-cluster overlay network (a ClusterUserDefinedNetwork, or CUDN) and the virtual private cloud (VPC) in which the cluster resides. Customers can then connect the VPC to their corporate networks using AWS's existing solutions (like Transit Gateway or Direct Connect) to achieve end-to-end connectivity between any of their networks and guest VMs in a Red Hat OpenShift Service on AWS cluster. Expanded workload possibilities. Because guest VMs can retain their native IP addresses externally, common challenges now have straightforward solutions. These include: * Firewalls and access control that rely on a packet's source IP address can now differentiate between each VM. This is because traffic from VMs is no longer passed through Network Address Translation (NAT) on worker nodes' IP addresses. * Active Directory Dynamic DNS can now correctly assign domain names to VM domain clients. This is because the Domain Controller sees the same IP address that clients report from their network interfaces. * Clustered software, such as older versions of Valkey, that is designed around clients seeing the same IP address for server cluster members, can now work correctly. This is because machines inside and outside of your cluster all see the same IP address. Demonstration. To see BGP cloud connector in action, let's look at how an EC2 instance in a VPC communicates directly with a VM running inside Red Hat OpenShift Service on AWS without NAT. Figure 1 illustrates a VM guest within my cluster. It has been assigned the IP address 192.168.5.3 from a CUDN that BGP cloud connector has configured the VPC to route to. Figure 1: The VM guest with IP address 192.168.5.3 I'm running a chatbot on that VM, listening on port 8000. [rhel@sample-vm ~]$ hostname -i 192.168.5.3 [rhel@sample-vm ~]$ socat TCP-LISTEN:8000,reuseaddr,fork EXEC:'/usr/bin/cla -i' # Expose the RHEL command-line assistant chatbot on port 8000 I also have an EC2 instance in the same VPC. I can hit my VM's port 8000 directly on its own IP address from the EC2 instance to interact with that chatbot. [ec2-user@ip-10-0-4-42 ~]$ socat - TCP:192.168.5.3:8000 Welcome to the interactive mode for command-line assistant! To exit, press Ctrl + C or type '.exit'. The current session does not include running context. >>> What is BGP? Be concise. +[+]+ Asking the command-line assistant... BGP (Border Gateway Protocol) is a standardized exterior gateway protocol designed to exchange routing and reachability information among autonomous systems (AS) on the internet. It is commonly used between Internet Service Providers (ISPs) to determine the best paths for traffic across the internet. Always review AI-generated content prior to use. How BGP cloud connector works. The Red Hat OpenShift Service on AWS cluster's worker nodes act as routers for traffic between the VPC and the CUDN that the guest VMs sit on. The cluster uses Border Gateway Protocol (BGP) to advertise routes to Amazon VPC Route Server, which updates them in VPC route tables. BGP cloud connector keeps the set of Route Server peers up-to-date as nodes join and leave the cluster. Each route configures the VPC to send traffic for the CUDN's IP range to one of the cluster's worker nodes. The worker node then forwards the traffic to the worker hosting the VM guest. Since VPC route tables only contain one route per IP prefix, Route Server chooses one route at a time to publish. This means that one worker node at a time acts as the router for all incoming traffic for a particular CUDN. If the active gateway node drops offline, Route Server quickly detects the failure over BGP and updates the VPC route table to point to a healthy worker, keeping your VM traffic flowing. Get started. If your architecture requires direct connectivity to VMs' IP addresses, it's straightforward to get started. Follow its product documentation for a detailed guide on how to set up your VPC, install and configure the operator, and deploy your first directly addressable VM. If you don't have a Red Hat OpenShift Service on AWS cluster yet, follow the Quickstart Guide or the Learning Path on Getting Started. If you'd like to learn more about OpenShift's Virtualization's networking concepts, check out the Red Hat webinar on the topic, "Networking OpenShift Virtualization: What you really need to know." Happy virtualizing! 15 reasons to adopt Red Hat OpenShift Virtualization. Discover how Red Hat OpenShift Virtualization can unify and simplify your IT operations, using 1 platform for both virtual machines and containers. Daniel Axelrod is a Specialist Solution Architect at Red Hat, specializing in Red Hat Managed OpenShift offerings on AWS, Azure, and Google Cloud Platform. He has over a decade of experience as a Platform Engineer, helping thousands of engineers ship great software. In his current role, Daniel helps customers remove organizational and technical blockers to be successful with Managed OpenShift as their application platform. Original podcast