GHSA-vg44-fw64-cpjx is a high-severity (CVSS 7.5) remote code execution vulnerability in eth-ledger-bridge-keyring. O3 Security confirms whether GHSA-vg44-fw64-cpjx is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Incorrect Account Used for Signing
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
eth-ledger-bridge-keyringnpm@metamask/eth-ledger-bridge-keyringnpmDescription
Impact
Anybody using this library to sign with a BIP44 account other than the first account may be affected. If a user is signing with the first account (i.e. the account at index 0), or with the legacy MEW/MyCrypto HD path, they are not affected.
The vulnerability impacts cases where the user signs a personal message or transaction without first adding the account. This includes cases where the user has already added the account in a previous session (i.e. they added the account, reset the application, then signed something). The serialization/deserialization process does restore a previously added account, but it doesn't restore the index instructing the keyring to use that account for signing. As a result, after serializing then deserializing the keyring state, the account at index 0 is always used for signing even if it isn't the current account.
Patches
This has been patched (#14) in version >=0.2.1 of eth-ledger-bridge-keyring, and in version >=0.2.2 of @metamask/eth-ledger-bridge-keyring. Users are encouraged to migrate to the new package name.
Workarounds
To work around this problem without updating, you should remove then re-add the account before use. As long as the account was added during the lifetime of that process, signing with that account should work correctly.
For more information
If you have any questions or comments about this advisory:
- Open an issue in MetaMask/eth-ledger-bridge-keyring on GitHub
- Email the MetaMask team at [email protected]
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | eth-ledger-bridge-keyring | all versions | 0.2.1 |
| 📦npm | @metamask/eth-ledger-bridge-keyring | all versions | 0.2.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for eth-ledger-bridge-keyring. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update eth-ledger-bridge-keyring to 0.2.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vg44-fw64-cpjx 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 pinpoints whether GHSA-vg44-fw64-cpjx is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-vg44-fw64-cpjx. 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-vg44-fw64-cpjx in your dependencies?
O3 detects GHSA-vg44-fw64-cpjx across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.