- cvss
- 7.5
- version 3.1, GitHub
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
### 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](https://github.com/MetaMask/eth-ledger-bridge-keyring/pull/14)) in version >=0.2.1 of [`eth-ledger-bridge-keyring`](https://www.npmjs.com/package/eth-ledger-bridge-keyring), and in version >=0.2.2 of [`@metamask/eth-ledger-bridge-keyring`](https://www.npmjs.com/package/@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](https://github.com/MetaMask/eth-ledger-bridge-keyring) * Email the MetaMask team at [hello@metamask.io](mailto:hello@metamask.io)
Patch / fix
- npm eth-ledger-bridge-keyring 0.2.1
- npm @metamask/eth-ledger-bridge-keyring 0.2.2
Is GHSA-vg44-fw64-cpjx in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| GitHub | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| npm | eth-ledger-bridge-keyring | <0.2.1 |
0.2.1 |
| npm | @metamask/eth-ledger-bridge-keyring | <0.2.2 |
0.2.2 |
Classification
- Weakness
-
- CWE-287 Improper Authentication
References
-
github.com
/MetaMask/eth-ledger-bridge-keyring/pull/14
web
-
github.com
/MetaMask/eth-ledger-bridge-keyring/commit/f32e529d13a53e55f558d903534d631846dc26ce
web
-
github.com
/MetaMask/eth-ledger-bridge-keyring/security/advisories/GHSA-vg44-fw64-cpjx
web
-
github.com
/advisories/GHSA-vg44-fw64-cpjx
advisory
-
snyk.io
/vuln/SNYK-JS-ETHLEDGERBRIDGEKEYRING-561121
web
-
npmjs.com
/advisories/1497
web
-
npmjs.com
/advisories/1498
web
Sources
- GitHub Advisory GHSA-vg44-fw64-cpjx
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.