Security Updates on KnightLi Blog

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.