Critical Linux Kernel Flaw CVE-2026-98432: What Australian Businesses Must Check Now

SwiftTech Urgent Cybersecurity Bulletin | Monday, 2 November 2026

A newly disclosed weakness in the Linux kernel deserves urgent attention from Australian organisations that operate Linux servers, hosted applications or virtual infrastructure. Tracked as CVE-2026-98432, the flaw affects the way some Linux systems handle incoming IPv4 TCP connections. The Linux kernel CVE record assigns it a CVSS 3.1 severity score of 9.8 (Critical), although individual vendors assess the risk differently for their products.

The concern has grown following security research published by Anthropic on 27 October 2026. Researchers reported that their Claude model developed an exploit capable of remotely running commands as the root administrator on certain Linux servers using Multipath TCP (MPTCP). This was a controlled research demonstration, not evidence that every Linux server is exposed to that exact attack or that criminals are already using it.

The immediate message: businesses should identify their Linux systems, review exposure, confirm the vendor’s patch status and plan safe updates. Do not assume a server is protected simply because automatic updates are switched on.

Important updates since 30 October 2026

Red Hat now calls this a Critical security issue. In its 30 October security bulletin, Red Hat classified CVE-2026-98432 as Critical and said it was expediting fixes for affected products. It also described the risk as extending beyond the MPTCP demonstration to ordinary IPv4 TCP traffic. Organisations using Red Hat or compatible distributions should recheck their vendor guidance urgently.

AWS has released Amazon Linux fixes. Its security bulletin confirms kernel updates for Amazon Linux 2 and 2023. Customers operating their own EC2, ECS or EKS nodes must check which update or machine image applies and ensure the replacement kernel is actually running. AWS is also rolling out infrastructure updates for certain managed services; responsibilities vary by service.

Ubuntu and Debian remain on different timelines. Ubuntu’s tracker continues to show several supported kernels as vulnerable or awaiting release, whereas Debian’s tracker lists fixed security packages for Debian 12 and 13. An installed update does not protect a host that has not yet restarted into the fixed kernel.

Proxmox administrators should check host kernels separately. A Proxmox forum technical discussion traces the fix to kernel build 7.0.14-25-pve, but it is not a substitute for checking the exact supported release, repository and package changelog. Do not infer protection solely from the Debian base OS.

No confirmed widespread attacks were established by the sources checked on 1 November. A documented research exploit is sufficient reason to prioritise exposed systems, but it is not proof that all Linux servers are under attack.

What is CVE-2026-98432?

The problem lies in the Linux kernel, the core software that manages the computer’s hardware, memory and networking. A timing error, called a race condition, can cause the kernel to access memory after that memory has been released. Security professionals call this a use-after-free vulnerability.

The issue occurs in the IPv4 TCP connection-handling code, which many online services rely on. Depending on the affected configuration and how the bug is triggered, the possible consequences include a system crash, a loss of service or corruption of memory. Anthropic demonstrated a more serious outcome in its test environment: unauthorised commands executed with root privileges.

This distinction matters. The technical flaw exists in kernel code used across multiple products, but an exploit that works against one setup is not automatically proven to work on every distribution, kernel build or network service.

For technical readers, see the official CVE record and Anthropic’s original research.

Why does this matter to Australian businesses?

Linux is behind many systems that businesses use every day, even when employees only see a website or a familiar application. Examples include web and application servers, cloud-hosted systems, databases, networking appliances, container hosts and virtualisation platforms.

A vulnerable internet-facing server may create a risk of interruption to business operations. In a more serious compromise scenario, an attacker gaining administrative control could interfere with services, investigate stored data or use the server as a foothold for further attacks. The actual impact depends on the product, patch level, configuration and network exposure.

Businesses often rely on a managed hosting company or software provider for these systems. That is useful, but it also means the business owner may not know which kernel is running or whether a security update is awaiting a reboot. Ask your provider for confirmation, not just reassurance.

Is every Linux machine vulnerable?

No. A server’s status must be checked against its precise operating system, running kernel and vendor security notice. The original vulnerable code dates back to older kernel branches, but vendors frequently backport security fixes into packages that retain an older-looking version number. Comparing a distribution’s version string with a generic upstream Linux release can produce a false result.

The upstream Linux kernel team has released fixes, but the availability of fixed packages differs by operating system. As checked on 1 November 2026, Ubuntu’s live tracker still identifies many supported kernel packages as vulnerable or work in progress; Red Hat’s new Critical bulletin says it is expediting fixes; Debian’s tracker shows fixed packages for Debian 12 and 13; and AWS now provides Amazon Linux 2 and 2023 updates. Always check your vendor’s information for the exact kernel package.

