The public release of working exploits for four Linux kernel vulnerabilities highlights a critical cybersecurity risk: an attacker who gains limited access to a Linux system may be able to exploit a vulnerability in the kernel to obtain complete administrative control. Security researcher Asim Manizada disclosed DirtyAH6, TUNderflow, PPPoEject and DiagSpill after coordinating with Linux kernel maintainers and distributions to allow security fixes to be released. The exploits became public on September 18, 2026, changing the threat landscape for organisations that have not yet updated their affected systems. Although there were no reported incidents of these vulnerabilities being exploited in real-world attacks at the time of publication, the availability of working exploit code significantly reduces the effort required to investigate and potentially adapt the techniques for vulnerable environments.

The four vulnerabilities affect different components of the Linux kernel's networking subsystem. DirtyAH6, tracked as CVE-2026-80844, involves an out-of-bounds memory write in IPv6 IPsec Authentication Header processing. TUNderflow, CVE-2026-81000, affects TUN/TAP virtual network devices through an integer-wraparound condition associated with buffer calculations. PPPoEject, CVE-2026-68121, is a use-after-free vulnerability in PPP over Ethernet processing. DiagSpill, CVE-2026-74469, involves an integer overflow in SCTP diagnostic reporting that can lead to a substantial out-of-bounds memory write. Despite affecting different networking functions, all four share a common consequence: corruption of kernel memory that the researcher demonstrated could be exploited locally to obtain root privileges. 

The distinction between local and remote exploitation is essential. These vulnerabilities should not be presented as four unauthenticated remote-root exploits. The documented privilege-escalation scenarios generally involve code already executing on the target system. Three of the vulnerabilities require unprivileged user namespaces for an ordinary local user to reach the relevant kernel functionality. DiagSpill does not require user namespaces or special privileges, provided the SCTP networking module is available. Two vulnerabilities have additional remote denial-of-service scenarios under narrow configuration conditions, but these should not be confused with reliable remote root access. The researcher demonstrated remote root with DirtyAH6 only in a laboratory environment after first manipulating the target's memory state and described achieving the same conditions entirely remotely as extremely difficult. 

This distinction does not diminish the seriousness of local privilege escalation. Modern intrusions frequently involve multiple stages, beginning with stolen credentials, vulnerable web applications, malicious dependencies or compromised user accounts. The initial foothold may provide only limited permissions, preventing the attacker from modifying critical system files, accessing protected credentials or disabling security controls. A kernel privilege-escalation vulnerability can remove that restriction. Once an attacker obtains root access, the potential consequences include manipulation of system configurations, access to sensitive files, interference with logging and attempts to establish further persistence. The actual impact depends on the system's architecture and additional security controls, but the transition from an ordinary account to root represents a fundamental security-boundary failure. 

DirtyAH6 is particularly relevant to organisations operating Linux-based networking infrastructure because it affects the processing of IPv6 IPsec Authentication Headers. The vulnerability results from insufficient validation of routing-header information against the number of addresses actually present, allowing a crafted packet to cause an internal pointer to move beyond the intended buffer. Under specific conditions, the issue can also be triggered remotely to crash an IPv6 router or gateway that adds an Authentication Header in transport mode. This does not mean that every Linux firewall or IPsec gateway is remotely exploitable, but it illustrates why networking appliances and systems that process specialised protocols need careful vulnerability assessment even when the affected code is not part of an ordinary application. 

TUNderflow demonstrates another important weakness in virtual networking infrastructure. TUN and TAP interfaces are widely used for virtual networking, VPNs and other applications that require software-defined network interfaces. The vulnerability involves an incorrect buffer-size calculation that can wrap around when an oversized value is introduced through an Open vSwitch-related processing path. This can result in packet data being written outside its allocated memory region. Such weaknesses highlight the complexity of network packet processing, where buffer sizes, metadata and memory offsets must remain consistent across several layers of the networking stack. A calculation error in a low-level subsystem can have consequences far beyond the virtual interface where the malformed data originated. 

PPPoEject involves a use-after-free condition in PPP over Ethernet processing. The vulnerable code retains a pointer into a network buffer while invoking a device operation that may free or relocate that buffer. Subsequent writes can then operate on memory that is no longer valid. Use-after-free vulnerabilities are especially dangerous within privileged software because memory reuse can create opportunities to manipulate objects or internal execution state. Although PPPoE is not relevant to every Linux deployment, it remains important in particular networking environments. Organisations should evaluate whether the affected functionality is present and reachable rather than assuming that an unfamiliar protocol name makes the vulnerability irrelevant. 

DiagSpill presents a different problem involving SCTP diagnostic functionality. A 16-bit counter used to track connection endpoints can wrap to zero when the endpoint count reaches 65,536. The reporting code may then allocate insufficient memory while copying a much larger amount of data, creating an out-of-bounds write of approximately 8 MiB. This illustrates how a relatively simple integer-width mistake can produce substantial memory corruption inside the kernel. The vulnerability is particularly noteworthy because its local exploitation does not require unprivileged user namespaces, although the SCTP module must be available. Its remote denial-of-service scenario additionally requires non-default SCTP options to be enabled. 

