# Ledger Connect Kit: offboarding and runtime dependencies share a security boundary Canonical: https://www.web3sec.news/blog/ledger-connect-kit-publishing Author: Raiders (https://www.web3sec.news/about) Format: postmortem Topic: Publishing & runtime code Published: 2026-11-08 Updated: 2026-11-08 Incident date: 2023-12-14 A package-publishing compromise reached applications through dynamically loaded code without changing their own repositories. ### Diagram: Trust the release path, not only the source. Protect the chain from reviewed change to the artifact receiving traffic. ![Protected source enters a least-privilege release workflow, produces a digest-identified artifact, and reaches production only after artifact verification. Untrusted pull requests use isolated checks without release credentials or write access.](https://www.web3sec.news/diagrams/software-release-trust.svg) [Full-size SVG](https://www.web3sec.news/diagrams/software-release-trust.svg) · [PNG download](https://www.web3sec.news/diagrams/software-release-trust.png) Original explanatory control model; not a reconstruction of private incident evidence. ## What Ledger reported Ledger’s 20 December 2023 report describes the 14 December Connect Kit compromise. A former employee retained npm publishing access and was phished. The attacker published malicious package versions 1.1.5, 1.1.6 and 1.1.7. Ledger said applications loaded the affected code through the Connect Kit loader at runtime, and that its own repositories and the applications’ repositories were not compromised. The report describes malicious signing requests and the role of CDN caching in propagation and cleanup. Ledger’s initial statement distinguished the Connect Kit event from compromise of Ledger hardware or Ledger Live. This retrospective follows the published reports without turning historical fixed-version advice into a current dependency recommendation. ## Two control failures meet at the consumer Our analysis: offboarding must follow release authority into external systems. An identity can lose source access yet retain the ability to publish code under a trusted namespace. The registry membership, tokens and recovery methods therefore need a direct revocation check, rather than a presumption that central account suspension reaches every external provider. For consumers, a fixed application build does not necessarily fix the code executed in the browser. Runtime loaders and mutable CDN references can introduce new code after a deployment has passed review. Map that loading behavior explicitly and decide which dependencies should be bundled, pinned or restricted. Test the deployed application’s network activity to discover dependencies absent from a simple manifest review. ## Contain both distribution and authorization When a malicious dependency is identified, determine which pages and application artifacts actually loaded it and what authority it could exercise. Disable the vulnerable integration through a trusted release path, coordinate registry and CDN remediation and verify the code served from representative locations. A fresh safe package publication does not establish that every cache or existing session immediately stopped using the malicious code. For affected users, distinguish code execution from the transactions and approvals it induced. Removing the JavaScript does not reverse a signed transfer or invalidate every token approval. Publish evidence-backed instructions through established channels and identify the exact affected period and behavior where known. Avoid asking users to sign a new recovery transaction through a flow whose integrity has not been independently restored. ## Build verification into publisher and consumer practice Publishers can rehearse offboarding with a test maintainer: remove access and confirm that publication fails through every previous path. Inspect the release artifact and require an approved build identity. Consumers can rehearse a dependency failure on staging, verifying the ability to disable the integration without disabling unrelated emergency communication or support paths. Add signing-semantic checks to the user journey for high-impact actions. The browser’s explanation should not be the only representation of the requested transaction. Keep a small operational wallet separate from treasury authority where the business permits. Completion means both the distribution path and the induced authorization risk have been reviewed, rather than only upgrading one dependency and closing the incident ticket. ## Controls to take away - Repository access and registry access are different authorities. - Runtime loaders can change code after application review. - Removing malicious code does not reverse authorizations it induced. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Verify external publishing access during offboarding. - [ ] Inventory runtime-loaded code in production pages. - [ ] Test integration disablement and CDN propagation. - [ ] Assess signed transactions and approvals separately from script removal. - [ ] Rehearse publication denial for a removed test maintainer. ## Sources & further reading - [Ledger: security incident report, 20 December 2023](https://www.ledger.com/blog/security-incident-report) - [Ledger: initial CEO statement, 14 December 2023](https://www.ledger.com/blog/a-letter-from-ledger-chairman-ceo-pascal-gauthier-regarding-ledger-connect-kit-exploit) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)