Every CVESearch/Get API key

GHSA-vg44-fw64-cpjx

Incorrect Account Used for Signing

7.5 HighFix available

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:

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 used7.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:

Record
GHSA-vg44-fw64-cpjx
CVSS 3.1
7.5 HighCVSS: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
OSV7.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:

Record
GHSA-vg44-fw64-cpjx
CVSS 3.1
7.5 HighCVSS: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

Affected packages
PackageAffectedFixed
eth-ledger-bridge-keyring
npm
before 0.2.1
0.2.1
@metamask/eth-ledger-bridge-keyring
npm
before 0.2.2
0.2.2

History

History
RecordedChangedSources
first indexedGitHub 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

MoveEnter Open