Curve.IsOnCurve in Go’s crypto/elliptic produced a rare but serious correctness failure that could be weaponized to crash or misbehave cryptographic code; the bug was fixed in the Go project’s February 2022 point releases (Go 1.16.14 and Go 1.17.7), and maintainers and downstream vendors issued patches and advisories as part of standard product-security rollouts.
The Go standard library implements elliptic-curve operations in package crypto/elliptic, which exposes Curve and CurveParams methods such as Add, Double, ScalarMult and IsOnCurve. The IsOnCurve function is a low-level predicate intended to check whether a given pair (x, y) is a valid point for the curve; callers — and downstream packages like crypto/ecdsa and some third‑party libraries — implicitly rely on its correctness.
In February 2022 a vulnerability was assigned CVE‑2022‑23806 (also tracked as GO‑2021‑0319). The problem: certain big.Int values that are not valid field elements (for example values that are negative or larger than the modulus) could cause Curve.IsOnCurve to incorrectly return true. Operating on those invalid values (for example carrying out ScalarMult or other operations) could then cause a panic or produce invalid results — in practice enabling denial-of-service (application crashes or panics) and, in some scenarios, integrity-impacting invalid computations. The Go team accepted the report, produced a fix, and released the patched point versions.
The issue was judged notable: many operating-system and vendor security trackers assigned high scores (CVSSv3 metrics reported in public trackers ranged into the high/critical range) and distributions pushed packaging updates. Vendors from Debian, Ubuntu and enterprise Linux vendors documented the bug and the fixed release numbers.
The project explicitly documented that Unmarshal will never produce those malformed big.Int values, and that the fix addresses direct low-level invocations that could otherwise be misled. Those notes are useful when triaging whether a specific code path is vulnerable: using high-level unmarshal/parsing helpers is safer than calling low-level IsOnCurve/ScalarMult with untrusted big.Int values, but the definitive remedy is to install patched runtime/library versions.
For teams that cannot immediately rebuild, take a staged approach: (1) identify and inventory affected binaries and build environments, (2) apply network/application mitigations to limit exposure, (3) schedule and test rebuilds with patched toolchains, and (4) adopt longer-term measures — SBOMs, strict input validation, and safer use of high-level crypto APIs — to reduce similar risks in the future. Vendor and distribution advisories (Debian, Ubuntu, SUSE, Oracle, Red Hat, cloud providers) are useful triage anchors; consult them to confirm which packaged artifacts in your environment require updates.
This class of bug is a reminder that cryptography is unforgiving: even a tiny correctness gap in representation checks can ripple into availability and integrity failures. The defensive steps — quick upgrades, disciplined builds, stronger validation, and careful input handling — are proven, practical, and should be routine parts of a secure software lifecycle.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
The Go standard library implements elliptic-curve operations in package crypto/elliptic, which exposes Curve and CurveParams methods such as Add, Double, ScalarMult and IsOnCurve. The IsOnCurve function is a low-level predicate intended to check whether a given pair (x, y) is a valid point for the curve; callers — and downstream packages like crypto/ecdsa and some third‑party libraries — implicitly rely on its correctness.In February 2022 a vulnerability was assigned CVE‑2022‑23806 (also tracked as GO‑2021‑0319). The problem: certain big.Int values that are not valid field elements (for example values that are negative or larger than the modulus) could cause Curve.IsOnCurve to incorrectly return true. Operating on those invalid values (for example carrying out ScalarMult or other operations) could then cause a panic or produce invalid results — in practice enabling denial-of-service (application crashes or panics) and, in some scenarios, integrity-impacting invalid computations. The Go team accepted the report, produced a fix, and released the patched point versions.
The issue was judged notable: many operating-system and vendor security trackers assigned high scores (CVSSv3 metrics reported in public trackers ranged into the high/critical range) and distributions pushed packaging updates. Vendors from Debian, Ubuntu and enterprise Linux vendors documented the bug and the fixed release numbers.
What went wrong: technical anatomy
How IsOnCurve is supposed to behave
Elliptic-curve arithmetic is defined on the finite field GF(p) for prime p: every coordinate that represents a legitimate point must satisfy 0 ≤ x,y < p and the curve equation y² ≡ x³ + ax + b (mod p). The IsOnCurve predicate is expected to reject values outside the valid field range and to return false for coordinates that do not satisfy the curve equation. Packages that implement higher-level cryptography assume this invariant.The real bug: invalid field elements misclassified as valid
In this bug class, some constructed big.Int inputs — notably negative numbers or integers that overflow the modulus limb arithmetic used internally — followed code paths that bypassed the intended range checks, allowing IsOnCurve to return true for inputs that should have been rejected. Once treated as “on-curve,” subsequent operations like ScalarMult could panic (triggering runtime errors) or produce invalid points. The Go project’s vulnerability report and the corrective commit explain that the problem stemmed from insufficient validation of the big.Int representation in a small number of edge cases; the fix explicitly rejects invalid field-element representations.Important caveat: how (and how not) these values typically appear
Two operational facts reduce the immediate attack surface in practice, but do not eliminate it:- The standard public parsing path — Unmarshal and other high-level unmarshalling helpers used to parse externally supplied encoded points — will not produce these invalid big.Int values when given properly formatted wire data. In other words, routine TLS-style parsing or normal certificate/unmarshal flows are not normally expected to generate these particular malformed big.Ints.
- The vulnerability is most relevant when code directly constructs, passes, or otherwise accepts arbitrary big.Int values into curve operations, or when code calls low-level helpers that do not sanitize untrusted integers. Attackers who can feed carefully crafted big.Ints into those code paths can provoke the incorrect IsOnCurve behavior and its downstream effects.
What the Go project changed (the fix)
The Go project accepted the report and committed a small, targeted change to crypto/elliptic that causes IsOnCurve to return false for the previously misclassified big.Int values. The relevant commit message states the fix clearly: “crypto/elliptic: make IsOnCurve return false for invalid field elements,” credits the reporter, links the upstream issue, and marks the change as fixing CVE‑2022‑23806. The change was included in the Go point releases Go 1.16.14 and Go 1.17.7.The project explicitly documented that Unmarshal will never produce those malformed big.Int values, and that the fix addresses direct low-level invocations that could otherwise be misled. Those notes are useful when triaging whether a specific code path is vulnerable: using high-level unmarshal/parsing helpers is safer than calling low-level IsOnCurve/ScalarMult with untrusted big.Int values, but the definitive remedy is to install patched runtime/library versions.
Who was affected — ecosystem and vendor responses
CVE‑2022‑23806 touched more than just individual Go programs: it affected distributions and products that ship Go runtimes, toolchains, or pre-built Go binaries. Major Linux distributors and vendors added the CVE to their trackers and published advisories or errata:- Debian and Debian LTS tracked the issue and produced DLA advisories for affected source packages.
- Ubuntu included CVE‑2022‑23806 in its security tracker with CVSS scoring and status notes.
- SUSE, Oracle Linux, Red Hat/OpenShift, Amazon Linux and other vendors issued patch advisories in their respective channels; many packaging updates fixed the underlying golang packages or the distribution-provided Go toolchain.
- Product vendors who embed Go-built components (for example IBM service bulletins listing Go CVEs) published product-specific guidance where relevant, often instructing customers to update product versions or underlying images.
Operational risk analysis — why this mattered
- Availability / Denial-of-Service: The most immediate operational risk was denial of availability — crafted inputs could provoke panics inside crypto code (e.g., ScalarMult panicking after IsOnCurve misclassification), crashing goroutines or bringing down services that do not isolate or recover from such panics. Vendor advisories and security trackers described DoS as the central impact.
- Integrity concerns: Because invalid arithmetic could be accepted as legitimate and then used in cryptographic calculations, there is a secondary risk of invalid cryptographic results (integrity impact). In practice this is more subtle and depends on whether an application uses the results in ways that affect authenticity decisions. tracked advisories flagged integrity as a potential consequence in some contexts.
- Supply-chain / build-time persistence: Go binaries commonly include the standard library code at build time; many teams ship statically linked or single-file Go executables that embed crypto/elliptic. That means a program built with a vulnerable Go toolchain retains the vulnerable code even after being deployed — only rebuilding with a patched toolchain or replacing the binary with a patched build removes the vulnerability from the shipped executable. For organizations that rely on prebuilt third‑party binaries or immutable container images, that creates a sustained remediation task beyond simply updating a runtime on a host. The Go project provides mechanisms for external/shared linking, but the most common practice remains shipping self-contained executables; vendors and maintainers thus had to consider rebuild-and-redeploy.
- Detection complexity: The vulnerability is not a simple version string in every environment. A runtime might be vulnerable if the binary was built with an affected toolchain, or if it dynamically links an affected shared stdlib variant; conversely, upgrading system packages without rebuilding third-party statically-linked binaries does not fix them. This multiplicity of build/linking models complicated enterprise triage.
Practical guidance — triage, detection, and remediation
Below is a practical checklist for defenders and maintainers to assess and mitigate risk from CVE‑2022‑23806.- Inventory: determine which systems run Go-built code or ship Go toolchains. Check package managers (golang packages), container base images, CI build agents, and any third‑party Go binaries deployed in your estate. Use package scanner tooling and SBOMs where available.
- Command sanity checks: run go version on build hosts and check distribution package versions (if the distro supplies golang packages).
- Check binary provenance: for deployed executables, identify whether the binary was built with an affected Go release. If you have build records, confirm the go toolchain version used, or rebuild with a patched toolchain as a precaution. Remember: many Go binaries are self-contained and retain their stdlib code.
- Upgrade toolchains and system packages: upgrade your Go toolchain to at least Go 1.16.14, 1.17.7 or any later supported release (the official note for the fix is these point releases). Also apply vendor OS/package updates that include the patched golang builds.
- Rebuild and redeploy: For any in‑house or third‑party binary built with a vulnerable toolchain, rebuild with a patched toolchain and redeploy. For containerized workloads, update container base images and rebuild images that include Go binaries. If rebuilding is not immediately possible, plan compensating controls (see below).
- Compensating controls (temporary): if you cannot immediately rebuild, consider isolating services that may process untrusted curve inputs (rate-limiting, stricter input validation at the application edge, or sandboxing untrusted parsing paths). Where feasible, avoid exposing APIs that accept raw big‑integer inputs or low-level elliptic operations from untrusted callers. These are temporary measures and do not replace the security of a patched build.
- Code audit: scan your codebase for direct calls to crypto/elliptic.CurveParams.IsOnCurve, ScalarMult, Add, Double and any places that accept or construct big.Int values for curve arithmetic. Pay special attention to code that manipulates big.Int directly (rather than using safe high‑level unmarshalling).
- Monitor vendor advisories and re-test: follow OS and product advisories for confirmation that your specific distribution package has been patched, and test updated builds in staging before production rollout. Vendors including Debian, Ubuntu, SUSE, Oracle, Red Hat and cloud providers published advisories and package updates for affected components.
Why this case is a useful security lesson
- Small correctness bugs in crypto primitives have outsized operational impact. Cryptography code must be both correct and protective against malformed inputs; a function as small as IsOnCurve is a correctness gatekeeper and, when wrong, undermines higher-level assurances. The Go project’s quick acceptance and fix demonstrate responsible vulnerability handling, but the incident highlights how subtle arithmetic/representation issues can slip through.
- Build/release practices matter. Because Go commonly produces self-contained binaries, a single vulnerable build can persist in production until rebuild and redeploy; distribution/package patching is necessary but not always sufficient. This is an operational risk that teams must manage through SBOMs, reproducible builds, and clear CI practices that make rollback/rebuild paths simple.
- Defense in depth: using higher-level, well-audited APIs (Unmarshal) rather than low-level bigint manipulation reduces exposure. Libraries and applications that accept external inputs should avoid passing raw big.Ints into elliptic-curve helpers without sanitary checks. Additionally, panics should be contained: recover patterns, supervision processes and graceful degradation help limit DoS impact when code unexpectedly panics.
Final assessment and recommendations
CVE‑2022‑23806 was a concrete, narrow correctness bug in the Go standard library’s elliptic-curve code that carried real-world operational consequences — most prominently denial of service. The Go project fixed the root cause and published point releases; distributions and downstream vendors updated packages and published guidance. The principal remedial action for operators is straightforward: upgrade toolchains and rebuild or replace binaries that were produced with the vulnerable releases.For teams that cannot immediately rebuild, take a staged approach: (1) identify and inventory affected binaries and build environments, (2) apply network/application mitigations to limit exposure, (3) schedule and test rebuilds with patched toolchains, and (4) adopt longer-term measures — SBOMs, strict input validation, and safer use of high-level crypto APIs — to reduce similar risks in the future. Vendor and distribution advisories (Debian, Ubuntu, SUSE, Oracle, Red Hat, cloud providers) are useful triage anchors; consult them to confirm which packaged artifacts in your environment require updates.
This class of bug is a reminder that cryptography is unforgiving: even a tiny correctness gap in representation checks can ripple into availability and integrity failures. The defensive steps — quick upgrades, disciplined builds, stronger validation, and careful input handling — are proven, practical, and should be routine parts of a secure software lifecycle.
Source: MSRC Security Update Guide - Microsoft Security Response Center
