libssh

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays on the Tier 2 row, which libssh reaches through its OSS-Fuzz integration, for a patch you get accepted upstream and that stays merged, without reverts, for one month, not for the report. The Tier 2 column runs from $100 for a one-liner to $5,000 for a complicated, high-impact change, and the memory-safety multiplier is Tier 1 only, so it does not apply here. The patch must be at least one month and under twelve months old, it is rate-limited to three submissions a person a month, the maintainers hold a veto, and sanctions and territory exclusions apply. Latest advisories Loading the feed Overview libssh is the SSH library applications reach for when they need SSH inside their own process rather than a shell out to the ssh binary. KDE, GitLab, X2Go and libvirt all link it, which puts it in remote-management paths, in CI and inside virtualisation control planes. It is unusual among SSH libraries in implementing the server side as well as the client, so its consumers include daemons that accept connections from anywhere and its authentication state machine is a genuine access-control boundary. An authentication bypass here hands over whatever the host was protecting. The project runs no bounty and the Internet Bug Bounty row that used to cover it is paused, so sorona.xyz pays you directly on qualified, reproduced findings. In scope [email protected] takes any not-yet-public security issue in libssh, and the maintainers fix privately, ship a numbered release and publish an advisory. Both halves of the library are in: the client implementation and the server implementation The server-side authentication state machine, where a client-supplied message sequence can drive a session into an authenticated state without valid credentials Pre-authentication packet handling on both sides: banner and version exchange, binary packet framing, and key exchange before any credential has been checked Memory safety in the transport layer, where a length or padding value taken off the wire drives a copy, a MAC check or a decompression step The authentication methods in full, covering public key, keyboard-interactive, password and GSSAPI, including the paths that report success or failure back to the caller Key, certificate and known_hosts parsing, and the host-key verification callbacks that decide whether a client trusts the server it reached The channel, SFTP and port-forwarding layers, where a peer controls sizes, request identifiers and filenames after the session is up The callback and options API surface, where an embedding application supplies its own authentication handlers and libssh decides what to do with their answers Out of scope libssh2, which is a different project with a different codebase despite the name, and has its own upstream and its own scope row OpenSSH, which is unrelated code and sits on its own Tier 1 row Defects that actually live in a linked crypto backend such as OpenSSL, mbedTLS or libgcrypt rather than in libssh Application-side API misuse: an embedding application that ignores a return value or wires its own authentication callback to always succeed One-line fixes for non-exploitable crashes, which the Patch Rewards rules will not reward, including crashes that come from resource exhaustion Patches the maintainers decline, patches under one month or over twelve months old, and anything past three submissions a person a month Most-valued findings Memory corruption reachable before authentication completes, the top bug class here at 38% and the class that turns any libssh-based daemon into a remote target A server-side authentication bypass, at 24% the second-largest class and the highest-impact one, since libssh's server mode is what GitLab-style and virtualisation front ends put in front of real credentials Host-key or certificate verification failure on the client side, which silently converts an authenticated channel into an interceptable one Parsing flaws in key or known_hosts handling driven by attacker-supplied files or peer-supplied blobs A systemic hardening patch across the transport or authentication state machine rather than a single instance. That is what the top of the Patch Rewards scale is written for, and one-liner crash fixes are explicitly excluded from it Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Send a detailed, reproducible report to the libssh security address; if the maintainers cannot reproduce it, it is not eligible Say whether the bug is on the client side, the server side or both, because libssh implements both and the impact differs sharply Give the maintainers room to ship a release and publish an advisory before any public writeup Findings that actually live in libssh2, OpenSSH or a linked crypto backend belong upstream with that project rather than here The Google patch money is a separate pathway: you land the fix upstream yourself and keep it merged, without reverts, for one month, and at Tier 2 there is no memory-safety multiplier Google cannot pay anyone on a sanctions list, in a sanctioned territory, or located in Russia or Belarus Disclosure Coordinated with the libssh maintainers through [email protected] . They fix privately, ship a numbered release and publish an advisory on libssh.org with researcher credit, giving the distributions a short private window first. Hold the detail until that release is out. Nothing in the Patch Rewards rules restricts who may help you prepare or route the report. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability