GRSecurity has identified an obfuscated fix for local privilege escalation committed to the Linux kernel. A PoC exploit exists that targets /etc/shadow
Multiple suid binary targets, please do not rely on individual ones you see posted as effective mitigations. Current exploits are only gaining read access to [/]etc[/]shadow, but can’t guarantee read/write to something useful isn’t possible.
Exploit:
What is the source of that quote? I don’t see it in either link.
Sorry 'bout that.
I feel like there’s a missing PoC here. I’m not comfortable with the claim that this is “being exploited.” Needs more reporting.
Fair enough. Hrbrmstr did post a link to what may be an exploit.
I have not tested it.
Direct link:
This vulnerability now has an assigned CVE: CVE-2026-46333
Can we update the thread title to make it easier to locate? The friendly name appears to be “ssh-keysign-pwn”.
Mitigation (ptrace)
These are the mitigations that I’ve applied on Ubuntu systems in my environment. They should block exploitation paths that use ptrace. If you set ptrace_scope to “3” and change your mind, you will have to reboot to change it to a different value. So, you may want to start with “2” if you have a critical system that cannot or should not be rebooted.
To check the value before/after: sudo /usr/sbin/sysctl kernel.yama.ptrace_scope
I opted to go this route for the moment and not test removing SUID permissions on binaries.
You can use the following to steps to configure a persistent block on ptrace exploits without system reboot:
/etc/sysctl.d/98-security-hotfixes.conf with:# CVE-2026-46333 - ssh-keysign-pwn
# Partial mitigation that addresses ptrace exploit paths
# 3 - fully block attach (no attach)
# 2 - admin-only attach
# References:
# - https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn
# - https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html
kernel.yama.ptrace_scope = 3
sudo /usr/sbin/sysctl -p /etc/sysctl.d/98-security-hotfixes.confSome Distro Security Pages:
Note: status of distro vulnerability as of posting, 2026-05-19.
Done
Done! What impacts might your mitigation have beyond preventing exploitation?
The mitigations are mostly based on others’ recommendations. I would not consider myself knowledgeable of kernel internals. That is also part of why this route was chosen over troubleshooting SUID on binaries.
Per the Kernal Yama (ptrace_scope) documentation, this functionality is used heavily in debugging (e.g., gdb). I can also see this impacting EDRs or other services that want/need to monitor other processes. With this in mind, the shared servers that I applied this to do not have the need for debugging or any EDR that needs to attach/monitor processes, so it was decided on the fullest protection setting of “3”. In the case of needing to allow for EDR or admins to attach to processes, it looks like “2” would be a better approach. On single-user systems, this mitigation likely has minimal effect as that user likely already has sudo or admin privileges.
>Since ptrace is not commonly used by non-developers and non-admins, system builders should be allowed the option to disable this debugging system.
This will likely impact crash handlers, too:
>For example, this is used by KDE, Chromium, and Firefox’s crash handlers, and by Wine for allowing only Wine processes to ptrace each other.