A newly disclosed Linux kernel vulnerability <\/a>is raising serious concerns across the security community, as it allows attackers to access highly sensitive data, including SSH private keys and password hashes, on affected systems. <\/p>\n Tracked as\u00a0CVE-2026-46333<\/a>, the flaw has been nicknamed\u00a0\u201cssh-keysign-pwn\u201d\u00a0and impacts a wide range of Linux distributions.<\/p>\n Linux system hit with multiple vulnerabilities in 2026, including\u00a0Dirty Pipe<\/a>, io_uring UAF<\/a>, Copy Fail<\/a>, io_uring ZCRX Freelist<\/a>, Dirty Frag<\/a>, and Fragnesia<\/a><\/span>.<\/p>\n The issue originates in the Linux kernel\u2019s\u00a0ptrace access control logic, specifically within the\u00a0__ptrace_may_access()\u00a0function. <\/p>\n This mechanism is supposed to restrict how processes can inspect or interact with other processes. However, a logic flaw tied to the kernel\u2019s \u201cdumpability\u201d checks creates a dangerous race condition.<\/p>\n In simple terms, when a privileged process (such as\u00a0ssh-keysign\u00a0or\u00a0chage) is shutting down, there is a short window where its memory context is cleared (mm = NULL) but its open file descriptors still exist. During this gap, an unprivileged local attacker can exploit the flaw using\u00a0pidfd_getfd()\u00a0to steal those file descriptors.<\/p>\n This effectively bypasses intended permission checks, allowing unauthorized access to sensitive files.<\/p>\n Security researchers, including Qualys, warn that this vulnerability can lead to severe consequences:<\/p>\n Because SSH keys are often reused across environments, a single compromised system can cascade into broader network access.<\/p>\n The vulnerability affects\u00a0most Linux distributions\u00a0running kernels before the patch released on\u00a0May 14, 2026. This includes:<\/p>\n Given that the flaw has reportedly existed for\u00a0over six years, many long-term deployments may be exposed.<\/p>\n The core issue lies in how the kernel handles processes without a memory context. The \u201cdumpability\u201d flag, originally designed to control core dumps, is reused in ptrace checks, even when it no longer makes logical sense.<\/p>\n When a process exits, its memory is released before its file descriptors are cleaned up. The kernel fails to properly enforce access restrictions<\/a> during this transitional state, allowing attackers to bypass security boundaries.<\/p>\n The GitHub PoC\u00a0 The PoC repeatedly spawns attack processes that race against a privileged helper\u2019s exit path, using\u00a0 According to public analysis, the exploit typically succeeds within 100\u20132000 attempts, making it practical on real systems.<\/p>\n Two core exploitation paths are highlighted:<\/p>\n Organizations should act immediately to reduce risk:<\/p>\n As a public proof-of-concept (PoC) exploit has already been released on GitHub, it increases the likelihood of active exploitation in the wild. This significantly raises the urgency for patching.<\/p>\n With SSH serving as the backbone of secure access across cloud and enterprise environments, the exposure of private keys poses a high-impact risk that cannot be ignored.<\/p>\n Follow us on\u00a0Google News<\/a>,\u00a0LinkedIn<\/a>,\u00a0and\u00a0X<\/a>\u00a0to Get More Instant Updates.<\/strong><\/p>\n The post Critical Linux Kernel Flaw \u2018ssh-keysign-pwn\u2019 Exposes SSH Keys and Shadow Passwords<\/a> appeared first on Cyber Security News<\/a>.<\/p>\n<\/div>\nLinux Kernel Vulnerability \u201cssh-keysign-pwn\u201d<\/strong><\/h2>\n
\n
Affected Systems<\/strong><\/h3>\n
\n
ssh-keysign-pwn<\/code>\u00a0demonstrates<\/a> exactly how to weaponize this race condition on pre\u201131e62c2ebbfd<\/code>\u00a0kernels.<\/p>\npidfd_getfd<\/code>\u00a0to grab file descriptors to root\u2011owned files before they are closed.<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/raw.githubusercontent.com\/0xdeadbeefnetwork\/ssh-keysign-pwn\/main\/demo.gif?ssl=1\")
<\/figure>\n\n
ssh-keysign<\/code>\u00a0to read SSH host private keys from\u00a0\/etc\/ssh\/ssh_host_{ecdsa,ed25519,rsa}_key<\/code>\n<\/li>\nchage -l <user><\/code>\u00a0to read\u00a0\/etc\/shadow<\/code>\u00a0via a similar file\u2011descriptor theft pattern<\/li>\n<\/ul>\nMitigations<\/strong><\/h2>\n
\n