The role of unprivileged user namespaces deserves particular attention. Linux user namespaces allow an ordinary user to obtain privileges within an isolated namespace without automatically obtaining those privileges on the host. This feature is useful for containerisation and sandboxing, but it can also make certain privileged kernel code paths accessible to otherwise unprivileged processes. In three of the disclosed vulnerabilities, user namespaces provide the route through which an ordinary user can reach the affected networking functionality. Disabling unprivileged user namespaces can therefore reduce exposure where operationally feasible, but this is not a complete solution. It does not address DiagSpill and may not prevent access by processes or containers that already possess the relevant network-administration capabilities. Changes to namespace configuration can also affect legitimate container workloads, so administrators must evaluate compatibility carefully. 

The potential implications for container environments are significant but should not be overstated. The researcher noted that the vulnerabilities could theoretically support container-escape scenarios, but did not develop a working container-escape exploit. Nevertheless, the findings reinforce an important architectural principle: containers generally share the host kernel, meaning a vulnerability in an accessible kernel subsystem may affect the security boundary separating workloads from the host. Container isolation, reduced Linux capabilities, appropriate namespace restrictions and syscall filtering can reduce exposure, but they cannot substitute for correcting a vulnerable kernel. 

The publication of exploit code also introduces a vulnerability-management challenge. The researcher's exploits are tuned to specific kernel builds and may crash systems when run against incompatible environments. They are not universal tools capable of reliably compromising every vulnerable Linux installation. However, security teams should not mistake that limitation for long-term protection. Public technical research can provide attackers with knowledge about vulnerable code paths, memory-corruption primitives and exploitation approaches that may be adapted over time. The appropriate response is to validate patch coverage promptly rather than relying on the assumption that an available exploit does not currently support a particular distribution. 

Linux distributions complicate version-based vulnerability assessment because enterprise vendors frequently backport security fixes into kernel packages that retain older upstream version numbers. Consequently, a system running a kernel with a numerically older version string is not necessarily vulnerable if its distribution has incorporated the relevant patches. Conversely, an apparently recent kernel may remain exposed if it has not received all four fixes. Organisations should verify the installed kernel package against their distribution's security advisories, confirm that the corrections are included and ensure that the patched kernel is actually running. Installing an updated kernel package without completing the required reboot or live-patching procedure may leave the active system exposed. 

The reported upstream releases containing all four fixes include 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4. These numbers should be treated as upstream references rather than universal version requirements for Debian, Ubuntu, Red Hat, SUSE or appliance-specific Linux distributions. Administrators responsible for embedded systems, security gateways and network appliances should obtain confirmation from their product vendors that the relevant fixes have been incorporated into the actual deployed kernel. 

The age of the underlying defects is another important finding. According to the research, the mistakes existed in kernel code for approximately 10 to 21 years. This demonstrates that mature software is not automatically free of serious vulnerabilities simply because its code has been deployed and reviewed for many years. Complex interactions between memory allocation, packet processing and kernel features may remain difficult to identify through conventional testing. The researcher's AI-assisted approach to mapping memory behaviour and reasoning about kernel layouts illustrates how newer analysis techniques may help discover longstanding weaknesses. However, AI assistance in vulnerability discovery should not be confused with evidence that attackers are currently using AI to exploit these specific CVEs. 
For organisations, the immediate defensive priority is to identify affected systems and install kernels containing all four fixes. Where patching cannot be completed immediately, disabling unprivileged user namespaces where practical and turning off unused AH6, TUN/TAP, PPPoE or SCTP functionality can reduce particular exposure paths. These measures are temporary risk reductions, not verified substitutes for patching. Monitoring should also focus on suspicious local privilege escalation, unexpected loading or use of networking modules, unusual namespace activity and unexplained kernel crashes. Such events are not definitive indicators of these vulnerabilities, but they may justify investigation when correlated with the affected system's patch status and other evidence.

The broader cybersecurity lesson is that preventing initial access and preventing privilege escalation are separate defensive objectives. A firewall may successfully restrict external connections while a compromised application or stolen low-privilege account still creates an opportunity for an attacker to exploit the local kernel. Organisations therefore need layered protection combining vulnerability remediation, least privilege, secure configuration, endpoint monitoring, workload isolation and network segmentation. No single perimeter control can compensate for a vulnerable kernel that allows unprivileged code to obtain root. 

Ultimately, the public release of exploits for DirtyAH6, TUNderflow, PPPoEject and DiagSpill reinforces the urgency of maintaining the security of the operating-system kernel itself. These vulnerabilities affect different networking components but can lead to the same critical outcome when exploited locally: escalation from limited permissions to full administrative control. Their disclosure also demonstrates that longstanding memory-safety defects remain a serious concern in mature infrastructure software, while AI-assisted security research may increasingly help uncover weaknesses that have escaped conventional analysis. 

The central lesson is clear: an attacker does not need to begin with root access if an unpatched kernel can provide it. Organisations must protect against initial compromise, but they must also ensure that a limited foothold cannot become complete control of the system.

A security researcher has released working exploit code for four Linux kernel flaws that each let a local user gain root, the highest level of access on a machine. Kernel maintainers have fixed all four over the past few weeks, so a system running an up-to-date kernel is not affected. But the exploit code is now public, and any machine still running an older kernel should be updated. The flaws

Source: Public Exploits Released for Four Linux Kernel Flaws That Enable Local Root via The Hacker News — published 18 Sep 2026.