Vulnerability Fix 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:

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

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag is a set of Linux kernel local privilege escalation vulnerabilities disclosed in May 2026 with signs of active exploitation. Microsoft describes it as a post-compromise risk: after an attacker gains low-privileged code execution, the bug may be used to escalate to root. Ubuntu has also marked CVE-2026-43284 as High.

The danger is not “remote one-click compromise”. The danger is that once an attacker gets in, they can expand control quickly. If they gain local execution through weak SSH credentials, a web shell, container escape, a low-privileged service account, or phishing-enabled remote access, Dirty Frag may let them obtain root and then disable security tools, read credentials, tamper with logs, move laterally, or persist.

Which CVEs are involved

Public information currently associates Dirty Frag mainly with two IDs:

CVE-2026-43284: related to the Linux kernel xfrm/ESP path. Microsoft’s esp4 and esp6 references belong to this risk area.
CVE-2026-43500: Microsoft says this is related to rxrpc, but as of May 8, 2026, the CVE had not yet been published in NVD and patch status was still evolving.

So do not check only one CVE. A safer approach is to review whether esp4, esp6, rxrpc, and related xfrm/IPsec functions are enabled, needed, and patched by your distribution.

Technical overview

According to Microsoft and Ubuntu, CVE-2026-43284 involves Linux kernel networking and memory-fragment handling, especially how shared page fragments are handled in the ESP/IPsec path.

In simplified terms, data pages can be attached to network buffers through mechanisms such as splice. If later kernel paths treat those fragments as privately owned and safe to modify in place, in-place decryption or modification can happen where it should not. An attacker may manipulate page cache behavior and eventually achieve local privilege escalation.

This has similarities to CopyFail (CVE-2026-31431): both involve Linux page cache behavior, kernel data paths, and local privilege escalation. Dirty Frag is dangerous because it adds more attack paths and may be more reliable than traditional LPE exploits that depend on tight race windows.

Environments to prioritize

Dirty Frag is a local privilege escalation vulnerability, so the attacker must already be able to execute code locally. Prioritize:

Linux servers with exposed SSH.
Web servers where a web shell could be written.
Multi-user login hosts, bastions, developer machines, and CI/CD runners.
Container hosts, Kubernetes nodes, and OpenShift nodes.
Systems using IPsec, VPN, xfrm, or RxRPC-related functionality.
Servers running Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and other mainstream distributions.

If a server has no local multi-user access, no containers, and no exposed application path, risk is lower. But any system where an attacker might obtain a low-privileged shell should treat this as a high-priority kernel issue.

Patch first

The safest fix is to install the kernel security update from your distribution and reboot into the new kernel.

Ubuntu’s CVE page shows CVE-2026-43284 was published on May 8, 2026 and is rated High. Microsoft also says the Linux Kernel Organization has released fixes for CVE-2026-43284 and urges customers to apply patches promptly.

Start by checking the system:

1
2

uname -a
cat /etc/os-release

Then update the kernel using your distribution’s package manager:

`1`	`sudo apt update && sudo apt full-upgrade`

Or:

`1`	`sudo dnf update`

After updating, confirm that the system has rebooted into the new kernel:

`1`	`uname -r`

Installing kernel packages without rebooting leaves the old kernel running, so the vulnerability may still be present.

If patches are not yet available, or production cannot reboot immediately, evaluate whether you can temporarily disable the related modules. Ubuntu’s mitigation blocks esp4, esp6, and rxrpc from loading and unloads them if already loaded.

Create modprobe blocking rules:

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

Update initramfs so the modules are not loaded during early boot:

`1`	`sudo update-initramfs -u -k all`

Unload currently loaded modules:

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

Check whether the modules are still loaded:

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

If a module is in use, unloading may fail. In that case, the block rule may only take effect after reboot.

Evaluate business impact before disabling

Do not paste the mitigation blindly. esp4, esp6, and xfrm/IPsec functionality may be used by VPNs, tunnels, encrypted networking, Kubernetes/container networking, or enterprise network configurations. rxrpc may also affect workloads that depend on that protocol.

Before using the mitigation in production, check at least:

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

If you depend on IPsec VPN or related kernel networking, disabling modules may break connectivity. In that case, schedule kernel patching and a maintenance reboot rather than relying on module blocking for long.

Do not skip post-compromise checks

Microsoft specifically notes that mitigation does not necessarily undo changes already made by successful exploitation. If an attacker already gained root, they may have left persistence, modified files, altered logs, or accessed session data.

At minimum, check:

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

Also review:

Abnormal su, sudo, or SUID/SGID process launches.
Newly created ELF executables.
Suspicious PHP, JSP, or ASP files in web directories.
Changes to SSH authorized_keys.
New persistence in systemd services, cron, or rc.local.
Suspicious privileged containers or host mounts.

If exploitation is suspected, isolate the host, preserve evidence, rotate credentials, and then clean up. Do not assume that unloading modules or clearing caches makes the system safe.

About drop_caches

Microsoft mentions that in some post-exploitation integrity verification scenarios, cache clearing may be evaluated:

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

This is not a vulnerability fix and not an incident cleanup command. Dropping caches can increase disk I/O and affect production performance. Use it only as an auxiliary step after understanding the impact. The real fix remains patching, rebooting, verifying integrity, and checking persistence.

Recommended response order

For production environments, a reasonable response sequence is:

Inventory Linux assets and kernel versions.
Prioritize systems with exposed SSH, web workloads, container hosts, and multi-user access.
Patch and reboot systems that can be restarted quickly.
For systems that cannot yet patch or reboot, evaluate disabling esp4, esp6, and rxrpc.
Increase monitoring for su, SUID/SGID activity, suspicious ELF files, web shells, and container escape indicators.
Run post-compromise checks and rotate credentials on hosts that may already have been exploited.

Summary

Dirty Frag is not a “remote one-click” vulnerability, but it significantly increases post-compromise risk. If an attacker can run code locally with low privileges, CVE-2026-43284 and the related rxrpc attack surface may allow escalation to root.

For administrators, the priority is not studying PoCs. The priority is to confirm kernel exposure, install distribution security updates and reboot, evaluate module-blocking mitigations before the patch window, and inspect exposed or suspicious systems for integrity and persistence issues.

References:

Vulnerability Fix on KnightLi Blog

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

Bottom line

What the vulnerability is

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

How to assess exposure

Which machines to prioritize

Remediation guidance

Temporary mitigation: tighten ptrace_scope

Should SSH host keys be rotated?

What to monitor

Common misconceptions

Response checklist

Summary

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

Which CVEs are involved

Technical overview

Environments to prioritize

Patch first

Interim mitigation: disable related modules

Evaluate business impact before disabling

Do not skip post-compromise checks

About drop_caches

Recommended response order

Summary