💥One Check, One Laser, Every Card: The Tangem Immutability Trap. The @DonjonLedger just published research worth stating plainly. With a single laser pulse the Ledger Donjon team faults one conditional check in the firmware of a Tangem card and resets the password to a value of its choosing. No existing password, backup card, or recovery feature needed. Once reset, the attacker is able to sign anything and can potentially drain the user’s wallet. To be precise about the threat model: this attack requires physical possession of the card, invasive chip opening, lab-grade fault-injection equipment, our own setup costs roughly $250,000, and genuine technical expertise. That puts it well beyond the reach of an opportunistic thief, but comfortably within the capabilities of a serious lab. Both things can be true at the same time. Why one pulse is enough: the recovery path depends on a single yes/no check, “is this card in recovery state?”, and a pulse is simply a precisely timed electrical disturbance designed to make the chip misread that decision at the critical moment. Because there is no redundant check and no penalty for repeated SetPin attempts, one successful disturbance is enough. The chip’s countermeasures are formidable, but they cannot protect the one bit the firmware chose to trust. The uncomfortable part: it cannot be patched. Tangem cards have no firmware update mechanism. The vulnerability was disclosed on February 10th, 2026. There is no fix coming, because there is no channel to deliver one. Tangem presents immutable firmware as a security feature. Call it what it is: a trade-off. "We cannot change the firmware" is a strong story right up until the firmware is wrong. Then the same property that protected you guarantees you can never be protected again. This research did not create that reality. It made it visible. What a user can do, since there is no patch: this attack requires physical possession of the card and invasive lab work, so it cannot be done covertly. The practical risk is a lost or stolen card in the hands of a capable attacker. If the card stays in your possession, there is no reason to assume compromise. If you have doubt, or if your threat model requires a higher level of assurance, treat the funds as compromised and move them to a new secure set up. This was published in line with Ledger Donjon’s responsible disclosure process. When a vulnerability cannot be patched, the next responsibility is to inform users clearly and widely, so they can make their own informed decisions, especially here where the vulnerability can not be exploited remotely. The bigger lesson is not about one product. Security is never static, and systems should be designed with human error and future failure in mind. You should not have to blindly trust that yesterday’s assumptions still hold. You should be able to verify, adapt, and recover when they do not. Design for the day you are wrong, because eventually, you will be. Full write-up from Baptistin Boilot, Ledger Donjon. Stay safe. Stay honest about your trust assumptions.

🚨Taiko drained for ~$1.7M. Root cause: a private key committed to a public GitHub repo. enclave-key.pem, the RSA key used to sign all of Taiko's SGX enclaves, sat in the public taikoxyz/raiko repo. That key is the whole trust model. The attacker derived MrSigner from the public key, signed their own malicious enclave with the leaked key, and registered as a trusted prover. The L1 contracts trust any enclave whose MrSigner matches. It matched. From there: forged SGX attestations on fake L2 blocks, processMessage() sets the message to RETRIABLE, retryMessage() does zero proof verification, funds leave. No key theft. No social engineering. No SGX exploit. Just a .pem in a public repo. Good opportunity to recall that SGX is broken. But here, nobody even had to break it. It's just yet another key management failure. The whole system was only ever as strong as the secrecy of one RSA key, and that secrecy depended on a human not running git add . on the wrong folder. AI greps every commit of every public repo at machine speed. Assume that is already happening. The only real exit: a verifier that checks a succinct validity proof of the L2 state transition. It trusts no enclave, no MrSigner, no operator discipline. It checks the math. In that world this exact attack becomes cryptographically impossible rather than operationally unlikely, because there is no privileged key whose leak forges the entire system. There is just a proof. Stay safe.

