You opened a terminal, typed ssh, and pulled from a host you’ve used a hundred times. Routine. Except this time the server was compromised, and the instant your client finished the handshake, memory corruption fired and someone else’s code ran on your machine. No password prompt. No click. That’s the scenario a fresh proof-of-concept for CVE-2026-55200 makes real, and it should reshape how you think about cybersecurity at the endpoint instead of just the edge.

The flaw lives in libssh2, the client-side SSH library baked into git, curl, monitoring agents, CI runners, and a long tail of embedded gear. A malicious or compromised SSH server can corrupt memory on the connecting client, with code execution on the table. It affects every release up to and including 1.11.1.

No credentials. No user interaction. CVSS 4.0 score of 9.2, and the library in question isn’t a server you harden. It’s a client you trust by default.

Outbound Trust Is The Cybersecurity Blind Spot

Almost every defensive instinct points inward. You harden the server, you lock the listening port, you assume the dangerous traffic is the stuff arriving uninvited. SSH fits that mental model perfectly: the server is the asset, the client is the trusted operator reaching in.

CVE-2026-55200 flips the arrows. The danger travels back up the wire you initiated. Your own outbound connection is the delivery mechanism, and the thing you reached out to is the attacker. Anything that links libssh2 inherits the exposure, often without the developer realizing the library is even in the build.

This isn’t a one-off. The same week, researchers found hijacked npm packages and a cluster of Go packages quietly deploying a Python infostealer across Windows, Linux, and macOS. The clever part: the attack dodged the usual npm lifecycle scripts and instead abused VS Code tasks to execute, specifically to slip past newer package-manager hardening.

Different bug, same lesson. The target is the developer and admin endpoint, and the weapon is the thing that endpoint trusts: a package registry, an upstream server, a build tool. You went looking for something legitimate and brought home a passenger.

Your Firewall Watches The Door. The Threat Walks Out With You.

Here’s the uncomfortable part. Your firewall, your brute-force protection, your inbound threat detection rules, they’re all standing at the front door checking IDs. A client-side SSH exploit or a poisoned dependency doesn’t knock. It leaves with you and comes back as a guest.

Perimeter controls assume the connection’s origin is the risk. When your own workstation initiates the session to a server an attacker controls, the malicious payload rides a channel you authorized, encrypted end to end, indistinguishable from legitimate work. The tooling that’s supposed to catch intrusions sees a normal outbound SSH session and a developer running their build. Nothing trips.

This is exactly why defense in depth stopped being a slogan and became survival. One control failing should be an inconvenience, not a breach. If the only thing standing between a compromised upstream and your production keys is “the library was supposed to be safe,” you don’t have layers. You have a single point of failure with good marketing.

The privileged workstation is the worst place to learn this. The box your engineers use to ssh into production, run git pull, and install dependencies is frequently the same box holding cloud credentials, signing keys, and an unrestricted path to everything that matters. Own that endpoint and you’ve skipped the entire fight at the perimeter.

Patch, Pin, And Watch Before Monday

You can’t patch trust, but you can stop extending it for free. Here’s where to spend the next few hours, then the next few weeks.

• Find every place libssh2 actually lives. It’s rarely in your dependency manifest by name. Check git clients, curl builds, monitoring and backup agents, CI runners, network appliances, and embedded devices. Statically linked binaries need rebuilding, not just an OS package bump. Update past 1.11.1 the moment a fixed release lands.
• Treat every SSH destination as hostile until proven otherwise. Pin known host keys, alert hard on any host-key change, and stop connecting to ephemeral or untrusted servers from machines that hold production secrets.
• Filter egress, not just ingress. Developer and admin endpoints should not be able to talk to arbitrary destinations. Restrict outbound, and use behavior-based threat detection that flags odd child processes spawned by ssh, git, node, or your package manager.
• Pin and verify dependencies, and isolate where you install them. Don’t run npm install or go get on the same host that can reach production. Build in throwaway environments, verify package integrity, and watch for execution paths that route around lifecycle scripts.
• Rehearse incident response for a compromised endpoint. Most playbooks assume a breached server. Write and drill the version where a single engineer’s laptop is the patient zero, including credential rotation, key revocation, and scoping blast radius across everything that laptop could reach.

Security hardening here is less about a single patch and more about refusing to grant implicit trust to outbound connections and upstream code. The bug will get fixed. The trust assumption that made it dangerous won’t, unless you change it.

Plenty of teams will read the libssh2 advisory, confirm they don’t run an SSH server, and move on. That’s the mistake. This was never about the servers you run. It’s about the ones you reach for, and the code you pull in, on the machines that can hurt you most. Check your clients. The threat already knows you’ll connect.

Sources

• Public PoC Released for Critical libssh2 CVE-2026-55200 Client-Side SSH Flaw
• Hijacked npm and Go Packages Use VS Code Tasks to Deploy Python Infostealer