Security Updates on KnightLi Blog

The AI Vulnerability Discovery Era Has Arrived: Why Copy Fail, Dirty Frag, Fragnesia, and ssh-keysign-pwn Clustered Together

Thu, 21 May 2026 09:30:01 +0800

In recent weeks, Linux kernel vulnerabilities have appeared in rapid succession: Copy Fail, Dirty Frag, Fragnesia, and ssh-keysign-pwn have all entered security discussions. Some allow local privilege escalation, some can expose highly sensitive files, and some affect container hosts and multi-tenant environments. Many people’s first reaction is: why did Linux suddenly become so insecure?

A more accurate answer is: Linux did not suddenly get worse. Long-hidden problems are being found faster and more systematically.

What really matters in this wave is not just the fixes for a few CVEs, but the change in how vulnerabilities are discovered. In the past, only a small number of top researchers could spend a long time connecting cross-subsystem logic bugs. Now AI-assisted auditing, automated static analysis, fuzzing, and security research platforms are amplifying that work. The vulnerabilities did not appear overnight, but the speed at which they are found, reproduced, and spread has increased.

What These Vulnerabilities Have in Common

First, put the recent incidents side by side.

Vulnerability	Main Impact	Key Characteristics	Risk Focus
Copy Fail / CVE-2026-31431	Local privilege escalation	Linux crypto / AF_ALG related path, involving a page cache write issue	Ordinary user to root; especially sensitive in container environments
Dirty Frag / CVE-2026-43284, CVE-2026-43500	Local privilege escalation	Page cache write primitive in XFRM/ESP, RxRPC, and related paths	Chainable exploitation; affects host and container boundaries
Fragnesia / CVE-2026-46300	Local privilege escalation	Logic issue in the XFRM ESP-in-TCP subsystem	Related attack surface to Dirty Frag
ssh-keysign-pwn / CVE-2026-46333	Local sensitive information disclosure and privilege escalation risk	Linux kernel `__ptrace_may_access()` logic flaw	Risk to SSH host keys, `/etc/shadow`, and other sensitive files

They are not the same vulnerability, but several patterns repeat:

They are not traditional remote RCE issues, but local privilege escalation or local sensitive information disclosure.
They require attackers to first obtain some kind of local execution, such as a normal shell, command execution inside a container, CI task permissions, or a low-privilege account.
Most of the risk sits at kernel boundaries: page cache, crypto/network subsystems, ptrace permission checks, and container-shared kernels.
Modern cloud-native environments amplify the blast radius, because containers are not a strong security boundary and the host kernel remains the shared base.

So the question is not only “is there a patch?” The deeper question is: why did these low-level, hidden, long-dormant issues appear in such a short period?

First Reason: Many Bugs Are Historical Debt, Not Newly Written Code

When people see a vulnerability disclosure date, they often assume the bug was introduced recently. That is often not true.

The key point of issues like Copy Fail is that a vulnerability can remain dormant for years until someone connects the right call path, permission boundary, and memory semantics. Public information indicates that Copy Fail relates to kernel optimization history around 2017. Dirty Frag and Fragnesia also point to deep cross-paths involving networking, crypto, and page cache.

The scary part is not that one line of code obviously looks dangerous. It is that several assumptions happen to overlap:

A subsystem performs in-place processing for performance.
An interface allows unprivileged users to reach kernel functionality.
A path connects read-only file pages, page cache, network fragments, and crypto buffers.
An implicit invariant was never written into types, assertions, or documentation.
The result becomes a path where an ordinary user can affect kernel state that should be out of reach.

This is not the kind of issue ordinary code review is best at finding. One reviewer may understand the crypto subsystem, another the network subsystem, and a third memory management. The bug lives at their intersection.

Second Reason: Linux Kernel Complexity Has Outgrown Manual Review

Linux’s strengths are openness, generality, broad hardware support, and a powerful ecosystem. Those strengths also carry costs.

The modern Linux kernel is not a small kernel. It includes scheduling, memory management, filesystems, network protocols, crypto frameworks, drivers, virtualization, container-related mechanisms, eBPF, LSM, security modules, and hardware platform support. Each subsystem has its own history, maintainers, performance goals, and compatibility baggage.

The problem is that vulnerabilities often do not live inside one module. They live where modules intersect:

splice() connects file pages and pipes.
AF_ALG connects user space to the kernel crypto API.
XFRM/ESP connects network packets, crypto, and memory pages.
RxRPC and ESP-in-TCP make the network stack more complex.
Containers make low-privilege local execution a much more common real-world precondition.

From an engineering perspective, the Linux kernel is no longer small enough for “many eyes” to reliably inspect every corner. Open source makes problems easier to fix and review, but it does not mean every corner receives continuous security review. Very few people can understand cross-subsystem vulnerabilities, and those are exactly the bugs that can have large impact.

Third Reason: Performance Optimizations Often Thin the Security Boundary

One theme appears repeatedly in this wave: reducing copies, reusing buffers, and processing data in place for performance.

These optimizations are reasonable. The kernel is infrastructure. A small performance loss can affect cloud providers, databases, networking, storage, and container platforms. One fewer copy, faster encryption/decryption, or one fewer memory allocation can matter in production.

But the security cost is also clear. When the boundaries between read-only data, shared pages, user-controlled input, kernel buffers, and crypto output become thin, one subsystem’s misunderstanding of input/output contracts can cause unauthorized writes or reads.

In other words, performance optimization itself is not wrong, but it creates more fragile combinations:

In-place encryption/decryption reduces copying, but relies more on correct isolation of input and output buffers.
Page cache improves file access performance, but can also become attack surface.
Zero-copy improves throughput, but lets different subsystems share the same memory objects.
Containers improve deployment efficiency, but shared kernels make the blast radius of local privilege escalation larger.

Security boundaries cannot rely on everyone remembering not to make a mistake. They have to be enforced through types, permission checks, immutability constraints, tests, fuzzing, and continuous auditing. Otherwise, the more performance optimizations and implicit assumptions accumulate, the more likely these bugs are to be found.

Fourth Reason: Containers Raise the Value of Local Vulnerabilities

In the past, “local privilege escalation” often sounded less urgent than remote vulnerabilities because the attacker already needed local access. Cloud-native environments changed that judgment.

Today, local execution can come from many places:

A web application turns into a normal shell.
A CI/CD task executes untrusted code.
A container runs user-uploaded workloads.
A multi-tenant platform lets users run notebooks, plugins, scripts, or build jobs.
AI code execution environments, sandboxes, and online judges are becoming more common.

Once an attacker has execution inside a container, kernel LPE is no longer just a “local machine” issue. Containers share the host kernel, so a kernel vulnerability can cross the container boundary and affect the host and other tenants.

This is why Copy Fail and Dirty Frag attract so much attention from cloud, security, and container teams. They can upgrade “low-privilege local code execution” into “host-level risk.”

AI’s Impact: The Cost of Finding Vulnerabilities Has Dropped

The most era-defining part of this wave is AI-assisted vulnerability discovery.

Public information about Copy Fail mentions Theori’s Xint Code participating in the discovery process. Whatever the exact tool capabilities, this represents a trend: AI does not necessarily invent vulnerabilities out of thin air, but it is very good at helping researchers shorten the search path.

AI affects vulnerability research in several ways:

Faster reading of unfamiliar code
Kernel subsystem codebases are large. Researchers cannot manually read every path. AI can help summarize functions, call chains, input/output relationships, and suspicious patterns.
Easier discovery of cross-module connections
Many vulnerabilities hide in chains such as “user-space entry -> network stack -> crypto framework -> memory pages -> file cache.” AI can help map these cross-file, cross-directory, cross-subsystem paths.
Easier generation of audit hypotheses
Questions like “which paths write user-controlled data into page cache,” “which APIs let unprivileged users reach crypto subsystems,” and “which functions assume input and output buffers never overlap” can now be enumerated more systematically.
Easier conversion into reproducible examples
AI cannot replace the judgment of kernel researchers, but it can help write validation code, organize PoC ideas, explain faulty paths, and generate tests.

