GHSA-69jw-4jj8-fcxm — gokey
Fix: cloudflare/gokey@f261819GHSA-69jw-4jj8-fcxm is a security vulnerability in github.com/cloudflare/gokey. A fix is available for github.com/cloudflare/gokey — see the affected versions and patch details below.
gokey allows secret recovery from a seed file without the master password
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-69jw-4jj8-fcxm.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
github.com/cloudflare/gokeyReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
In gokey versions <0.2.0, a flaw in the seed decryption logic resulted in passwords incorrectly being derived solely from the initial vector and the AES-GCM authentication tag of the key seed.
This issue has been fixed in gokey version 0.2.0. This is a breaking change. The fix has invalidated any passwords/secrets that were derived from the seed file (using the -s option). Even if the input seed file stays the same, version 0.2.0 gokey will generate different secrets.
Impact
This vulnerability impacts generated keys/secrets using a seed file as an entropy input (using the -s option). Keys/secrets generated just from the master password (without the -s option) are not impacted. The confidentiality of the seed itself is also not impacted (it is not required to regenerate the seed itself). Specific impact includes:
- keys/secrets generated from a seed file may have lower entropy: it was expected that the whole seed would be used to generate keys (240 bytes of entropy input), where in vulnerable versions only 28 bytes was used
- a malicious entity could have recovered all passwords, generated from a particular seed, having only the seed file in possession without the knowledge of the seed master password
Patches
The code logic bug has been fixed in gokey version 0.2.0 and above. Due to the deterministic nature of gokey, fixed versions will produce different passwords/secrets using seed files, as all seed entropy will be used now.
System secret rotation guidance
It is advised for users to regenerate passwords/secrets using the patched version of gokey (0.2.0 and above), and provision/rotate these secrets into respective systems in place of the old secret. A specific rotation procedure is system-dependent, but most common patterns are described below.
Systems that do not require the old password/secret for rotation
Such systems usually have a "Forgot password" facility or a similar facility allowing users to rotate their password/secrets by sending a unique "magic" link to the user's email or phone. In such cases users are advised to use this facility and input the newly generated password secret, when prompted by the system.
Systems that require the old password/secret for rotation
Such systems usually have a modal password rotation window usually in the user settings section requiring the user to input the old and the new password sometimes with a confirmation. To generate/recover the old password in such cases users are advised to:
- temporarily download gokey version
0.1.3for their respective operating system to recover the old password - use gokey version
0.2.0or above to generate the new password - populate the system provided password rotation form
Systems that allow multiple credentials for the same account to be provisioned
Such systems usually require a secret or a cryptographic key as a credential for access, but allow several credentials at the same time. One example is SSH: a particular user may have several authorized public keys configured on the SSH server for access. For such systems users are advised to:
- generate a new secret/key/credential using gokey version
0.2.0or above - provision the new secret/key/credential in addition to the existing credential on the system
- verify that the access or required system operation is still possible with the new secret/key/credential
- revoke authorization for the existing/old credential from the system
Credit
This vulnerability was found by Théo Cusnir (@mister_mime) and responsibly disclosed through Cloudflare's bug bounty program.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/cloudflare/gokey | all versions | 0.2.0go get github.com/cloudflare/gokey@v0.2.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/cloudflare/gokey, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/cloudflare/gokey to 0.2.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-69jw-4jj8-fcxm is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-69jw-4jj8-fcxm can be triaged on real exposure rather than presence alone.
Tailored to GHSA-69jw-4jj8-fcxm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-69jw-4jj8-fcxm in your dependencies?
O3 Security finds GHSA-69jw-4jj8-fcxm across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.