Platform	What businesses should check as of 1 November 2026
Ubuntu	Several LTS and cloud kernel packages remain listed as vulnerable or work in progress; check the current release and kernel flavour against Canonical’s live tracker.
Red Hat Enterprise Linux	Red Hat has issued a Critical bulletin and is expediting vendor fixes. Follow its security bulletin and any compatible distribution’s own advisory.
Debian 12 and 13	Fixed security kernel packages are listed; install the relevant package and confirm the fixed kernel is running after reboot.
Amazon Linux 2 and 2023	AWS reports fixed kernel packages available. Self-managed EC2 and container hosts require the correct update and reboot; managed AWS services have separate guidance.
Proxmox VE	Check the host kernel separately from VMs. A Proxmox forum investigation identifies the fix in 7.0.14-25-pve, but verify against the official kernel package, repository and installed build.
Other cloud and Linux appliances	Confirm who supplies kernel security fixes and who performs the required updates and restarts.

These are 1 November 2026 snapshot notes, not permanent patch guarantees. Vendor status can change quickly. A fixed version may have been backported into a kernel whose version string looks older than an upstream release. For Proxmox, a Debian guest’s update cannot establish that the separate host kernel is safe.

What did Anthropic actually demonstrate?

Anthropic reported that its research model constructed a multistage exploit for Linux servers with an MPTCP listener, a special kind of TCP service that can support multiple network paths. The researchers said the exploit could run commands as root remotely without a password or user interaction.

That is a powerful demonstration. It also has clear limits: Anthropic did not establish that every ordinary TCP service is exploitable in precisely the same way. Importantly, Red Hat updated its assessment on 30 October, rating the vulnerability Critical and warning that remotely triggered memory corruption or denial of service can occur through standard IPv4 TCP traffic. Its new guidance says fixes are being expedited. Limiting MPTCP may reduce some exploit conditions, but disabling MPTCP alone does not close the underlying vulnerability.

As of the source review on 1 November 2026, we have not verified confirmed malicious exploitation in the wild. Businesses should respond promptly to this credible, exploitable vulnerability without claiming that every Linux server has been compromised.

Seven practical checks businesses should make now

1. Identify your Linux systems

Ask your IT team or hosting provider for an inventory of Linux servers, virtualisation hosts, cloud machines and appliances. Include systems running websites, backups, databases and remote-access tools. Note the operating system, exact kernel package and who maintains it.

2. Check the running kernel, not just installed updates

A security update can be downloaded while the server continues running an older kernel. The administrator should verify the running version and match it to the vendor’s fixed package information. Arrange a controlled reboot where the update requires one.

3. Prioritise systems reachable from the internet

Start with public web and application servers, exposed remote-access systems and externally reachable management services. Review firewall and access rules. Remove unnecessary external access and keep administration available only through approved secure channels.

4. Review Multipath TCP use carefully

Ask whether any service uses MPTCP. Anthropic’s research exploit targeted an MPTCP listener, so those systems deserve particular attention. MPTCP being enabled does not prove a listening service exists. AWS describes disabling MPTCP as a temporary way to reduce some exploit conditions, not a fix. The vulnerable code can still be reached through ordinary IPv4 TCP processing; changes must be assessed by your administrator before deployment.

5. Install the vendor’s supported fix when available

Use approved operating-system or appliance updates and reboot when required. Avoid untrusted third-party kernel patches or blindly replacing the kernel on a production server. Where the vendor has not released a fix, document the exposure and assess temporary protections. Red Hat’s updated guidance describes filtering incoming IPv4 TCP packets that carry IP options as a partial mitigation, warning that it could disrupt necessary traffic and is not a substitute for patching. Such network changes should only be made by a qualified administrator after testing.

6. Check for suspicious activity and protect backups

Review unexpected restarts, service outages and unusual access or system changes. Ensure business-critical data and server configurations have recent, tested backups. A backup is only useful if it can be restored when needed.

7. Confirm the server is healthy afterwards

After maintenance, verify remote access, websites, applications, scheduled jobs, monitoring and backups. Keep a record of the new running kernel and the advisory used to confirm the fix. For containers and virtual machines, remember to patch the underlying host as well as any separately vulnerable guest kernels.

Quick checks for your IT administrator

The following read-only commands help gather information on a Linux host. They do not prove that a system is vulnerable or patched:

cat /etc/os-release
uname -r
sysctl net.mptcp.enabled
ss -lntp
ss -Mlnp

The ss -Mlnp option is available on systems with a suitably recent iproute2 package and displays MPTCP listening sockets. A setting of net.mptcp.enabled = 1 by itself does not establish that an MPTCP service is listening. If a command is unsupported, your administrator should use the platform’s documentation rather than making assumptions.

What if an update is not yet available?

Do not wait for a serious incident, but do not make untested changes to a business-critical system. Ask for a documented risk review, limited external access, tighter management restrictions and enhanced monitoring. Keep track of the official vendor advisory and arrange the update as soon as the appropriate release is available. Consider an emergency change window for high-exposure services.

The best response is prioritised patch management backed by verified recovery, not a rushed change that creates an avoidable outage.

Research updated on 1 November 2026 for publication on Monday, 2 November 2026. CVE severity and vendor patch availability can change; always use the current vendor advisory for your exact product and kernel package before upgrading.