CVE-2021-43565: Denial of service in golang.org/x/crypto/...

CVE-2021-43565 is a denial-of-service vulnerability in the SSH implementation shipped as part of golang.org/x/crypto, the extended cryptography module maintained by the Go team. The flaw sits in the low-level packet handling logic of the ssh package: a peer in an SSH session — client or server — can send a maliciously crafted packet during connection setup that causes the other side's process to panic and crash. Because golang.org/x/crypto/ssh is the de facto standard SSH library for Go applications (used to build everything from SFTP servers and bastion hosts to CI runners and IoT management agents), the practical blast radius of this bug extends well beyond the standard library itself and into a large slice of the Go supply chain.

This is a classic library-level availability bug rather than a remote-code-execution or credential-theft issue: there is no reported path to confidentiality or integrity impact. But for any service where uptime matters — SSH-based deployment pipelines, git servers, remote access gateways — an unauthenticated actor able to reach the SSH port can knock the process over with a single crafted packet, and if the process is not supervised to restart cleanly, that can translate into a real outage.

Affected versions and components

The vulnerability lives in the golang.org/x/crypto/ssh package, not in Go's standard crypto packages, which is an important distinction when triaging exposure. Any Go binary that imports golang.org/x/crypto/ssh — directly or transitively through a dependency such as an SSH/SFTP server framework, a Kubernetes tool that shells out over SSH, or a custom bastion/jump-host implementation — built against a pre-fix version of the module is potentially affected on both the client and server side of a connection.

The fix landed in the module at commit 5770296d904e, corresponding to the pseudo-version golang.org/x/crypto@v0.0.0-20211202192323-5770296d904e. Any module resolution pinned to a golang.org/x/crypto pseudo-version older than that commit, or any tagged release predating it, should be treated as vulnerable. Because golang.org/x/crypto was distributed almost exclusively via commit-based pseudo-versions for years before the project adopted semantic version tags, exposure in the wild is scattered across a long tail of go.sum entries pinned to arbitrary pre-December-2021 commits — which is exactly the kind of stale, hard-to-eyeball dependency state that tends to survive unnoticed in vendored vendor/ directories and infrequently updated Go modules.

Severity, exploitation likelihood, and known exploitation

Public vulnerability databases list CVE-2021-43565 with a CVSS 3.1 base score of 7.5 (High), reflecting a network-exploitable, low-complexity, no-privilege, no-user-interaction attack whose only impact is availability (a crash), with no effect on confidentiality or integrity. That combination — high reachability, zero impact confinement to availability — is typical of parser and packet-handling bugs in protocol libraries: trivial to trigger once you understand the malformed input, but limited in what an attacker actually gains beyond an outage.

EPSS scoring for this CVE is low, consistent with a bug that requires an attacker to be network-positioned as an SSH peer, has no public proof-of-concept exploit widely circulated, and yields denial of service rather than a foothold an attacker can chain further. It has not been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no public reporting of in-the-wild exploitation. In practice, this means the vulnerability should be prioritized as a patch-hygiene and availability issue rather than an active-incident-response trigger — but "low observed exploitation" is not the same as "safe to ignore," particularly for internet-facing SSH servers built on the affected package.

Timeline

The bug was identified and reported through the Go project's standard security process for golang.org/x/crypto, which handles vulnerabilities in the x/ extended module tree separately from the Go standard library CVE stream. The fix was committed to the module in early December 2021, and the corresponding GitHub Security Advisory and CVE record were published to the community shortly after, giving downstream consumers visibility into both the crash condition and the exact commit that resolved it. As with most golang.org/x/crypto advisories, there was no extended embargo period with vendor coordination beyond the usual Go security disclosure window — once the fix was merged and tagged, the advisory went public and the pseudo-version became the reference point every dependent project needed to match or exceed.

Because golang.org/x/crypto did not yet use semantic version tags at the time, "patched" is defined by commit date rather than a clean version number jump, which is precisely why dependency scanners that understand Go pseudo-versions (rather than just semver ranges) are necessary to reliably catch this one.

Remediation steps

1. Identify exposure. Run go list -m all or inspect go.sum for every service in your Go estate to find golang.org/x/crypto entries, and check whether any resolve to a pseudo-version predating v0.0.0-20211202192323-5770296d904e. Pay particular attention to transitive dependencies — SFTP servers, SSH tunneling libraries, and remote-execution tooling frequently pull in x/crypto/ssh without it appearing as a direct import in your own code.
2. Upgrade the module. Run go get -u golang.org/x/crypto@latest (or pin explicitly to a version at or after the fix commit) and regenerate go.sum. Any tagged release from the module's later semantic-versioning era (v0.1.0 onward) already includes this fix, so a routine "upgrade x/crypto to latest" pass resolves it as a side effect.
3. Rebuild and redeploy. Because this is a compiled dependency, the fix only takes effect once affected binaries are rebuilt against the patched module and redeployed — patching go.mod alone in source control does nothing for services still running an old binary.
4. Run govulncheck. Go's official vulnerability scanner cross-references your actual call graph against the Go vulnerability database and will flag binaries that both import the vulnerable code path and actually reach it, cutting down noise versus a blanket "any old x/crypto = vulnerable" alert.
5. Add crash resilience regardless. SSH-facing services should already run under a supervisor (systemd, Kubernetes liveness/restart policies, process managers) that restarts a crashed process quickly. This doesn't fix the vulnerability, but it limits the duration of any denial-of-service window if a similar packet-handling bug surfaces again before you've patched.
6. Verify with SBOM/dependency inventory tooling that no downstream image or artifact still embeds a pre-fix x/crypto commit, since container images built before the upgrade will keep shipping the vulnerable binary until they're rebuilt from a refreshed base.

How Safeguard Helps

CVE-2021-43565 is a good example of the class of vulnerability that's easy to miss precisely because it hides in transitive Go dependencies pinned by commit hash rather than a clean version number — the kind of gap that a one-time audit catches and then loses track of as the dependency tree keeps moving. Safeguard's software composition analysis continuously resolves the full dependency graph for Go services, including indirect imports of golang.org/x/crypto/ssh, and maps each resolved pseudo-version or tag against known-fixed commits so a stale, pre-patch SSH library doesn't quietly persist in a rebuilt image or a forgotten internal tool.

Beyond flagging the vulnerable version, Safeguard correlates exposure with real reachability and deployment context — surfacing which services actually expose an SSH listener or act as an SSH client to untrusted peers, so remediation work is prioritized against genuine denial-of-service risk rather than treated as a flat inventory finding. That context matters for a CVSS-7.5 availability bug like this one: not every internal build tool that happens to import x/crypto/ssh carries the same operational risk as a public-facing bastion host, and Safeguard's platform is built to make that distinction visible instead of forcing every finding into the same severity bucket.

Finally, Safeguard's continuous monitoring means that when the Go team ships the next x/crypto or x/crypto/ssh advisory, the same pipeline that caught CVE-2021-43565 automatically re-evaluates your fleet against the new fix commit — closing the loop on the pattern of unpinned, commit-based Go module versions that let vulnerabilities like this one linger long after a patch exists.