OpenSSH

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 $15,000 Google Patch Rewards pays on the Tier 1 named-project row for a patch you get accepted upstream and that stays merged, without reverts, for one month. It does not pay for the report. The Tier 1 column runs from $500 for a one-liner to $15,000 for a complicated, high-impact change, and a 2× memory-safety multiplier runs to the end of 2026 on top of that. 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, reactive single-CVE patches are reviewed case by case, and sanctions and territory exclusions apply. Latest advisories Loading the feed Overview OpenSSH is the SSH implementation on essentially every server on earth. It is the remote-administration path into Linux and the BSDs, it ships in Windows and macOS, and it is the transport under Git, rsync, Ansible and most automated deployment. sshd sits on a public listener by design and does a substantial amount of parsing before any client has authenticated, so a pre-authentication defect here is remote code execution against a large fraction of all reachable hosts at once. Google places it in Patch Rewards Tier 1 under "Other high-impact network services". The project itself still pays nothing for a report, so sorona.xyz pays you directly on a qualified, reproduced finding. In scope Reports go privately to the OpenSSH developers at their security address, against OpenSSH portable or the OpenBSD tree rather than a vendor's patched fork. Everything below sits inside that tree The whole of sshd, starting with the pre-authentication code paths: version and banner exchange, binary packet protocol framing, key exchange and the algorithm negotiation that precedes any credential check The authentication methods in full: public key, keyboard-interactive, password, host-based and GSSAPI, plus anything that lets a session reach an authenticated state without valid credentials The privilege-separation boundary, where the unprivileged pre-auth process talks to the privileged monitor, and any way the child can drive the parent past its intended checks Key and configuration parsing everywhere it happens: authorized_keys, known_hosts, private key files and sshd_config, including Match block evaluation and option expansion ssh-agent and agent forwarding, where a remote host reaches back into the client's key material The whole client side of the protocol, where a malicious or compromised server drives ssh, scp and sftp with attacker-chosen responses The file-transfer tools, meaning sftp-server and the scp path handling, including filename and glob expansion that crosses the boundary between what the client asked for and what the server delivers The key-management utilities, ssh-keygen and ssh-keyscan, which parse material supplied by whoever generated or served it Out of scope Defects that actually live in a linked library such as OpenSSL, zlib or a PAM module rather than in OpenSSH itself Vendor forks and heavily patched distribution builds where the upstream tree does not carry the defect Configuration arguments about which algorithms or authentication methods are enabled by default, which are policy rather than a defect Attacks that assume the attacker already holds valid credentials or a trusted host key, which sit inside the trust boundary 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 Pre-authentication memory corruption in sshd reachable by an unauthenticated client, which is the top bug class here at 38% and the single highest-consequence finding available anywhere in this rail An authentication bypass that puts a session past the credential check without valid material, since every access-control assumption on a Linux fleet rests on that check A privilege-separation escape that gets the unprivileged pre-auth process to code execution in the privileged monitor Client-side memory corruption triggered by a malicious server, which turns every outbound ssh, scp or automated deployment connection into an attack surface A systemic hardening patch that removes a whole class of pre-auth parsing risk rather than one instance. That is what the top of the Patch Rewards scale is written for, and the memory-safety multiplier doubles it until the end of 2026 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 OpenSSH developers at their security address; if they cannot reproduce it, it is not eligible Show the bug against OpenSSH portable or the OpenBSD tree rather than a vendor's heavily patched fork Give the developers room to ship a release before any public writeup; OpenSSH fixes land in a numbered release rather than a hotfix The Google patch money is a separate pathway: you land the fix upstream yourself and keep it merged, without reverts, for one month On that pathway a patch must be at least one month and under twelve months old, you may submit at most three a month, and reactive single-CVE patches are reviewed case by case Google cannot pay anyone on a sanctions list, in a sanctioned territory, or located in Russia or Belarus Disclosure Coordinated with the OpenSSH developers, who fix privately and then ship the fix in a numbered release with release notes crediting the reporter; distributions are given a short private window first because the update has to be simultaneous. 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