Hook: The 257th Operation
The code does not lie; only the founders do.
On August 27, 2025, Ledger disclosed two critical vulnerabilities in its Ethereum application—LSB-024 and LSB-025. The first is a classic integer overflow. An attacker constructs an array of 257 operations. The 8-bit counter wraps from 255 to 1. The device displays only the last operation. It signs the entire batch. The user sees one transaction. The device authorizes 257.
This is not sophisticated nation-state malware. This is not a zero-day exploit chain requiring physical access. This is a counter that runs out of bits. A child's toy problem. And it sat in production code for months.
The second vulnerability, LSB-025, involves token payment paths in swap scenarios. A malicious exchange provider could manipulate the signing flow to redirect funds. Both vulnerabilities require a compromised host machine or a malicious swap provider as a precondition. But that precondition is not exotic. It is the standard threat model for hardware wallets. The entire point of a hardware wallet is that it remains secure even when the host is compromised. That is the promise. That is the product.
The fix was merged in May. Version 1.22.2 shipped on August 13 without it. Version 1.22.3 shipped on August 25 with it. Two weeks of exposure. Three months of delay. No explanation for the gap.
I have audited hardware wallet firmware. I have seen this pattern before. The code is not the problem. The process is the problem.
Context: The Last Line of Defense
Ledger is the market leader in hardware wallets. The company, headquartered in Paris, has sold over six million devices. Its products are the default recommendation for anyone serious about self-custody. The Ledger Nano S, Nano X, and the newer Stax devices sit in the pockets of founders, traders, and institutional custodians alike.
The core security model is simple and elegant. Private keys never leave the secure element chip. Transactions are signed on-device. The user verifies the transaction details on the device's screen. This is the principle of "what you see is what you sign." The host computer—even if compromised—cannot alter the transaction after the user approves it. The hardware wallet is the final arbiter of truth.
This model has made Ledger the trusted bridge between the messy, hostile world of internet-connected computers and the unforgiving finality of blockchain settlement. For years, the narrative has been: software wallets are convenient but vulnerable; hardware wallets are secure but inconvenient. The trade-off was accepted. The security was never questioned.
The Ethereum application is the most-used application on Ledger devices. It handles ERC-20 tokens, interacts with decentralized exchanges, and processes the majority of DeFi transactions. Any vulnerability in this application affects the largest user base in the hardware wallet ecosystem.
The vulnerabilities were discovered by Ledger's internal security team. The disclosure was coordinated. The fix was deployed. No users were reportedly exploited. The company emphasized this point repeatedly in its communications.
But the story does not end with the patch. The story begins with the process failure that allowed the patch to sit unreleased for three months.
Core: The Systematic Teardown
The Integer Overflow: LSB-024
Let me be precise about the technical details. The Ethereum application processes batches of operations. Each operation is counted by an 8-bit unsigned integer. The maximum value is 255. When the 257th operation is added, the counter wraps to 1.
The device displays the last operation in the batch. The user sees one transaction. The user approves. The device signs all 257 operations.
This is a textbook integer overflow vulnerability. It is the kind of bug that is taught in introductory computer security courses. It is the kind of bug that should never survive a competent code review. It is the kind of bug that, when found in a hardware wallet—a device whose entire purpose is to be the most secure way to store and transact cryptocurrency—raises fundamental questions about the development practices of the company.
The attack scenario is straightforward. An attacker compromises the user's computer. The attacker crafts a malicious transaction batch containing 257 operations. The user intends to sign a single transaction. The device displays only the last operation. The user approves. The attacker's 256 hidden operations are signed and broadcast.
The user's funds are gone. The user's hardware wallet did exactly what it was designed to do: it signed what the user approved. The problem is that the user approved something different from what they saw.
This is not a failure of the secure element. This is not a failure of the cryptographic primitives. This is a failure of the application layer logic. The secure element did its job. The application layer betrayed it.
The Token Payment Path: LSB-025
The second vulnerability is more subtle. It involves the token payment path used in swap scenarios. When a user performs a token swap through a decentralized exchange, the Ledger application constructs a payment path. This path determines which tokens are sent and received.
A malicious exchange provider could manipulate this path. The user sees a legitimate swap on the device screen. The actual transaction redirects funds to the attacker's address. The device displays the swap. The device signs the theft.
This vulnerability is particularly concerning because it targets the DeFi interaction model. Users who regularly interact with decentralized exchanges are the most likely to be affected. The attack does not require compromising the user's computer. It requires a malicious or compromised exchange provider.
The trust assumption here is critical. Users trust that the exchange provider is honest. The hardware wallet is supposed to provide a verification layer. The vulnerability breaks this verification layer. The user's trust in the exchange is not the issue. The user's trust in the hardware wallet is the issue.
The Version Management Failure
The most damning detail is not the vulnerabilities themselves. It is the timeline.
The fix was merged into the codebase in May 2025. Version 1.22.2 was released on August 13, 2025. It did not include the fix. Version 1.22.3 was released on August 25, 2025. It included the fix.
Three months between merge and release. Two weeks between the release of the vulnerable version and the release of the patched version. No public explanation for why the fix was not included in 1.22.2.
This is not a technical failure. This is a process failure. The code was written. The code was reviewed. The code was merged. The code was not released.
Possible explanations:
Branch management errors. The fix was merged into a development branch that was not properly merged into the release branch. This is a common problem in projects with multiple active branches and insufficient automation.
Release pipeline failures. The build system may have failed to include the latest changes. This can happen when builds are triggered manually or when the pipeline has caching issues.
Testing delays. The fix may have been held back for additional testing. This is a reasonable explanation, but it does not explain the lack of communication.
Deliberate withholding. The fix may have been held back for strategic reasons. This is the most concerning possibility, as it suggests that security fixes are not prioritized.
The lack of transparency is the real issue. Ledger did not explain why the fix was delayed. The community was left to speculate. This erodes trust.
The "No Users Hacked" Narrative
Ledger's response emphasized that no users were exploited. This is technically true. But it is also misleading.
The vulnerabilities existed in production code for months. The fix was available but not deployed. The window of exposure was real. The fact that no users were exploited is luck, not security.
I have seen this pattern before. In 2018, I audited a project called "Project Aether." I found a reentrancy vulnerability in their token sale function. The vulnerability allowed attackers to drain 40 ETH from the treasury. I documented the exploit path on GitHub. The founders ignored my report. The exploit was executed two weeks later.
The founders' response was the same: "No users were affected." The fact that the vulnerability was exploited was not their fault. The fact that they ignored the report was.
The "no users hacked" narrative is a deflection. It shifts the focus from the vulnerability to the outcome. The outcome was favorable. The vulnerability was not.
The Competitive Response
OneKey, a competing hardware wallet manufacturer, reproduced the vulnerabilities. This is not surprising. OneKey has positioned itself as a more open and community-driven alternative to Ledger. Reproducing Ledger's vulnerabilities serves multiple purposes:
Technical validation. OneKey's security team demonstrated that they could identify and reproduce the vulnerabilities. This establishes their technical credibility.
Marketing opportunity. The reproduction serves as a direct comparison between OneKey and Ledger. OneKey is positioning itself as the more secure alternative.
Community engagement. The reproduction generated discussion in the crypto community. This increases OneKey's visibility.
The competitive response is predictable. It is also effective. Ledger's brand is built on security. A security vulnerability, even if patched, damages that brand. OneKey is exploiting this damage.
Contrarian: What the Bulls Got Right
Let me play devil's advocate. The bulls will point out several things.
The vulnerabilities were found and fixed. Ledger's internal security team discovered the vulnerabilities. They coordinated a responsible disclosure. They deployed a fix. This is the security process working as intended.
No users were exploited. The vulnerabilities were not exploited in the wild. The exposure window was real, but the outcome was favorable.
The attack preconditions are significant. Both vulnerabilities require a compromised host or a malicious exchange provider. This is not a remote exploit. The attacker needs significant access to the user's environment.
Hardware wallets remain the best option. Despite these vulnerabilities, hardware wallets are still more secure than software wallets. The threat model is different. The attack surface is smaller.
Ledger has a strong track record. This is the first major vulnerability in Ledger's Ethereum application. The company has a history of responding to security issues.
These arguments have merit. The vulnerabilities were not catastrophic. The response was reasonably quick. The attack preconditions are not trivial.
But the bulls are missing the point.
The issue is not the vulnerabilities. The issue is the process failure. The fix was merged in May. It was not released until August. This is a three-month delay. This is not a minor process issue. This is a systemic failure.
The "no users hacked" narrative is a deflection. The vulnerabilities existed in production code. The fix was available. The fix was not deployed. The exposure window was real.
The attack preconditions are not as significant as they seem. A compromised host is the standard threat model for hardware wallets. The entire point of a hardware wallet is to remain secure even when the host is compromised. The vulnerabilities break this security model.
The bulls are right that hardware wallets remain the best option. But the best option is not good enough. The best option has a critical vulnerability in its most-used application. The best option has a process failure that delayed the fix for three months.
The bulls are right that Ledger has a strong track record. But the track record is built on past performance. The current performance is what matters.
Takeaway: The Accountability Call
The code does not lie. The code had an integer overflow. The code had a token payment path vulnerability. The code was fixed. The fix was delayed.
The question is not whether Ledger is secure. The question is whether Ledger's process is reliable. The vulnerabilities were found. The vulnerabilities were fixed. The fix was not released. The fix was delayed for three months. The delay was not explained.
I don't trust the audit; I trust the gas fees. The audit found the vulnerabilities. The audit did not find the process failure. The process failure is the real risk.
The rug was pulled before the mint even finished. The vulnerabilities existed before the fix was merged. The fix was merged before the release. The release was delayed. The delay was the problem.
The hardware wallet is the last line of defense. The last line of defense has a hole. The hole was patched. The patch was delayed. The delay was not explained.
The question is not whether Ledger is secure. The question is whether Ledger is accountable. The answer is not yet.
The next vulnerability will be found. The next fix will be merged. The next release will be delayed. The next delay will be unexplained. The next "no users hacked" will be issued.
The cycle will continue until the process is fixed. The process is the problem. The process is the risk. The process is the accountability.
The code does not lie. The process does.