# GHSA-vg44-fw64-cpjx: Incorrect Account Used for Signing

> Incorrect account selection during signing may cause transactions to be signed by the wrong key, requiring users to upgrade the library.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Not stated
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 24 Mar 2020

## What is GHSA-vg44-fw64-cpjx?

GHSA-vg44-fw64-cpjx is a vulnerability in @metamask/eth-ledger-bridge-keyring, published on 24 Mar 2020. 

### Official description

### 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)

## Which versions are affected by GHSA-vg44-fw64-cpjx?

4 open source packages ship an affected version, including @metamask/eth-ledger-bridge-keyring and eth-ledger-bridge-keyring.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `@metamask/eth-ledger-bridge-keyring` | npm | All versions | 0.2.2 |
| `@metamask/eth-ledger-bridge-keyring` | npm | All versions | 0.2.2 |
| `eth-ledger-bridge-keyring` | npm | All versions | 0.2.1 |
| `eth-ledger-bridge-keyring` | npm | All versions | 0.2.1 |

## How do I fix GHSA-vg44-fw64-cpjx?

Upgrade @metamask/eth-ledger-bridge-keyring to 0.2.2 or later.

## Is GHSA-vg44-fw64-cpjx being exploited?

There is no known exploitation of GHSA-vg44-fw64-cpjx in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-vg44-fw64-cpjx and fix it if it is affected.

What it is: GHSA-vg44-fw64-cpjx is a vulnerability in @metamask/eth-ledger-bridge-keyring, published on 24 Mar 2020. 
Exploitation: There is no known exploitation of GHSA-vg44-fw64-cpjx in the wild and no public exploit code.

Affected packages and fixed versions:
- @metamask/eth-ledger-bridge-keyring (npm): affected all versions; fixed in 0.2.2
- @metamask/eth-ledger-bridge-keyring (npm): affected all versions; fixed in 0.2.2
- eth-ledger-bridge-keyring (npm): affected all versions; fixed in 0.2.1
- eth-ledger-bridge-keyring (npm): affected all versions; fixed in 0.2.1

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-vg44-fw64-cpjx/ (Markdown: https://insights.sbomify.com/GHSA-vg44-fw64-cpjx/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-vg44-fw64-cpjx

---
From sbomify Insights: https://insights.sbomify.com/GHSA-vg44-fw64-cpjx/
Summaries are generated and may contain mistakes; the official description above is the record.