The result is a lower unit cost for vulnerability discovery.

In the past, a high-quality kernel vulnerability might take elite researchers a long time to find. Now, someone who understands systems and has AI tools can triage suspicious paths faster. The ceiling on vulnerability supply has risen, making clustered disclosures more likely.

But AI Is Not the Only Reason

There is another extreme to avoid: blaming everything on AI.

AI is an accelerator, not the root cause. The real roots are still:

Long accumulation of historical code.
Implicit contracts in performance optimizations that were never enforced.
Excessive cross-subsystem complexity.
Too much kernel functionality exposed by default.
Security tests that do not cover all combined paths.
Containers, multi-tenancy, and automated execution environments raising the value of local vulnerabilities.

Without those conditions, even powerful AI would not find so many high-impact bugs. Conversely, as long as these conditions exist, more mature AI will make vulnerabilities easier to find systematically.

What This Means for Defenders

For operations, security, and platform teams, this wave has several direct lessons.

First, stop treating local privilege escalation as low priority.
If your environment has containers, CI, online execution, plugins, notebooks, or multi-tenant workloads, local privilege escalation can become host risk.

Second, kernel patch cadence must get faster.
Critical hosts, Kubernetes nodes, CI runners, AI sandboxes, and virtualization hosts should not stay on old kernels for long periods. Kernel updates, reboot windows, live patching, and rollback plans need explicit processes.

Third, reduce unnecessary kernel attack surface.
Protocols, modules, user namespaces, special sockets, and debugging interfaces that are not needed should be tightened according to business needs. Enabled by default does not mean exposed by default.

Fourth, container security should assume the kernel may be broken.
Running containers as non-root, minimizing capabilities, using seccomp, AppArmor/SELinux, read-only filesystems, and isolating sensitive mounts remain important. They may not stop every kernel bug, but they reduce preconditions and follow-on damage.

Fifth, monitoring should focus on privilege escalation chains.
Do not only watch remote entry points. Also watch abnormal processes, sensitive file reads, kernel module loading, container escape signals, CI runner anomalies, and access to high-value files such as /etc/shadow and SSH host keys.

What This Means for Open Source Communities

For Linux and large open source projects, AI-assisted vulnerability discovery creates a two-sided pressure.

On one hand, AI can help defenders find old problems faster. More latent vulnerabilities being publicly fixed is good in the long run.

On the other hand, AI also creates noise. Low-quality automated reports, false positives, duplicates, and “AI found a bug” claims without context consume maintainer time. The real challenge is not whether to use AI, but how to bring AI output into responsible security processes:

Reports need minimal reproduction.
Reports must define impact scope and threat model.
Reports must distinguish theoretical issues, triggerable bugs, and exploitable vulnerabilities.
Embargoes, distribution coordination, and fix windows must be respected.
Maintainers need better automated tests, fuzzing, static analysis, and regression validation.

AI makes vulnerability discovery faster, and that requires more mature repair and coordination mechanisms. Otherwise, higher security research productivity becomes maintainer pressure and user panic.

Conclusion: Not Myth Collapse, But a Changed Security Reality

Linux remains one of the most transparent, controllable, fixable, and hardenable foundations in mainstream operating system infrastructure. The issue is not that Linux suddenly became insecure. It is that modern kernel complexity, cloud-native usage patterns, and AI-assisted vulnerability discovery are changing the speed of vulnerability exposure.

Similar events are likely to appear again. Not because every time is a new disaster, but because complex paths accumulated in the past are now being searched more efficiently.

The security assumptions need to change:

Do not treat “no disclosed vulnerability” as “no vulnerability.”
Do not treat local privilege escalation as low risk.
Do not treat container isolation as a strong security boundary.
Do not rely only on manual review for systems with tens of millions of lines of code.
Do not wait only for patches; shrink attack surface, speed up patching, and build defense in depth.

AI has pushed vulnerability discovery into a higher-output era. That is true for attackers and defenders. The difference is whether defenders can turn that capability into faster auditing, earlier fixes, and more stable infrastructure governance.

References

Impact Summary of Four Recent Linux Local Security Issues: Copy Fail, Dirty Frag, Fragnesia, and ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

Several high-profile local security issues have appeared in the Linux ecosystem recently. Individually, they involve different areas: crypto interfaces, network and IPsec paths, page cache handling, and ptrace access checks. Together, they point to the same operational lesson: once an attacker has a low-privilege local execution point, the risk to Linux hosts, container nodes, CI machines, and multi-user servers increases sharply.

This article does not repeat all technical details of each vulnerability. Instead, it summarizes their practical impact and links to four separate articles on this site for deeper reading.

What the Four Events Affect

The four risks worth tracking are:

Copy Fail (CVE-2026-31431): a low-privilege local user may affect the page cache through kernel crypto-related paths and expand privileges.
Dirty Frag (related to CVE-2026-43284 / CVE-2026-43500): risk centers on xfrm/ESP, RxRPC, and related network and kernel data paths, making it dangerous in post-compromise scenarios.
Fragnesia (CVE-2026-46300): close to Dirty Frag, involving XFRM ESP-in-TCP, shared fragments, and page-cache write risk.
ssh-keysign-pwn (CVE-2026-46333): not a direct root-shell bug, but a local information disclosure risk that may expose SSH host private keys, /etc/shadow, and other sensitive files.

The entry points differ, and so do the mitigations. Fixing Copy Fail does not automatically cover Dirty Frag or Fragnesia. Disabling some network modules does not automatically remove the information disclosure risk around ssh-keysign-pwn.

Copy Fail: High Priority for Containers and CI Nodes

The key impact of Copy Fail is not an application crash. It is that low-privilege execution may be turned into root privileges. It is especially sensitive in these environments:

CI/CD nodes that allow users to upload or run code.
Container hosts running untrusted workloads.
Development machines, jump hosts, and shared servers.
Cloud hosts running older kernels with slower patch cycles.

The danger is that Copy Fail has a relatively low exploitation threshold and combines easily with container scenarios. Many teams treat containers as a strong isolation boundary, but ordinary containers still share the host kernel by default. If an attacker gets a shell inside a container, a kernel LPE can turn a container issue into a host issue.

Detailed analysis: Copy Fail CVE-2026-31431: Container Escape Risk in a Linux Kernel File-Copy Path.

Dirty Frag: A Post-Compromise Amplifier

Dirty Frag is more like a privilege amplifier after an attacker has entered a system. It is not a typical remote unauthenticated vulnerability. The usual prerequisite is that the attacker already has local execution through a weak password, WebShell, low-privilege service account, container task, or another foothold.

Its practical impact appears in several places:

A compromised low-privilege account may become root.
A low-privilege execution point inside a container may threaten the host.
Systems using IPsec, ESP, RxRPC, or related kernel networking capabilities need careful patch and mitigation review.
Security teams should look beyond perimeter defense and include post-compromise privilege escalation chains.

Dirty Frag reminds operations teams that local privilege escalation may not be the first entry point, but it can decide how far an intrusion goes. Once a low-privilege foothold exists, attackers will look for kernel bugs to push privileges to the highest level.

Detailed analysis: Dirty Frag CVE-2026-43284: Linux Local Privilege Escalation Risk and Mitigation Guide.

Fragnesia: Similar Attack Surfaces Are Not Cleaned Up All at Once

Fragnesia matters because it shows that the attack surface near Dirty Frag is not an isolated one-off issue. Even if one bug is fixed, neighboring paths, similar data structures, and related module combinations may still contain new exploitable points.

