GHSA-vg44-fw64-cpjx
Incorrect Account Used for Signing
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 hello@metamask.io
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- None
- User interaction
- Required
What an attacker can affect
- Confidentiality
- High
- Integrity
- High
- Availability
- High
What each source reports
GitHub Advisories Score used 7.5
Incorrect Account Used for Signing
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 hello@metamask.io
- Record
GHSA-vg44-fw64-cpjx- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H - Weakness
- CWE-287
- Updated
- 2026-11-02
OSV 7.5
Incorrect Account Used for Signing
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 hello@metamask.io
- Record
GHSA-vg44-fw64-cpjx- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H - Weakness
- CWE-287
- Updated
- 2026-11-02
Affected packages
| Package | Affected | Fixed |
|---|---|---|
eth-ledger-bridge-keyringnpm | before 0.2.1 | 0.2.1 |
@metamask/eth-ledger-bridge-keyringnpm | before 0.2.2 | 0.2.2 |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | GitHub Advisories, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
GHSA-vg44-fw64-cpjx is a high vulnerability (CVSS 7.5) in eth-ledger-bridge-keyring, published March 24, 2020. No source lists public exploit code. Fixed in eth-ledger-bridge-keyring 0.2.1.
References
github.com/MetaMask/eth-ledger-bridge-keyring/security/advisories/GHSA-vg44-fw64-cpjx
github.com/MetaMask/eth-ledger-bridge-keyring/pull/14
github.com/MetaMask/eth-ledger-bridge-keyring/commit/f32e529d13a53e55f558d903534d631846dc26ce
github.com/advisories/GHSA-vg44-fw64-cpjx
npmjs.com/advisories/1497
npmjs.com/advisories/1498
snyk.io/vuln/SNYK-JS-ETHLEDGERBRIDGEKEYRING-561121