Please note that disabling ptrace isn't sufficient, despite the commit message and the function involved: ptrace_may_access is called from all over the place and indeed this PoC doesn't use ptrace.
In terms of mitigations, there's not great options. AFAIK it's really down to:
remove the world executable bit on /usr/lib64/misc/ssh-keysign as a very weak mitigation for this specific PoC only (only do this if you need to go to bed right now and you can't patch your kernel or shutdown the machine) (*);
block pidfd_getfd with eBPF or the like (systemtap would be another option). Not much uses it and there's often a fallback.
I haven't reviewed the PoC, usual caveats apply w/ running random PoCs from the net.
The Qualys advisory hasn't been published yet, they recently said they'd stop doing linux-distros with heavy regret because of the Linux kernel security policy. LLMs being able to go from some fix commit that is possibly suspicious to a PoC most rapidly has made things rough. Otherwise you could get away with waiting a few days in normal times.
Qualys are real legends and it's unfortunate that they don't get a proper moment to announce this themselves now. I'm confident that when it does appear, it'll be excellent though.
(*) openssh is a convenient target for this and not to blame. There will be other (suid) binaries to pick on.
In the interest of a quick mitigation, I asked an LLM (Opus) to write a systemtap script to block pidfd_getfd. It's here, must be run as stap -g block_pidfd_getfd.stp. Review the script before you run it, as with everything from the internet.
Can the kernel please stop 0-daying itself by just publicly committing fixes to the main branch? It even says ““Reported-by: Qualys” in the commit, so it's obviously a security fix.
Ideally, send a patch to the distros' security mailing lists, tell them to have the packages ready to ship in 24h, and merging to main at the same time the distros release the patched kernels.
Security ML are not going to help, the world has changed and discovering/exploiting vulns just happens too fast. One thing worth trying out is completely automated kernel-release-to-distro-packages pipeline, users should be able to reboot into a new kernel just a few hours after an upstream release.
discovering/exploiting vulns just happens too fast
This doesn't matter in this context. Yes, vulnerabilities are being discovered at a very rapid pace, and people are also quick to turn bugfix patches into working exploits. That doesn't mean that when Qualys finds a vulnerability, everyone else will suddenly stumble upon that vulnerability.
As long as patches are withheld before public disclosure, I don't really see any major issues with this approach. A 90-day wait might be too long nowadays, though...
That sounds like a fantastic vector for supply chain attacks.
I'm only suggesting that for the kernel, not all distro packages. It has enough accidental vulns that there doesn't seem to be a need to slip in malicious ones. It is heavily-analyzed, including multiple actors looking at every commit, making an xz-style attack highly unlikely. QA by distro packagers is useful, but not against malicious code slipping into a kernel release.
Yup, I've read this article. I, however, assume Qualys is competent - so if they use LLMs in their work, and if usage of hosted models causes this sort of leakage, then I'd expect them to stick to local models.
Just because using Mythos or whatever to find vulnerabilities causes them to be leaked, doesn't mean all vulnerabilities will be magically leaked by LLMs.
There are hundreds of Linux distros out there. Many of them staffed by volunteers. Would they actually be able to do coordinated patching within 24 hours?
The alternative is doing the patching while the exploits are already in the wild, so instead of 24h you have effectively 0h. Basically what has been happening this last week.
Realistically, there will be a two tiered system. Not every distro is equally prominent, or trustworthy, nor can every distro dedicate the resources to quickly patching.
It is not an attack on volunteers to observe that you don't typically ask them for an SLA, or that professionals should often prefer to depend on non-volunteer organizations.
Context for people coming in now: we were referring to the original title, "ssh-keysign-pwn: Read root-owned files as an unprivileged user", which I based on the repository's title and description.
I ended up giving up on that and I've changed the title to the current "linux 0-day, access root-owned files as an unprivileged user", just trying to highlight the most important stuff without suggesting anything incorrect (such as this being in any way related to SSH, or being a read-only exploit - this PoC is, but it seems more serious than that). I hate editorializing titles, but it is what it is.
It seems that this lets you access file descriptors opened by setuid executables under some conditions. I... see no reason why this would be only limited to reads. Surely you can twist this into an LPE that doesn't require cracking a hash.
You can break this poc in particular with chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage (you might need to change the path to ssh-keysign. see also the manpage), but that doesn't fix the core issue, and it can probably be worked around. There are no other mitigations available that I know of.
Practically, this affects systems where the user already has an unprivileged account - so one wouldn’t be able to use this to achieve RCE on an internet-exposed box running SSH without already having a valid login, correct?
sams | 9 hours ago
Please note that disabling ptrace isn't sufficient, despite the commit message and the function involved:
ptrace_may_accessis called from all over the place and indeed this PoC doesn't use ptrace.In terms of mitigations, there's not great options. AFAIK it's really down to:
/usr/lib64/misc/ssh-keysignas a very weak mitigation for this specific PoC only (only do this if you need to go to bed right now and you can't patch your kernel or shutdown the machine) (*);pidfd_getfdwith eBPF or the like (systemtap would be another option). Not much uses it and there's often a fallback.I haven't reviewed the PoC, usual caveats apply w/ running random PoCs from the net.
The Qualys advisory hasn't been published yet, they recently said they'd stop doing linux-distros with heavy regret because of the Linux kernel security policy. LLMs being able to go from some fix commit that is possibly suspicious to a PoC most rapidly has made things rough. Otherwise you could get away with waiting a few days in normal times.
Qualys are real legends and it's unfortunate that they don't get a proper moment to announce this themselves now. I'm confident that when it does appear, it'll be excellent though.
(*) openssh is a convenient target for this and not to blame. There will be other (suid) binaries to pick on.
tomsmeding | 39 minutes ago
In the interest of a quick mitigation, I asked an LLM (Opus) to write a systemtap script to block
pidfd_getfd. It's here, must be run asstap -g block_pidfd_getfd.stp. Review the script before you run it, as with everything from the internet.strugee | 5 hours ago
Do you have a link to the linux-distros announcement? I can't find anything.
mxey | 3 hours ago
Can the kernel please stop 0-daying itself by just publicly committing fixes to the main branch? It even says ““Reported-by: Qualys” in the commit, so it's obviously a security fix.
giffengrabber | 2 hours ago
What should they do instead?
cosarara | 2 hours ago
Ideally, send a patch to the distros' security mailing lists, tell them to have the packages ready to ship in 24h, and merging to main at the same time the distros release the patched kernels.
moltonel | an hour ago
Security ML are not going to help, the world has changed and discovering/exploiting vulns just happens too fast. One thing worth trying out is completely automated kernel-release-to-distro-packages pipeline, users should be able to reboot into a new kernel just a few hours after an upstream release.
[OP] dzwdz | an hour ago
This doesn't matter in this context. Yes, vulnerabilities are being discovered at a very rapid pace, and people are also quick to turn bugfix patches into working exploits. That doesn't mean that when Qualys finds a vulnerability, everyone else will suddenly stumble upon that vulnerability.
As long as patches are withheld before public disclosure, I don't really see any major issues with this approach. A 90-day wait might be too long nowadays, though...
That sounds like a fantastic vector for supply chain attacks.
moltonel | 28 minutes ago
https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/#story-1-10-people-1-bug-6-weeks https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/#what-the-industry-needs-to-do-and-i-am-not-sugarcoating-this
I'm only suggesting that for the kernel, not all distro packages. It has enough accidental vulns that there doesn't seem to be a need to slip in malicious ones. It is heavily-analyzed, including multiple actors looking at every commit, making an xz-style attack highly unlikely. QA by distro packagers is useful, but not against malicious code slipping into a kernel release.
[OP] dzwdz | 3 minutes ago
Yup, I've read this article. I, however, assume Qualys is competent - so if they use LLMs in their work, and if usage of hosted models causes this sort of leakage, then I'd expect them to stick to local models.
Just because using Mythos or whatever to find vulnerabilities causes them to be leaked, doesn't mean all vulnerabilities will be magically leaked by LLMs.
giffengrabber | 49 minutes ago
Would that really work?
There are hundreds of Linux distros out there. Many of them staffed by volunteers. Would they actually be able to do coordinated patching within 24 hours?
cosarara | 25 minutes ago
The alternative is doing the patching while the exploits are already in the wild, so instead of 24h you have effectively 0h. Basically what has been happening this last week.
hyperpape | 9 minutes ago
Realistically, there will be a two tiered system. Not every distro is equally prominent, or trustworthy, nor can every distro dedicate the resources to quickly patching.
It is not an attack on volunteers to observe that you don't typically ask them for an SLA, or that professionals should often prefer to depend on non-volunteer organizations.
johnklos | 9 hours ago
This is a Linux issue, not an ssh issue. The title should reflect this.
[OP] dzwdz | 9 hours ago
I agree that the title is misleading, but I had no other ideas for how to title it. Any suggestions? I can still edit it.
johnklos | 9 hours ago
Perhaps add “on Linux” at the end of the title?
[OP] dzwdz | an hour ago
Context for people coming in now: we were referring to the original title, "ssh-keysign-pwn: Read root-owned files as an unprivileged user", which I based on the repository's title and description.
I ended up giving up on that and I've changed the title to the current "linux 0-day, access root-owned files as an unprivileged user", just trying to highlight the most important stuff without suggesting anything incorrect (such as this being in any way related to SSH, or being a read-only exploit - this PoC is, but it seems more serious than that). I hate editorializing titles, but it is what it is.
[OP] dzwdz | 9 hours ago
The proof-of-concept is pleasantly short, and my boxes are indeed vulnerable.
It seems that this lets you access file descriptors opened by setuid executables under some conditions. I... see no reason why this would be only limited to reads. Surely you can twist this into an LPE that doesn't require cracking a hash.
You can break this poc in particular with
chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage(you might need to change the path to ssh-keysign. see also the manpage), but that doesn't fix the core issue, and it can probably be worked around. There are no other mitigations available that I know of.edit: this was fixed (and thus publicized) in ptrace: slightly saner 'get_dumpable()' logic (excuse the github link). 10 fucking hours ago.
edit 2: Here's a public announcement from Qualys sent to oss-security.
This is going to be good, I'm looking forward to it. In the meantime, here's Brad Spengler's (of grsecurity) commentary. It seems like that's the tweet that drove the development of this PoC.
quasi_qua_quasi | 5 hours ago
I tried running the PoC and wasn't able to get it to win the race, but the exploit_vuln_target/vuln_target pair worked fine. Bleh.
bja | 4 minutes ago
Practically, this affects systems where the user already has an unprivileged account - so one wouldn’t be able to use this to achieve RCE on an internet-exposed box running SSH without already having a valid login, correct?