🔔Post-Quantum Signatures: NIST's Second Wave In August 2024, NIST finalized its first PQC standards: ML-KEM (key exchange), ML-DSA, and SLH-DSA (signatures). A third signature, Falcon (FN-DSA, FIPS 206), is still in draft. Last week, NIST announced the nine candidates advancing to Round 3 of a parallel competition aimed at additional signature schemes, explicitly chosen to fill the gaps left by the first wave. Each of the standardized signatures comes with sharp trade-offs. None of them is naturally suited to threshold signing, and all have signatures that are large compared to ECDSA's 64 bytes. ➡️ SLH-DSA (SPHINCS+, hash-based) The most conservative choice: its security rests only on the collision resistance of a hash function. The price is enormous signatures (7–50 KB !!!). It is the safest pick for very long-lived signatures (firmware, archival, some blockchains such as QRL). ➡️ML-DSA (Dilithium, lattice-based). Compact and fast, while elegant, is younger than hash-based assumptions. It is becoming the default for TLS, PKI, and most non-blockchain ecosystems (~2.4 KB signatures). ➡️Falcon (FN-DSA, lattice-based). The smallest of the three (~666 B at NIST-I), which is why Algorand and Solana selected it. Its drawback: signing relies on floating-point arithmetic, making error-prone and side-channel-resistant/ constant-time implementations notoriously hard. Its FIPS 206 standard is still in draft. 🔍Most blockchains are leaning towards customized shorter versions of SLH-DSA. NIST is organizing a second wave of standardization. The goal is twofold: shrink signature sizes and diversify the underlying mathematics so a single cryptanalysis breakthrough cannot break everything. The nine Round 3 finalists span five families: 🔸 Isogeny: SQIsign 🔸 Lattice: HAWK 🔸 MPC-in-the-Head: MQOM, SDitH 🔸 Multivariate: MAYO, QR-UOV, SNOVA, UOV 🔸 Symmetric-based: FAEST Notably, no code-based scheme survived. Both Round 2 candidates were eliminated: LESS and CROSS were dropped because of 2 attacks 👉 Two candidates worth watching ⏩ SQIsign produces the smallest known post-quantum signatures by a wide margin: from 148B to 292B (depending on the level of security), with sub-130-byte public keys. That is the only PQC signature scheme today that even approaches the bandwidth profile of ECDSA, extremely attractive for blockchains, certificates, and firmware. The catch: isogeny-based cryptography is still young, signing is mathematically intricate, and side-channel hardening is an active research area. ⏩HAWK is essentially "Falcon without the floating-point." It is a lattice hash-and-sign scheme producing 555 B signatures at NIST-I (smaller than Falcon's 666 B) and can be implemented purely with integer arithmetic, a major engineering win. NIST has said the Round 3 review will last roughly two years and that any multivariate winners are unlikely to be standardized without yet another round. Realistically, the earliest a new signature standard will land alongside ML-DSA and SLH-DSA is 2028. The urgency to migrate has grown sharply, yet the current standards still have significant drawbacks, and this last-minute selection round, while necessary, collides head-on with the migration timeline.

This morning, THORChain was drained of roughly $10.8m Node operators have freezed the network for nearly 13 hours. The full analysis isn't out yet, but according to @jpthor, this could be a MPC exploit. ECDSA and TSS is hard. THORChain's vaults rely on TSS, a flavor of MPC where a quorum of nodes jointly produces a signature without ever reconstructing the private key. Clean for Schnorr or EdDSA; painful for ECDSA, which Bitcoin and Ethereum require. That's why we saw plenty of protocol attempts (Lindell17, GG18, GG20, CMP, CGGMP21, DKLS, KU23...), each patching flaws in the previous one. GG20 has a track record. THORChain's TSS uses GG20, on a fork of Binance's tss-lib. GG20 has shipped two well-publicized critical bugs: CVE-2023-33241 and TSSHOCK. CGGMP21, now cggmp24, are the latest protocols, but GG20 is still widely deployed. I often hear a misconception when I hear about MPC setup: "The key is split across many nodes, so any single co-signer doesn't really matter". In every published GG18/GG20 attack, one malicious or compromised co-signer is enough to extract everyone else's shard and reconstruct the full key. AI changes the threat model. Compromising a full software node, complex Go stack, exposed P2P, custom signing daemons, a churn protocol that admits new participants on a schedule, has always been difficult and acted as a barrier. With LLM-driven vulnerability discovery and exploit synthesis, the bar to compromise one of N validators is dropping fast. Here, it's a plausible TSSHOCK-style playbook: - compromise one operator - wait for it to churn into an active Asgard vault - send malformed proofs during keygen or signing - reconstruct the key offline - sweep in a single transaction It's unclear yet if the attacker used a known-unpatched GG20 weakness, or a fresh cryptographic flaw. But, in all cases, MPC and TSS are not a substitute for hardening every co-signer. They sit on top of co-signers that must each be treated as critical infrastructure, hardware-isolated enclaves, minimally exposed, continuously audited, and running protocol with security proofs. While the investigation progresses, be careful in your interactions onchain. These TSS setup are used in various protocols.

So proud of the @ledger team for making clear signing on Ethereum a reality. They built in the open, brought together stakeholders across the ecosystem, and created the 7730 standard as a public good for Ethereum.

🚨 A new NPM supply chain attack is currently underway, specifically targeting the AI ecosystem, including packages related to Mistral AI, OpenSearch, Guardrails AI, and others. It hooks into Claude and VS Code environments to steal user credentials, including GitHub tokens. What makes this attack especially sneaky is its persistence mechanism. It deploys scripts that monitor whether the compromised GitHub token gets revoked. The moment revocation is detected, the malware retaliates by wiping the user’s home directory. This punitive behavior both disrupts remediation efforts and buys attackers more time to deepen the compromise. We are entering a new era where attackers are becoming dramatically more capable, and defending against them is growing more difficult every day.

Finding vulnerabilities has never been easier, and code generation is now accessible to almost anyone. The result is predictable: out of 5,000 vibe-coded apps that were analysed, 40% end up leaking sensitive corporate or personal dat

BIP-361 ( in one sentence: it tackles the incentive problem of the Post-Quantum migration, how you actually get holders to move, without trying to settle the technical parameters of it (which signature scheme, which output type). Those are deferred to other BIPs. It defines three phases: - Phase A (~3 years after activation): new outputs to ECDSA/Schnorr addresses are forbidden. You can still spend from legacy, but only into post-quantum scripts. The vulnerable surface stops growing. - Phase B (2 years after Phase A): a flag-day that makes ECDSA/Schnorr spends invalid altogether. Unmigrated UTXOs are effectively frozen. - Phase C (TBD): a recovery path for legitimate owners of those frozen funds. The A → B logic is clean: cap the exposure, then sunset it. Phase C is where it gets interesting. In a post-quantum world, "knowing the private key" is no longer proof of ownership, a CRQC can derive it from the public key just as well as the legitimate owner. Recovery therefore needs a secret quantum computers cannot reach. The elegant idea hinted at in the BIP is a zero-knowledge proof of BIP-39 seed phrase ownership. The BIP-39 → BIP-32 derivation is a one-way hash chain, quantum-secure: a CRQC can invert ECDSA, but it cannot invert the seed derivation. The owner proves "I know the seed behind this UTXO" without revealing it; the chain verifies the proof and releases the funds. This ZK would have to be Quantum resistant to avoid arbirary proof forgery (STARK is our friend). This is doubly attractive: it solves recovery, and it forces Bitcoin to natively verify ZK proofs, unlocking a much broader design space (validity-rollup settlement, succinct proofs, privacy upgrades). There's a catch, though, that the BIP itself acknowledges. BIP-39 was only introduced in 2013, and BIP-32 in late 2012. UTXOs created before then, including most P2PK coins, whose public keys are already exposed on-chain, were generated from raw, individually managed private keys. There is no seed phrase to prove. For these coins, ZK recovery is structurally impossible, and the BIP-361 authors explicitly fall back on an Hourglass-style mechanism (rate-limited spending) to handle them. So BIP-361 is, in my view, the right scaffolding. But Phase C is where the real political and ethical questions of the migration actually live, and ZK-of-seed only solves the easier half.

Directionally, I agree with this take, but it lacks urgency. We don't know when, or even if, a CRQC will arrive. That's not the point. Cryptography exists to provide trust in our systems, and once that trust erodes, it has to be rebuilt. Rebuilding takes time. We shouldn't wait for a CRQC to act. The whole world is going to migrate, and NIST has already laid out a timeline. For Bitcoin, the problem is harder: we need social consensus. As a community, we need to agree on a migration plan. What's the new signature scheme? Do we deprecate ECDSA and Schnorr? What's the impact on block size and throughput? Soft fork or hard fork? What's the activation timeline? And critically: what happens to coins that don't migrate, including the millions of BTC sitting in addresses with exposed public keys, or Satoshi's? These are concrete questions we need to answer before the FUD builds and trust erodes. The main question shouldn't be "Is there a quantum computer capable of breaking Bitcoin out there?" Framing the debate solely through that lens is a recipe for disaster.

Drift Protocol, one of the leading perpetual DEXs on Solana, has been hacked for approximately $213M. This makes it the biggest hack of 2026 so far, and one of the largest ever on the Solana blockchain, right behind the Wormhole Bridge exploit of 2022. The full details of the attack are still unfolding, but from what I understand so far, the multisig controlling the protocol was compromised, potentially days or even weeks before the funds were actually drained. Either the attackers directly stole enough private keys to meet the multisig threshold, or, more likely, they compromised several machines belonging to multisig signers and tricked the operators into approving a malicious transaction. The signers may have believed they were signing a legitimate operation while unknowingly authorizing the drain. This modus operandi is similar to the Bybit hack last year, widely attributed to DPRK-linked actors. The pattern is becoming familiar: patient, sophisticated supply-chain-level compromise targeting the human and operational layer, not the smart contracts themselves. This is yet another wake-up call for the industry. We need to collectively raise the bar on security: - Better detection mechanisms at the network and endpoint level to catch compromised environments before they can be weaponized. - Secure key management with proper governance, hardware-backed signing, operational procedures that assume individual machines can be compromised. - Clear signing: ensuring that signers always have full, human-readable visibility into what they are actually approving. Ultimately, security is not just about code audits. It's about giving operators and users the right information at the right time, so they can make informed decisions about what they sign. Stay safe.