Ledger Security Bulletin 014

04 August 2020: Path derivation too permissive in Bitcoin derivative apps

05 August 2020: This security bulletin was updated to mention the publication of a new version of the Bitcoin app, add a disclosure timeline section, rephrase a sentence in the Remediation section and give a link to the patch.

Please read our support article if you aren’t interested in technical details.


The Ledger Nano S and Nano X are Hierarchical Deterministic (HD) wallets, meaning that they can derive different cryptographic secrets from a single seed. As written in the Threat Model, apps can derive keys on their own HD path only, which ensures that cryptocurrency apps cannot use keys from each other. For instance, the Zcoin app cannot derive keys on the Dogecoin derivation path (m/44'/3'/), since its own derivation path is m/44'/128'/.

This path restriction was not enforced for the Bitcoin app and most of its derivatives, allowing a Bitcoin derivative (eg. Litecoin) to derive public keys or sign Bitcoin transactions.

Technical Analysis

When installing an app on the Ledger Nano S/X, a list of allowed paths is provided. In the source code, it is usually specified in the Makefile of the app. For instance, the Monero app is allowed to use the path m/44'/128' (2147483692/2147483776) thanks to the --path parameter:

APP_LOAD_PARAMS= --path "2147483692/2147483776" --curve secp256k1 $(COMMON_LOAD_PARAMS) --appFlags 0x240
APPNAME = "Monero"

This parameter is enforced by the OS when any app retrieves a key used for public key derivation and transaction signature (using syscall os_perso_derive_node_bip32).

This parameter is however empty in the Bitcoin app and in its derivatives (at the exception of Qtum). The following table presents the coins affected by this lack of restriction:

CoinAffected (signature)BIP 44 coin typeForked coin
Bitcoin TestnetYes1No
Bitcoin CashNo (different signature format)145Yes (BTC)
Bitcoin GoldNo (different signature format)156Yes (BTC)
ZCashNo (different signature format)133No
HorizenNo (different signature format)258No
KomodoNo (different signature format)141No
StratisYes (against Peercoin family)105No
PeercoinYes (against Peercoin family)6No
QtumNo (lock already in place)2301No
Bitcoin PrivateNo (different signature format)183Yes (BTC)
GamecreditsYes (but to be removed)-No

Enforcing the restriction to one or multiple paths for each coin type is actually a tough topic because:

  • Some third party software wallets use incorrect derivation paths. This is a specific concern for older coins using third party wallets based on Electrum (Dogecoin, Litecoin, Dash, etc.)
  • Some BTC forks use the same derivation path as BTC. If we prevent these forks from using the BTC derivation path, this would simply prevent users from using the Ledger Nano S/X with these forks.

For completeness, the following paths are standard for all Bitcoin variants:

  • BIP 44 (44'/type')
  • BIP 49 if supporting Segwit (49'/type')
  • BIP 84 if supporting Native Segwit (84'/type')

We can assume that by default all coins support those 3 paths for their type. Bitcoin being in use for some time, additional non standard paths have popped up:

  • BIP 45 (45'/type') for Copay multisignatures
  • “GA’/” (18941'/) - GreenAddress proprietary for the shared multisignature address
  • Users can also sign on randomly selected paths with PSBT (Partially Signed Bitcoin Transaction from BIP 174)


Blocking unusual paths from Bitcoin derivatives apps could fix the issue, but it leads to situations where user funds would be locked and users unable to spend their funds anymore. We thus chose to enforce a path lock in the Bitcoin app itself. If a Bitcoin derivative app tries to perform a derivation on an unusual path, a warning is displayed to the user.

In order to allow users to continue to use their Ledger Nano S/X seamlessly with any third party software wallet, this fix doesn’t enforce this verification from the OS though, which means that the --path parameter is still empty. We might add an exhaustive path list in the future if we are sure it doesn’t break any other wallets.

The vulnerability is fixed from version 1.4.6 of the Bitcoin app (being used as a library by the other apps) thanks to the commit 3f85053e.

Disclosure timeline

2020-05-02monokh sent to bounty@ledger.fr a vulnerability report about app isolation bypass.
2020-05-04Ledger’s security team acknowledged the reception and starts investigating.
2020-05-10 to 2020-05-13monokh and the Ledger security team discussed the issue. Ledger’s security team started coordinating other Ledger teams to fix it. A disclosure date is being set to 90 days (that is, 2020-08-02).
2020-08-0290 days deadline reached. Ledger started the test and release process for the fixed Bitcoin app.
2020-08-04monokh published the details of the vulnerability, without informing Ledger’s security team beforehand through bounty@ledger.fr.
2020-08-05Ledger updated the Bitcoin app.

In this case, we regret not having respected the disclosure deadline, leading the security researcher to publish a blogpost on his website before a fix was made available for the users.

Besides other issues being handled at the same time, internal discussions to find an appropriate fix and coordination with other engineering teams took longer than expected. This led to a new version of the Bitcoin app being published after the scheduled deadline (that was set to 90 days after the vulnerability report).

Miscommunication didn’t help solving that issue sooner. The reporter sent Twitter DM messages that were missed by most of the security engineers. Indeed, the bounty@ledger.fr email address is the only way to reach the whole security team.


We would like to thank the security researcher monokh who reported the vulnerability through our bug bounty program.


  1. Threat Model - App Isolation
  2. app-monero/Makefile
  3. app-bitcoin/Makefile
  4. Applications of HD Trees
  5. GitHub - Merge pull request from GHSA-7gvm-55wh-x2c4