Bugs That Live in the Seams: What SSHole and ThisBash Teach About Trust Boundaries

11/11/2026

Two stories crossed my feeds within a day of each other last week, and they look unrelated. One is about the most trusted remote-login software on the internet. The other is about an AI assistant that can run commands on your laptop. Read them side by side, though, and they are the same story: a vulnerability that no single component owns, because it lives in the seam between two of them.

SSHole: an error value that looked like a valid state

CVE-2026-123158, nicknamed SSHole, is a password-authentication bypass in portable OpenSSH. It was fixed in OpenSSH 10.6p2 on 5 November 2026, scored 8.1 (High), and within hours multiple outlets were reporting exploitation attempts, including root access on an Alpine Linux honeypot.

The interesting part is how narrow and how old it is. It only bites when sshd is built against musl libc without PAM, which is exactly how Alpine's default openssh-server package ships. Glibc distributions such as Debian, Ubuntu, and RHEL are not affected, and neither are systems that check passwords through PAM.

The mechanism, as TuxCare's analysis lays it out, takes two reasonable decisions and puts them next to each other:

  • When an account's stored password is too short to be a real hash (for example a single *, the conventional marker for "this account has no password, use keys"), sshd borrows a salt from another account so that timing doesn't reveal which users exist. That behaviour dates back to a 2016 fix.
  • musl's crypt() signals an error by returning the string *. Hand it a SHA-512 setting and a password longer than 256 bytes, and it errors.

So: the stored value is *, the computed value is *, and the comparison says the passwords match. A key-only account accepts a sufficiently long junk password. OpenSSH says the root cause is outside sshd; the musl maintainer says it is an erroneous use by the caller. Both are defensible positions, and the system is still broken. That is what a seam bug looks like.

The fix adds a minimum hash length so short markers like * can never match. If you can't patch immediately, the OpenSSH developers' advice is blunt: set PasswordAuthentication no or turn SSH off on affected systems. Don't forget the places musl hides: container images built on Alpine, and embedded devices.

ThisBash: a hidden link is not an access control

The second story is ThisBash, published by Forever Security last week. It concerns Claude Dispatch, a feature that lets you send instructions from your phone to Claude Desktop, which is a code-capable agent able to run commands on the machine it is installed on.

The researchers found that Dispatch was designed for the desktop app, but its interface and API were also reachable from an ordinary logged-in claude.ai browser session. The web version simply didn't show a link to it. In their words, "the missing link hid the feature without restricting access to it."

That turns any browser extension with permission to script claude.ai into a remote-control channel. Their proof of concept used an extension with the scripting permission and broad host access. It opened a small Dispatch window, submitted prompts, and clicked the "Allow" buttons automatically every second, until Claude Desktop installed an npm package that opened Calculator. Because Dispatch pairs devices by account, the target desktop does not have to be the same machine as the browser. The researchers also say they observed personal Claude accounts with Dispatch enabled on corporate endpoints.

According to the researchers' timeline, they reported it to Anthropic on 14 May, Anthropic acknowledged it as valid and closed it as a duplicate of an internal issue, and in October said Dispatch would be retired, targeting the end of October. Anthropic's help pages reportedly show Dispatch as unavailable to new users. The researchers also say Claude Code Remote Control and Claude Cowork sessions allow the same style of attack, with a follow-up post promised. Check the current status for your own environment rather than relying on any of these dates.

Two seams this time. The first is between "not shown in the UI" and "not allowed by the server". The second is between a confirmation dialog and a human: an "Allow" button rendered in a page an attacker can script is not consent, because it can be clicked by code just as easily as by a person.

The common lesson

Strip away the specifics, and both bugs come from one assumption: that the component next to me enforces the thing I'm relying on. sshd relied on crypt() never producing something that looks like a stored marker. Dispatch relied on the web UI never showing the link. Each piece was reasonable in isolation. The security property lived in the gap, and nobody owned the gap.

That is also why both took so long to find. Reviews and audits are usually scoped to a component: the SSH daemon, the C library, the desktop app, the web app. Seam bugs only appear when someone asks what happens when this output meets that input, or when this session can reach that API.

What I'd do this week

  1. Find musl. Inventory hosts, containers, and appliances running OpenSSH on Alpine or other musl builds. Patch to a fixed package, or disable password authentication and verify with sshd -T, since on older Alpine releases a drop-in config file is silently ignored.
  2. Check for accounts marked *. Key-only accounts are the targets. If a host was exposed, review new users and new authorized_keys entries, and treat it as compromised if you can't rule out a login.
  3. Treat browser extensions as endpoint software. Review which extensions can script the sites where your AI assistants live, and control installation and permission changes like any other software. (The Browser Extensions tab on Security Feeds tracks known-malicious ones.)
  4. Inventory agents that can act on endpoints. Which desktop agents are installed, which accounts they are tied to, and whether those are corporate-managed or personal. Disable cross-device features where there is no business need. The agent identity playbook has the longer version.
  5. Ask vendors about their seams. In your next evaluation, ask: which of your features are reachable from which sessions, and is that enforced on the server or only in the interface? A vendor who can answer that crisply has thought about it.

The most dangerous assumption in security is rarely "this code is correct". It is "the thing next to this code will take care of it".

Sources: TuxCare's analysis of CVE-2026-123158; Help Net Security and The Hacker News on exploitation; Forever Security's ThisBash write-up. Details were current as of 7 November 2026 and may change as vendors respond. The views here are my own and are not legal or professional advice.