Its operational impact is mainly:

Do not handle only the vulnerability name once. Keep checking by attack surface.
esp4, esp6, rxrpc, XFRM, and ESP-in-TCP should be evaluated against actual business dependencies.
If a system does not depend on the related network capabilities, temporary disabling may be considered, but it must be tested first to avoid breaking VPN, IPsec, tunnels, or internal networking.
Page-cache pollution risks can create detection blind spots where files appear unchanged, but the execution path is affected.

For enterprises, the biggest lesson is that patch management should not look only at a single CVE. A safer approach is to build an inventory around subsystems and attack surfaces, then identify which machines expose the relevant capabilities and which services truly need those modules.

Detailed analysis: Fragnesia (CVE-2026-46300): Linux Kernel Local Privilege Escalation Impact and Mitigation.

ssh-keysign-pwn: Not Direct Root, Still Dangerous

ssh-keysign-pwn differs from the previous three. It is more of a local sensitive information disclosure issue than a direct root-shell vulnerability. But in real attacks, sensitive information disclosure can quickly become a larger incident.

The main impacts include:

Leaked SSH host private keys may damage host identity trust.
Access to files such as /etc/shadow can lead to offline cracking and account takeover.
Multi-user servers, jump hosts, build machines, and shared development machines carry higher risk.
Even without immediate privilege escalation, attackers may obtain credential material useful for lateral movement.

This type of issue is easy to underestimate because it does not look as dramatic as a direct root shell. In enterprise environments, however, key and password-hash exposure often means a longer cleanup cycle: rotating SSH host keys, reviewing trust relationships, checking account passwords, and auditing login logs.

Detailed analysis: ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk.

Shared Impact: Containers Are Not a Strong Boundary by Default

Taken together, these four events make one point clear: ordinary container isolation is not virtual-machine isolation.

Docker, containerd, and Kubernetes use namespaces, cgroups, capabilities, seccomp, AppArmor, and SELinux to reduce attack surface, but they usually still share the host kernel. If the vulnerability is in the shared kernel, a low-privilege execution point inside a container can become an entry point.

High-risk environments should check:

Whether untrusted code is allowed to run on shared hosts.
Whether containers run as root by default.
Whether unnecessary capabilities are granted.
Whether seccomp policies are too broad.
Whether multi-tenant workloads should move to gVisor, Kata Containers, Firecracker microVM, dedicated virtual machines, or dedicated nodes.

CI/CD platforms deserve special attention. Build jobs naturally run external code, dependency install scripts, test scripts, and temporary binaries. If these jobs share hosts with long-running services, one local privilege escalation can affect much larger infrastructure.

Shared Impact: Patches Must Reach the Running Kernel

A common Linux kernel patching mistake is assuming that an installed package means the machine is running the fixed kernel.

At minimum, operations teams should verify three things:

`1`	`uname -a`

Check the currently running kernel.

`1`	`dpkg -l \| grep linux-image`

Or on RHEL-family distributions:

`1`	`rpm -qa \| grep kernel`

Check installed kernel packages.

Finally, confirm that the machine has rebooted into the fixed kernel. For core services that cannot reboot immediately, evaluate livepatch, hot patching, or short-term isolation, but do not treat temporary mitigation as the final fix.

Shared Impact: Attack Surface Reduction Must Be Specific

These vulnerabilities remind us that Linux hardening cannot stop at “update the system” and “enable a firewall.”

More specific checks include:

Whether AF_ALG / algif_aead is used by business workloads.
Whether XFRM, ESP, ESP-in-TCP, and IPsec are required by VPNs, tunnels, or security gateways.
Whether RxRPC is needed.
Whether unprivileged user namespaces must be enabled.
Whether containers can create overly broad socket types.
Whether ptrace access policies are too loose.

If the business does not need certain capabilities, evaluate disabling modules, adjusting sysctl settings, tightening seccomp, and reducing capabilities. Do not blindly copy commands into production. Inventory dependencies first, then roll out changes gradually.

Suggested Response Order

First, prioritize machines where local code execution is exposed:

Container hosts.
CI/CD runners.
Jump hosts.
Multi-user servers.
Hosts running external-facing services.
Systems running untrusted plugins, scripts, or extensions.

Second, confirm distribution advisories and the actual running kernel. Do not rely only on upstream version numbers. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, openEuler, and other distributions may backport security fixes.

Third, tighten container runtime policies. Prefer non-root users, minimal capabilities, no-new-privileges, read-only filesystems, and explicit seccomp plus AppArmor or SELinux policies.

Fourth, review key and credential exposure. Especially for environments affected by ssh-keysign-pwn, evaluate whether SSH host keys, /etc/shadow, jump-host credentials, and CI secrets need rotation.

Fifth, improve monitoring. Watch for abnormal root shells, suspicious local LPE PoCs, critical file changes, abnormal ptrace behavior, container processes accessing host paths, and unusual network connections from CI nodes.

Conclusion

The point of these four events is not “Linux is insecure.” The point is that default trust is no longer enough.

Linux remains transparent, fixable, configurable, and hardenable. But in environments where containers, CI, multi-tenancy, and AI-driven code execution are increasingly common, a low-privilege execution point can no longer be treated as a minor issue. If the kernel contains exploitable local privilege escalation or sensitive information disclosure bugs, a partial intrusion can become host control, credential exposure, or lateral movement.

A more realistic approach is to treat these four events as a reminder: patch quickly, confirm rebooted kernels, enable modules only when needed, tighten containers, make key rotation possible, and reassess isolation levels for multi-tenant workloads.

Next.js High-Severity SSRF CVE-2026-44578: Impact Scope and Upgrade Guidance

Sun, 17 May 2026 17:27:13 +0800

Next.js disclosed a high-severity SSRF vulnerability in May 2026: CVE-2026-44578.

According to the GitHub / Vercel advisory GHSA-c4j6-fc7j-m34r and the NVD record, the issue affects self-hosted Next.js applications that use the built-in Node.js server and are exposed to malicious WebSocket upgrade requests. An attacker may cause the server to proxy requests to arbitrary internal or external destinations, exposing internal services or cloud metadata endpoints.

Vercel-hosted deployments are not affected. The fixed versions are 15.5.16 and 16.2.5.

Short Version

If you run Next.js on your own servers, containers, Kubernetes, ECS, VPS, bare metal, or a self-managed PaaS, check this first.

Affected ranges:

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

Unaffected or lower-risk cases:

Applications deployed on Vercel.
Applications upgraded to 15.5.16, 16.2.5, or later.
Deployments that do not expose the built-in Node.js server.
Environments where reverse proxies or load balancers already block unnecessary WebSocket upgrades and outbound access is restricted.

Recommended response order:

Confirm the next version actually running in production.
Upgrade self-hosted applications to a patched version as soon as possible.
If you cannot upgrade immediately, block unnecessary WebSocket upgrades at the reverse proxy or load balancer.
Restrict application servers from reaching cloud metadata, internal admin panels, and sensitive internal services.
Review recent WebSocket upgrade requests and internal access logs.

What the Vulnerability Is

CVE-2026-44578 is a Server-Side Request Forgery vulnerability, or SSRF.

The core risk of SSRF is that an attacker does not access internal systems directly. Instead, they make your server send requests on their behalf. Servers often sit closer to private networks, cloud platforms, and internal services, so if a server becomes a proxy, it may reach resources the attacker could not otherwise access.

In this Next.js case, the issue is in the WebSocket upgrade handling path. The advisory says that self-hosted applications using the built-in Node.js server can be made to proxy requests to arbitrary internal or external destinations through crafted WebSocket upgrade requests.

Risk areas include:

