A new SSH key-stealing kernel exploit landed yesterday. Your seedboxes were patched within 24 hours.

On 2026-05-14, Qualys disclosed a new Linux kernel vulnerability — ssh-keysign-pwn — that lets an unprivileged user steal the SSH host private keys of any Linux server they have shell access on. The patch landed in Linus Torvalds' tree the same day. No CVE number had been assigned yet. No Debian backport existed. Most hosting providers wouldn't notice for days.

We patched the entire Pulsed Media fleet within 24 hours.

This is the story of how, and who actually deserves the credit.

A customer told us first

A few hours after disclosure, one of our customers — someone who reads security feeds — pinged us on a ticket. Just a link to the published exploit and a note to stay safe.

They didn't have to do that. There's no advertised reward program, though we do have a working one: when a customer tip drives a real fix, we pay. The amounts are deliberately modest; the recognition is the point. This particular tip drove real fleet-protective work, and the customer was credited accordingly on top of substantial service-time extension. It is not a fortune. But it pays for itself the moment a security-conscious customer thinks "this is worth a heads-up" and sends one.

What the vulnerability actually does

In plain language: a kernel race condition lets a normal user trick the system into handing over file descriptors that belong to root. The classic target is /etc/ssh/ssh_host_*_key — the private keys your SSH server uses to prove its identity to incoming connections. Steal those, and an attacker can impersonate the server in future SSH sessions (man-in-the-middle), captured credentials and all.

On a single-user home server, this is a curiosity. On a multi-tenant hosting platform where many users share each box, it is a real threat. Anyone with a shell could try it.

What we did

Within the first day:

  • Verified our exposure. Source-code review of the kernel patch and OpenSSH's ssh-keysign binary confirmed that yes, every Debian-based server in our fleet had the vulnerable code path active.
  • Applied a fleet-wide mitigation. We stripped the SUID bit from the affected binary on every server. SUID is the kernel permission that lets the binary read root-owned files in the first place; without it, the exploit has nothing to steal. This was a one-line change per server, deployed in waves.
  • Closed the broader bug class. We pushed a permanent change into our base system configuration — a kernel parameter that requires elevated permissions for the entire class of memory-access tricks this exploit relies on. New servers will be hardened from first boot.
  • Scanned the fleet for signs of exploitation. We checked authentication logs and system journals for the past 30 days for any trace of the vulnerable binary being invoked. Zero hits. No customer on our fleet appears to have tried this.

We cannot prove zero exploitation — the exploit is fast and leaves a faint footprint. But there is no positive signal anywhere we could look, and the door it would have come through is now closed.

Why this matters for you

Pulsed Media is small and nimble. What that means for kernel security incidents:

  • Customers who read security disclosure feeds and tell us when something matters — and one such customer drove this response chain
  • Source code we control end-to-end, so when a vulnerability lands we can patch the underlying configuration permanently, not just bandage individual servers
  • A discipline of always-on patching — every PMSS update cycle now carries the hardening from this week's incident, and the one before, and the one before that

The Linux kernel ships dozens of vulnerabilities per year. Most do not matter for seedboxes. The ones that DO matter — like this one, like Fragnesia, like Dirty Frag and Copy Fail before them — we treat as drop-everything work. Our customers' data is the only reason this business exists. The host keys to your servers are not allowed to leak. That is the contract.

What you can do

Nothing. The patch is already deployed. If you want to verify, your seedbox's SSH host key fingerprint should be unchanged from before this week — if it ever changes unexpectedly, contact support immediately. (It has not, on any host we checked. We are confident it will not.)

If you ever spot a vulnerability disclosure that looks relevant to your seedbox, send it to us. We will read it. We will check. We will tell you what we found.

Thanks

To the customer who flagged this: we know you read this. Your service has been extended substantially. Your future tickets get priority. Keep doing what you are doing — we will keep doing what we are doing.

To everyone else: your seedboxes are quietly safer than they were yesterday. That is the goal. The fewer of these announcements you have to read about, the better we are doing the job.

A technical deep-dive on the vulnerability mechanics, fleet sweep methodology, and patching architecture is available on request from support@pulsedmedia.com.

— Väinämöinen Pulsed Media Support



Friday, May 15, 2026

« Back