Internal HTTP services.
Admin panels.
Cloud metadata endpoints.
Container or cluster-internal services.
Internal APIs that only the server can reach.

The CVSS v3.1 score is 8.6 High, with this vector:

`1`	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`

That means the attack is network reachable, low complexity, requires no privileges or user interaction, and primarily affects confidentiality.

Why Self-Hosting Is Riskier

The advisory explicitly states that Vercel-hosted deployments are not affected.

The focus is self-hosted deployments. Their network environments vary widely: some expose the origin server directly, some sit behind Nginx, Traefik, Ingress, Cloudflare, ALB, or a custom gateway, and some run in cloud VMs, container networks, or Kubernetes clusters.

If outbound traffic is not restricted, the Next.js process may be able to reach:

Cloud metadata addresses such as 169.254.169.254.
Private IP ranges.
Services exposed only inside a VPC.
Internal Redis, Elasticsearch, Prometheus, Grafana, and similar components.
Kubernetes Services, Pods, or management endpoints.

So the danger is not only in Next.js itself. It depends on what the Next.js server can access from its network position.

How to Check Exposure

First, check the next version.

Run this in the project directory:

`1`	`npm ls next`

Or:

`1`	`pnpm why next`

You can also inspect:

cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

If the version falls in these ranges, you need to act:

1
2

>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

Second, check the deployment model.

Pay close attention to:

Production services started with next start.
Custom Node.js servers hosting Next.js.
Docker images that start a Next.js server directly.
Kubernetes / ECS / VPS / bare-metal self-hosting.
A Next.js origin still reachable behind a reverse proxy.
Application networks that can reach internal services or cloud metadata.

If the application is deployed on Vercel, the official advisory says it is not affected by this vulnerability. Still, keep Next.js updated, because adjacent releases may contain other security fixes.

What Version to Upgrade To

The official patched versions are:

15.5.16
16.2.5

Upgrade example:

`1`	`npm install next@15.5.16`

Or, if you are on 16.x:

`1`	`npm install next@16.2.5`

pnpm:

`1`	`pnpm add next@15.5.16`

Or:

`1`	`pnpm add next@16.2.5`

Then rebuild and redeploy:

1
2

npm run build
npm run start

Or follow your CI/CD process to rebuild and publish the Docker image.

If your project is pinned to 14.x or 15.x, do not rush into a major upgrade to 16.x just for this fix. A safer path is to upgrade to the 15.5.16 patch line first, test and release, then plan a major-version migration separately.

Temporary Mitigations

If you cannot upgrade immediately, the advisory’s core guidance is: do not expose the origin server directly to untrusted networks; block WebSocket upgrades at the reverse proxy or load balancer if they are not required; and restrict outbound access from the origin where possible.

Consider these mitigations:

Do not expose the Next.js origin server directly.
Filter unnecessary WebSocket upgrades at Nginx, Ingress, ALB, Cloudflare, or similar entry points.
If the business does not use WebSockets, reject requests with upgrade semantics.
Apply egress restrictions to block access to cloud metadata and sensitive internal ranges.
Use safer cloud metadata modes where available, such as token-required metadata services.
Add authentication and network isolation around admin panels, databases, caches, and monitoring systems.

Reverse proxy rules are temporary mitigations, not a replacement for upgrading. Framework vulnerabilities should ultimately be fixed by moving to patched versions.

Operational Review

Because this issue mainly affects confidentiality, the key question is whether the server was used to reach internal resources.

Review:

Web logs for abnormal Upgrade, Connection, Host, paths, and source IPs.
Reverse proxy or load balancer logs for unusual WebSocket upgrade requests.
Abnormal outbound connections near the Next.js service.
Cloud metadata access logs or credential usage records.
Unusual access to internal admin services, monitoring, caches, or search systems.
Abnormal IAM temporary credential, access key, or token usage.
Suspicious processes, downloads, or lateral movement on containers or hosts.

If exploitation is suspected:

Preserve logs and evidence.
Rotate potentially exposed cloud credentials, API keys, database passwords, and session secrets.
Review recent cloud account API calls.
Check internal service access records.
Rebuild affected containers or hosts.
Revisit egress controls and metadata protection.

Not the Same as the React/Next.js RCE

One common source of confusion: CVE-2026-44578 is a Next.js WebSocket upgrade SSRF, not the earlier React Server Components RCE.

Its core impact is making the server request attacker-chosen internal or external addresses. The main risk is information exposure and internal resource probing.

React Server Components RCE issues are code execution risks, with different consequences and patch ranges.

So do not stop at the headline “Next.js has a vulnerability.” Map the exact CVE to the affected versions, deployment model, and fixed versions.

Teams That Should Prioritize This

Highest priority:

Self-hosted Next.js production sites.
Deployments on cloud VMs, containers, Kubernetes, or internal networks.
Application servers that can access cloud metadata services.
Application servers that can reach internal admin panels, databases, caches, or monitoring systems.
Directly exposed next start origin servers.
Older next versions with unclear upgrade ownership.

Lower priority:

Applications fully deployed on Vercel.
Applications already upgraded to patched versions.
Origins not directly exposed, with entry layers blocking unnecessary WebSocket upgrades.
Strict outbound network control preventing access to sensitive internal resources.

Lower priority does not mean “do not upgrade.” Next.js is a high-exposure framework, and long-stale framework versions accumulate risk quickly.

Developer Checklist

Use this checklist:

Confirm the next version in every repository.
Identify all self-hosted deployments, not only Vercel projects.
Mark services using next start or the built-in Node.js server.
Upgrade to 15.5.16, 16.2.5, or later.
Rebuild and publish production images.
Block unnecessary WebSocket upgrades at the entry layer.
Restrict application server access to cloud metadata and sensitive internal ranges.
Review recent abnormal upgrade requests and outbound access.
Rotate credentials that may have been exposed.
Add Next.js security updates to the dependency update process.

Summary

CVE-2026-44578 is a high-severity Next.js SSRF vulnerability that deserves prompt attention.

It does not affect Vercel-hosted deployments, but it covers a broad range of self-hosted Next.js applications: from 13.4.13 up to before 15.5.16, and from 16.0.0 up to before 16.2.5. The trigger is the WebSocket upgrade handling path. An attacker may cause the server to proxy requests to internal or external addresses, potentially exposing internal services or cloud metadata endpoints.

The direct fix is to upgrade to 15.5.16 or 16.2.5. Temporary mitigations are to avoid exposing the origin server directly, block unnecessary WebSocket upgrades, and restrict outbound access from the application server.

For operations teams, the important point is not only the CVE score. It is what your Next.js server can reach from its network position. With SSRF, the real impact often depends on internal resources and cloud permissions behind the server.

References:

ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn refers to a set of exploitation paths around a logic flaw in Linux kernel __ptrace_may_access(), assigned CVE-2026-46333. It is not a remote unauthenticated flaw and it does not directly hand out a root shell, but the risk is still high: a low-privileged local user may read root-owned sensitive files that should be inaccessible, such as SSH host private keys or /etc/shadow.

For operations teams, the priority is not reproducing a PoC. The priority is to identify affected machines, upgrade the kernel, reboot into the fixed kernel, and rotate SSH host keys or reset passwords when necessary.

Bottom line

This vulnerability deserves high handling priority for four reasons:

It can be triggered by a low-privileged local user and does not require root.
Public PoC code is available, lowering the exploitation barrier.
The potential targets are not ordinary files, but SSH host private keys and /etc/shadow.
The fix requires a kernel patch and reboot; installing packages without rebooting is not enough.

If your servers have multiple users, local shell access, shared hosting, CI runners, container hosts, student lab machines, bastion hosts, or any local users you do not fully trust, handle this first.

What the vulnerability is

Qualys disclosed details on oss-security on May 15, 2026. They had previously reported a Linux kernel __ptrace_may_access() logic issue to security@kernel.org, and the upstream fix had already been merged by Linus. Public exploit code then appeared, so Qualys posted the details to oss-security.

The Linux kernel CVE team later assigned CVE-2026-46333. The NVD page lists kernel.org as the source, and the description maps to the kernel commit ptrace: slightly saner 'get_dumpable()' logic.

In simple terms, the bug sits in a process exit path. When some privileged processes are exiting, ptrace-related access-check logic in the kernel may bypass a dumpable check that should have applied because the target task no longer has an mm. An attacker can race a very narrow timing window and obtain file descriptors that the exiting privileged process still has open.

That is why the issue is called ssh-keysign-pwn: one public exploitation path uses ssh-keysign to read SSH host private keys.

Why SSH host private keys and /etc/shadow may be exposed

At its core, this is a local information disclosure issue. It abuses a window during privileged process exit where the memory descriptor is gone, but file descriptors have not yet been closed.

The AlmaLinux advisory explains the risk clearly: if a privileged program opened sensitive files before dropping privileges, and an attacker successfully grabs the corresponding file descriptor during the exit window, those sensitive files may become readable.

Two commonly discussed targets are:

ssh-keysign: may involve SSH host private keys such as /etc/ssh/ssh_host_*_key.
chage: may involve /etc/shadow.

If SSH host private keys leak, an attacker may impersonate the host and undermine SSH host identity trust. If /etc/shadow leaks, an attacker can crack password hashes offline and expand the compromise later.

That is why this should be treated as high priority even though it is not a “direct root shell” bug.

How to assess exposure

From the upstream perspective, this is a Linux kernel vulnerability. NVD records show the issue entered the NVD dataset on May 15, 2026, with no CVSS score assigned at that time.

Distribution status should be checked against each vendor’s own advisory:

AlmaLinux 8, 9, and 10 published guidance and updated it on May 16, 2026 to say patched kernels had reached production repositories.
Debian Security Tracker lists vulnerable and fixed states, plus fixed versions, for bullseye, bookworm, trixie, sid, and other branches.
For other distributions, check the official security pages or repositories for Ubuntu, Red Hat, SUSE, Arch, Alpine, and so on.

Do not judge safety only by the upstream kernel version. Distributions backport fixes, so the same upstream-looking version number may mean different patch states across distributions.

Which machines to prioritize

Prioritize remediation in this order:

Multi-user servers and shared hosts.
Bastion hosts, teaching machines, development machines, and other systems with normal shell accounts.
CI runners, build machines, and hosting platform nodes.
Container and virtualization hosts, especially where not-fully-trusted workloads coexist.
Public service machines. The vulnerability needs local access, but the risk compounds once a web bug, RCE, weak password, or similar path gives an attacker a low-privileged foothold.

Pure single-user desktop systems are lower risk, but they should still be updated. Local low-privileged code execution is common on desktops through browsers, developer tools, scripts, and third-party software.

Remediation guidance

The preferred fix is to install the fixed kernel supplied by your distribution and reboot.

Commands differ by distribution, but the principle is the same:

Refresh package metadata.
Install the kernel package containing the CVE-2026-46333 fix.
Reboot into the new kernel.
Use uname -r and the distribution security advisory to verify the running kernel is fixed.

The AlmaLinux advisory says fixed kernels are available in production repositories and users can run the usual dnf upgrade and reboot. The Debian tracker also lists fixed versions for multiple branches.

Important: if you only install a new kernel package but do not reboot, the old vulnerable kernel is still running.

Temporary mitigation: tighten ptrace_scope

If you cannot reboot immediately, tighten Yama ptrace_scope first.

Qualys confirmed in a follow-up oss-security reply that setting /proc/sys/kernel/yama/ptrace_scope to 2 (admin-only attach) or 3 (no attach) blocks the public exploitation paths they know about. They also noted that other theoretical exploitation paths may exist, so this is only a mitigation, not a fix.

Temporary setting:

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

Persistent setting:

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 disables ptrace attach and may affect debugging workflows such as gdb and strace -p. If production debugging is required, evaluate 2. Either way, schedule the kernel upgrade and reboot as soon as possible.

Should SSH host keys be rotated?

Use a conservative approach if the machine had any of the following conditions around the disclosure window:

Untrusted local users.
Shared hosting or container/CI multi-tenant environments.
Web vulnerabilities, weak passwords, supply-chain scripts, or other paths that could give an attacker a local foothold.
Suspicious local processes, unusual debugging behavior, or public PoC files in logs.
Long exposure before patching.

Conservative handling includes:

Rotate SSH host keys after patching and rebooting.
Update known-host fingerprint management systems.
Notify automation that depends on the host fingerprint.
Review SSH connection alerts so legitimate fingerprint changes are not mistaken for man-in-the-middle attacks, and real risks are not ignored.

If /etc/shadow may have leaked, also evaluate password resets, weak-password bans, and whether old hashes could be cracked offline.

What to monitor

The exploitation window is short, so traditional logs may not capture everything. Still, watch for:

Files such as ssh-keysign-pwn, chage_pwn, or similar PoC artifacts in normal user directories.
Suspicious compilation activity, such as unfamiliar C programs compiled in a short window.
Signs of abnormal access to /etc/ssh/ssh_host_*_key or /etc/shadow.
Unusual pidfd_getfd, ptrace, or debugger-related activity.
External reports of unexpected SSH host fingerprint changes.

These signals cannot prove exploitation occurred, and their absence cannot prove it did not. The real priorities remain patching, rebooting, credential rotation, and risk isolation.

Common misconceptions

First: this is not an OpenSSH remote vulnerability. The name includes ssh-keysign, but the root cause is Linux kernel ptrace access-check logic, not the remote authentication path in sshd.

Second: no local users does not mean no risk. The bug does require local execution, but real attack chains often obtain a low-privileged local foothold first through web services, CI, scripts, weak passwords, or container escape paths.

Third: setting ptrace_scope is not enough. It is a temporary mitigation, not the root fix. Kernel update and reboot are still required.

Fourth: “no root shell” does not mean “no incident.” Exposure of SSH host private keys or /etc/shadow can be enough to enable lateral movement, host impersonation, and offline password cracking.

Response checklist

Suggested order:

Inventory affected Linux hosts, especially multi-user and shared environments.
Check distribution security advisories and identify the fixed kernel version.
Install the fixed kernel and reboot.
For machines that cannot reboot immediately, set kernel.yama.ptrace_scope=2 or 3.
After remediation, verify the running kernel version.
Rotate SSH host keys on high-risk machines.
If /etc/shadow exposure is suspected, evaluate password resets and account audits.
Check for public PoCs, unusual compilation, and suspicious local debugging behavior.

Summary

ssh-keysign-pwn (CVE-2026-46333) is a local information disclosure vulnerability rooted in Linux kernel __ptrace_may_access() logic. It does not allow a remote attacker to break in directly and it does not directly grant a root shell, but it may let a low-privileged local user read high-value sensitive files, making it especially important in multi-user, shared hosting, CI, and container-host environments.

The reliable fix is to upgrade to a distribution-provided fixed kernel and reboot. ptrace_scope=2/3 can be used as a temporary mitigation, but it does not replace patching. Critical hosts exposed during the risk window should also be evaluated for SSH host key rotation and password risk.

References:

How to Check CVE-2026-42945: Nginx Rift Trigger Conditions, Version Checks, and Upgrade Advice

Fri, 15 May 2026 17:55:42 +0800

CVE-2026-42945 is a security vulnerability in NGINX Open Source and NGINX Plus. It is also being referred to as Nginx Rift. The issue is in ngx_http_rewrite_module, and the vulnerability type is heap-based buffer overflow.

News like this is easy to turn into headlines such as “hidden for 18 years”, “remote control without a password”, or “30% of servers affected”. Those claims travel well, but when reading the patch notes and NVD description, it is better to separate the risk into concrete pieces: the issue is serious, and it does not require a logged-in account; but not every Nginx instance is automatically compromised. Triggering it requires specific rewrite configuration and request conditions.

Start with the official description

The NVD description of CVE-2026-42945 can be summarized as follows:

It affects NGINX Plus and NGINX Open Source.
The vulnerability is in ngx_http_rewrite_module.
The issue may be triggered when a rewrite directive is followed by a rewrite, if, or set directive, unnamed PCRE capture groups such as $1 and $2 are used, and the replacement string contains a question mark ?.
An unauthenticated attacker can send a crafted request to trigger the vulnerability.
The result may be a heap buffer overflow and restart of an NGINX worker process.
If ASLR is disabled on the system, code execution is possible.

F5, as the CNA, gives the following scores:

CVSS v4.0: 9.2, Critical.
CVSS v3.1: 8.1, High.
CWE: CWE-122 Heap-based Buffer Overflow.

So this is not a routine “bad config causes a 404” issue. It is a memory safety vulnerability covered by an official Nginx security fix.

Which claims need context

First, “no password required” is best understood as unauthenticated attack. In other words, the attacker does not need to log in to an Nginx admin panel, obtain SSH access, or hold an application account. But that does not mean every public-facing Nginx instance can be casually taken over.

Second, “direct remote control” depends on conditions. The more careful official framing is that the vulnerability can cause worker process restarts; on systems where ASLR is disabled, code execution is a possible outcome. On environments with ASLR enabled, proper distribution hardening, and restricted runtime privileges, the exploitation path becomes more complex.

Third, “30% of servers affected” should not be treated as “all Nginx market share equals exposed attack surface”. Real exposure depends on the version, whether the affected module is present, whether the specific rewrite configuration exists, whether the distribution has already backported the patch, and how hardened the Nginx runtime environment is.

The more accurate approach is simple: if you run Nginx in production, check it quickly; but do not decide whether you are affected based only on a headline percentage.

How to determine the affected scope

According to nginx.org release information, the nginx-1.30.1 stable release and nginx-1.31.0 mainline release published on May 13, 2026 include multiple security fixes, including the ngx_http_rewrite_module buffer overflow tracked as CVE-2026-42945.

If you use official Nginx source builds or official packages, focus on:

NGINX Open Source stable: upgrade to 1.30.1 or later.
NGINX Open Source mainline: upgrade to 1.31.0 or later.
NGINX Plus: check the fixed version for your F5-supported branch.

If you use Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Alpine, container images, Plesk, control panels, Ingress Controller, or cloud-provider managed components, do not rely only on the upstream version shown by nginx -v. Many distributions backport security fixes into older package versions. The version string may look old while the patch is already included.

One-minute urgency check

Use these questions for a quick risk tiering:

Is this Nginx instance directly exposed to the internet, or is it part of an API Gateway, reverse proxy, load balancer, or Ingress entry layer?
Are you using official Nginx packages, source builds, third-party control panels, or container images without having confirmed the CVE-2026-42945 fix status?
Does the configuration contain complex rewrite rules, especially consecutive rewrite, if, or set directives and unnamed captures such as $1 and $2?
Does any rewrite target include request paths, query parameters, or other user-controlled input?
Is the system weakly hardened, for example with ASLR disabled, overly privileged workers, or overly broad container permissions?

If the first two items apply and rewrite configuration has not yet been reviewed, treat it as high priority. Public entry points, shared environments, Kubernetes Ingress, edge proxies, and Nginx instances carrying login or API traffic should be upgraded or replaced with a confirmed fixed package first.

How to confirm fixes on Debian / Ubuntu / RHEL / Alpine

Distribution users should not look only at nginx -v. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, and Alpine often backport security patches into stable branches, so the visible version may still be lower than nginx.org’s 1.30.1 or 1.31.0.

On Debian / Ubuntu, check security advisories, package changelog, and upgrade candidates:

nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

On RHEL / AlmaLinux / Rocky Linux, check security updates and package changelog:

1
2

yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

On Alpine, check the installed package version and security branch updates:

1
2

apk info -v nginx
apk version -v nginx

If the package manager, distribution security advisory, or vendor advisory explicitly says CVE-2026-42945 is fixed, you can treat it as backported even if the upstream version number looks old. Conversely, if the version looks new but the source is unclear, still confirm the build date and patch source.

How to check container images and Ingress Controller

In container environments, check the Nginx inside the image, not only the host. First confirm the actual embedded version:

1
2

docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

Also check whether the base image has been updated. If the image is built on Debian, Ubuntu, Alpine, or distribution packages, apply the same advisory and changelog checks for that distribution. Restarting an old image is not useful; the image itself needs to be rebuilt or replaced.

For Kubernetes Ingress, confirm three things:

Whether the Ingress Controller project has published an advisory or fixed release for CVE-2026-42945.
Whether the running controller image digest has actually changed, rather than only the tag.
Whether the controller’s embedded Nginx version, build flags, and template configuration still contain high-risk rewrite rules.

Start by checking the running image:

1
2

kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

If you use a cloud-provider managed Ingress or gateway, check the corresponding cloud service advisory. Managed components usually cannot be fixed by running apt upgrade yourself; you need the provider’s fix or a switch to a fixed version.

Which rewrite patterns deserve attention

This vulnerability is related to rewrite configuration. Start by searching Nginx configuration:

1
2

grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

Pay attention to patterns like:

`1`	`rewrite ^/old/(.*)$ /new/$1? permanent;`

The unnamed captures such as $1 and $2, plus the ? in the replacement target, are among the key conditions described by the official sources. During review, pay special attention to:

A rewrite followed by another rewrite, if, or set.
Broad captures such as (.*) and (.+) that are reused as $1 or $2.
Rewrite targets containing ? to append or discard query parameters.
Rewrite input coming from public paths, Host, URI, parameters, or upstream-controlled values.
Rewrite rules generated by panels, gateways, Ingress annotations, or templates.

If you cannot upgrade immediately, use temporary mitigations:

Reduce complex rewrite rules.
Replace unnamed captures with clearer named captures.
Avoid unnecessary ? concatenation in replacement strings.
Add WAF or reverse-proxy rules for high-risk entry points.
Confirm that ASLR is enabled.
Reduce Nginx worker privileges and verify systemd sandboxing, SELinux/AppArmor, and related hardening.

These measures are mitigations, not replacements for patching.

Remediation priority

Prioritize by exposure:

Public-facing Nginx entry points.
Reverse proxies, API Gateway, and edge gateways.
Nginx in multi-tenant environments.
Kubernetes Ingress Controller.
Plesk, control panels, marketplace images, and other components that bundle Nginx.
Internal Nginx instances that carry critical business traffic.

How to verify after upgrading: nginx -t, reload, and worker state

After updating, do not stop at “the package manager succeeded”. Confirm the configuration, process state, and actual binary have all switched over. First validate the configuration:

`1`	`nginx -t`

If there are no errors, reload smoothly:

`1`	`systemctl reload nginx`

If the package upgrade replaced the binary, confirm old workers have exited:

`1`	`ps aux \| grep nginx`

You can also inspect the master process start time and binary path to ensure the running service is not an old process still resident in memory. If needed, schedule a maintenance window and restart the service so old workers or old containers do not continue handling requests.

For containers and Ingress, also confirm the new image rollout has actually completed:

1
2

kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

The key verification question is not “did the command run”, but “is live traffic now handled by Nginx processes that include the fix”.

Do not ignore the same Nginx security batch

The 1.30.1 and 1.31.0 releases published by nginx.org on the same day fixed more than CVE-2026-42945. The release information also mentions HTTP/2 request injection, SCGI/uWSGI buffer overread, charset module buffer overread, HTTP/3 address spoofing, OCSP resolver use-after-free, and other issues.

That means production environments should not only add a temporary rule for a single CVE. Treat this Nginx security release as an overall upgrade.

Summary

The key point of CVE-2026-42945 is not “all Nginx instances can be instantly taken over”. It is a long-standing memory safety vulnerability in the rewrite module that can be triggered by unauthenticated requests under specific configurations. The most direct result is worker crash and restart; on weaker environments such as systems with ASLR disabled, code execution risk is higher.

For operations teams, the handling order is straightforward:

Confirm the Nginx source and version.
Check distribution, F5, nginx.org, or cloud-provider advisories.
Upgrade to a fixed version or distribution security package as soon as possible.
Review complex rewrite configuration, especially combinations of $1, $2, and ?.
Confirm ASLR, privilege isolation, and service reload state.

The headline can be scary. The fix should be calm: confirm exposure, upgrade, then clean up high-risk rewrite rules.

References

Dirty Frag, Copy Fail, and Fragnesia: Comparing Three Recent Linux Local Privilege Escalation Flaws

Fri, 15 May 2026 13:24:04 +0800

Several high-profile Linux kernel local privilege escalation vulnerabilities have appeared recently: Dirty Frag, Copy Fail, and Fragnesia. They look like a single family of events because the end result is similar: a low-privilege local user may be able to become root.

But from an operations perspective, they should not be treated as one vulnerability. Their entry modules, trigger paths, mitigation options, and patch timelines differ. A better way to understand them is this: they expose a shared risk around the complex boundary between the Linux page cache, splice, socket buffers, and crypto paths.

This post only covers risk and response analysis. It does not include reproducible exploitation steps.

What the Three Flaws Are

Dirty Frag: CVE-2026-43284

Dirty Frag mainly points to a page-cache write issue in the Linux kernel networking path. Public write-ups usually discuss it together with two issues: the xfrm-ESP side, CVE-2026-43284, and the rxrpc side, CVE-2026-43500.

CVE-2026-43284 is related to in-place decryption when ESP handles shared skb fragments. The key point is not that an attacker directly modifies a disk file, but that the kernel can write to shared pages it should not modify, affecting file contents in the page cache.

Operationally, remember that Dirty Frag reaches esp4, esp6, and rxrpc, a set of kernel modules and networking subsystem paths. It is tied to IPsec, ESP, and RxRPC, so temporary mitigation also focuses on those modules.

Copy Fail: CVE-2026-31431

Copy Fail is a Linux kernel local privilege escalation vulnerability disclosed by Theori / Xint Code. Its entry point is not the IPsec networking path, but the kernel userspace crypto API around algif_aead / AF_ALG.

Public explanations describe it as originating from an in-place optimization introduced in 2017. In some cases, the kernel failed to copy data as expected and instead placed page-cache pages into a writable destination path. An attacker can combine AF_ALG with splice() to perform a small controlled write to page-cache-backed pages.

Its risk comes from strong exploitability and broad impact across mainstream distributions. Unlike Dirty Frag, Copy Fail’s temporary mitigation focuses on restricting or disabling algif_aead, and on limiting AF_ALG socket creation in container and CI environments.

Fragnesia: CVE-2026-46300

Fragnesia is another Linux kernel local privilege escalation vulnerability disclosed by V12 Security, and it belongs to a similar attack surface as Dirty Frag. It is not the same bug as Dirty Frag, but it still revolves around IPsec ESP / rxrpc related modules and page-cache write effects.

AlmaLinux describes it as the third local-root issue in the same broad code area. The key problem is that skb_try_coalesce() did not preserve the shared-fragment marker when coalescing socket buffer fragments, which could later let the XFRM ESP-in-TCP receive path decrypt in place over external page-cache pages.

In short, Fragnesia is closer to Dirty Frag. Both revolve around esp4, esp6, rxrpc, skb fragments, and ESP decryption paths. Their temporary mitigations also overlap heavily.

Similarities: Why They Are Dangerous

The common thread is not that the exact code locations are identical, but that the attack outcome and risk model are very similar.

First, all three are local privilege escalation issues. Attackers usually need ordinary local code execution first, then they can attempt to become root. For a single-user desktop this is not remote one-click compromise; for multi-user servers, CI runners, container hosts, shared development machines, and VPS instances with exposed SSH, low-privilege entry points are not rare.

Second, all three involve page-cache writes. Attackers may not permanently modify the file on disk; instead, they affect the in-memory page-cache copy. This makes traditional integrity checks less reliable: the disk hash can remain normal while the execution path reads polluted page-cache content.

Third, they are closer to deterministic logic bugs than timing-sensitive race conditions. Public material repeatedly notes that these issues do not require winning a race condition. Defenders should not underestimate exploit reliability based on older assumptions.

Fourth, they amplify the risk of container and automation environments. Low-privilege code inside containers, CI jobs, build scripts, or third-party plugins can turn a “local issue” into a platform-level issue if it can reach the relevant host kernel interfaces.

Differences: One Mitigation Does Not Cover All

The biggest difference is the entry module.

Copy Fail’s critical entry point is algif_aead / AF_ALG, part of the kernel userspace crypto API. Its temporary defense focuses on disabling or restricting algif_aead, and using seccomp to block containers from creating AF_ALG sockets.

Dirty Frag’s critical entry point is xfrm-ESP and rxrpc. It is closer to protocol and socket buffer handling paths. Temporary defense typically considers disabling esp4, esp6, and rxrpc, but that can affect IPsec, VPNs, tunnels, or related networking capabilities.

Fragnesia sits in a similar region to Dirty Frag, but the concrete issue is that skb_try_coalesce() did not preserve the shared-fragment marker. It is more like another branch of the Dirty Frag risk surface than a Copy Fail crypto API issue.

So, fixing Copy Fail does not mean Dirty Frag and Fragnesia are covered. Likewise, disabling esp4 / esp6 does not automatically remove Copy Fail. Their patch state and mitigation strategy must be checked separately.

How to Judge Exposure

For these vulnerabilities, do not judge only by distribution name or kernel major version. Distributions backport fixes, cloud vendors maintain their own kernel branches, and enterprise distributions may carry additional patches.

A safer sequence is:

Check the distribution security advisory and kernel package changelog.
Verify whether the current kernel package fixes the relevant CVE.
For cloud servers, container hosts, and CI nodes, also check cloud or platform advisories.
For temporary mitigations, confirm whether the business depends on the affected module.
After a kernel update, schedule a reboot and confirm the running kernel has changed.

The most common trap is “the package is updated, but the machine has not rebooted.” Kernel vulnerabilities are not like ordinary userspace service updates. Until the system boots into the new kernel, the old kernel may still be running.

Operational Priority

The systems that deserve the highest priority are not all Linux machines equally. Start where low-privilege code execution is most likely.

Highest-priority environments include:

Multi-user login servers
CI / CD runners
Build and artifact packaging machines
Container hosts and Kubernetes nodes
Shared development machines
Cloud servers and VPS instances exposing SSH
Platforms running third-party scripts, plugins, or job queues
Machines with web vulnerabilities, weak passwords, or historical compromise signals

Closed, single-user machines with no external code execution entry point are still at risk if vulnerable, but they can usually be handled later.

How to Treat Temporary Mitigation

Temporary mitigation is not a replacement for a patch. Its value is reducing exposure when you cannot immediately reboot or are waiting for distribution packages.

For Copy Fail, focus on algif_aead and AF_ALG. If the business does not use the kernel AF_ALG crypto interface, evaluate disabling the related module. In container environments, check seccomp policies first so untrusted workloads cannot freely create the relevant socket.

For Dirty Frag and Fragnesia, focus on esp4, esp6, and rxrpc. If the system does not depend on IPsec ESP, related VPNs, tunnels, or RxRPC, consider temporary disabling. Do not do this blindly in production because these modules may support real networking workloads.

The final path is still a kernel update. Temporary mitigation can reduce attack surface, but it cannot prove the system is fully safe.

What These Three Flaws Tell Us

The important warning is not just the number of CVEs. These flaws all cluster around high-complexity kernel paths: zero-copy, splice, socket buffers, the page cache, crypto interfaces, and protocol-stack optimizations.

These paths deliver performance, but their ownership boundaries are hard to maintain. Whether a fragment is shared, whether a page may be written in place, and whether an optimization truly only reduces copying all become security boundaries.

For security and operations teams, the takeaways are practical:

Treat local privilege escalation as an amplifier for existing low-privilege entry points.
Containers are not a natural isolation boundary for kernel vulnerabilities.
File integrity checks cannot look only at disk contents.
CI, build machines, and plugin platforms are high-priority assets.
Kernel patching requires verifying both “installed” and “running” states.

Summary

Dirty Frag, Copy Fail, and Fragnesia are all high-priority recent Linux local privilege escalation events, but they are not three names for one vulnerability.

Copy Fail goes through the algif_aead / AF_ALG crypto API path. Dirty Frag goes through xfrm-ESP and rxrpc. Fragnesia, in a nearby Dirty Frag attack surface, again triggers page-cache write risk through skb fragment marker handling.

Operationally, the safest response is to update the kernel according to distribution advisories and reboot. For systems that cannot be updated immediately, evaluate temporary module disabling or tighter seccomp rules based on the actual vulnerability entry point. Prioritize multi-tenant systems, CI, container hosts, and shared development environments.

References:

Theori Copy Fail notes: https://github.com/theori-io/copy-fail-CVE-2026-31431
CERT-EU Copy Fail advisory: https://cert.europa.eu/publications/security-advisories/2026-005/
AlmaLinux Dirty Frag notes: https://almalinux.org/blog/2026-05-07-dirty-frag/
AlmaLinux Fragnesia notes: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
V12 Security Fragnesia PoC notes: https://github.com/v12-security/pocs/tree/main/fragnesia

Fragnesia (CVE-2026-46300): Impact and Mitigation for a Linux Kernel Local Privilege Escalation Flaw

Fri, 15 May 2026 13:18:01 +0800

The Linux kernel has another local privilege escalation issue in the same broad attack surface as Dirty Frag: Fragnesia (CVE-2026-46300).

According to V12 Security, Fragnesia is a Linux local privilege escalation vulnerability. An attacker does not need existing high privileges on the host. If they can execute local code, they may be able to abuse a logic flaw in the kernel’s XFRM ESP-in-TCP subsystem to modify read-only file contents through the page cache and eventually trigger a root shell.

Source:

V12 Security PoC notes: https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

This post does not cover reproducible exploitation steps. It focuses on the operational risk and response path.

How It Relates to Dirty Frag

V12 Security classifies Fragnesia as part of the Dirty Frag vulnerability class. It is not the same bug as Dirty Frag, but it lives in a related attack surface: Linux kernel XFRM ESP-in-TCP.

XFRM is the Linux kernel framework for IPsec processing. ESP-in-TCP is related to carrying ESP encrypted traffic over TCP. Fragnesia comes from logic around shared page fragments and socket buffer coalescing: in some cases, the kernel can lose track of the fact that a fragment is still shared, leaving room for controlled writes.

This resembles the broader Dirty Pipe / Dirty Frag family of page-cache write issues. The concrete code paths differ, but the effect again lands on the page-cache copy of a read-only file.

Why the Risk Is High

Fragnesia is dangerous for three reasons.

First, it is a local privilege escalation. Once an attacker can run ordinary user-level code on a system, they may be able to become root. That matters especially on multi-user servers, container hosts, CI runners, shared development machines, VPS instances, and systems exposing shell access.

Second, it does not rely on a traditional race condition. V12’s notes describe a path that drives ESP-in-TCP processing over file-backed pages already spliced into a socket buffer, allowing byte-level influence over page-cache contents. That makes the issue more practical than a purely theoretical bug.

Third, it changes the page cache, not the on-disk file. The public notes use /usr/bin/su as an example target. After successful exploitation, the file on disk is not permanently modified; the modified copy lives in memory. Integrity checks that only compare disk hashes may miss this.

That is the awkward part for administrators: the file can look unchanged, but executing the polluted page-cache copy of a target binary may still trigger privilege escalation.

Known Affected Scope

V12 Security states that kernels affected by Dirty Frag and missing the relevant May 13, 2026 patches are also affected by Fragnesia. Publicly tested environments include Ubuntu 22.04, Ubuntu 24.04, and kernels such as 6.8.0-111-generic.

There are two important caveats.

First, do not judge only by the distribution major version. Whether Ubuntu 22.04 or 24.04 is affected depends on the actual kernel patch state, not just the distribution name.

Second, do not rely only on default AppArmor restrictions for unprivileged user namespaces. Ubuntu’s AppArmor restrictions can raise the bar, but the disclosure treats that as an additional bypass problem, not as a fix for the vulnerability itself.

The reliable path is still to check distribution security advisories and kernel package updates.

Temporary Mitigation

If a system cannot be upgraded immediately, first check whether it depends on the relevant protocol modules.

V12 gives the same mitigation direction as Dirty Frag: if the system does not depend on IPsec ESP or RxRPC, administrators can consider disabling modules such as esp4, esp6, and rxrpc. This can affect networking features, so production systems should not do it blindly. Confirm whether the environment uses IPsec, VPNs, tunnels, or related kernel functionality.

A safer response order is:

Check whether the distribution has published a kernel security update.
Install the kernel patch and schedule a reboot first.
If immediate upgrade is impossible, evaluate temporary module disabling.
Prioritize multi-user systems and CI / build environments.
Review unnecessary local accounts, shell access, container escape surface, and low-privilege execution entry points.

Disabling modules should not be treated as the final fix. It is only a way to reduce exposure while moving toward a patched kernel.

If Exploitation Is Suspected

One key feature of Fragnesia is page-cache pollution. V12 notes that after exploitation, the target file’s page-cache copy may contain injected content, and later execution can still behave abnormally until the page is evicted or the system is rebooted.

If exploitation is suspected, do at least the following:

Preserve logs and audit records as soon as possible.
Check recent abnormal local logins, low-privilege user activity, suspicious processes, and root shell traces.
Clear the relevant page cache or reboot directly.
Upgrade to a fixed kernel.
Verify key binaries, but do not rely only on disk hashes.
Rotate potentially exposed credentials and keys.

For production servers, it is better to treat this as a potential local privilege escalation incident, not merely as a routine patch event.

Which Machines Should Come First

The highest priority is not every Linux machine equally. Start with systems where attackers are most likely to obtain low-privilege code execution.

High-priority environments include:

Multi-user login servers
CI / CD runners
Build machines
Shared development machines
Container hosts
VPS and cloud servers
Edge nodes exposing SSH
Platforms running third-party scripts or plugins

Closed, single-user machines with no external code execution entry point are still affected if vulnerable, but their urgency is lower.

Summary

Fragnesia matters not because it has a new name, but because it again pulls Linux local privilege escalation back into the difficult boundary between the page cache and kernel networking subsystems.

For administrators, the important work is to confirm kernel patch status, understand whether ESP / RxRPC is in use, prioritize highly exposed machines, and remember that “the disk file is unchanged” does not mean “the system was unaffected.”

If a system is affected, the final answer is still to install the distribution’s kernel update as soon as possible. Temporary module disabling is only a bridge, not a replacement for the patch.