📌 AI made finding bugs cheap, but it didn’t make responsible disclosure optional. Finding and exploiting vulnerabilities has never been easier. A few hours of prompting now does what used to take a skilled researcher weeks. Unfortunately, defenders no longer enjoy the asymmetry they relied on. Security is still a cat-and-mouse game, but with many more cats, the user suffers. Which is exactly why the process around disclosure matters more than ever. How it works, and it is not complicated: ➤ A researcher finds a bug and contacts the vendor privately. ➤ The vendor reproduces, acknowledges, and both sides agree on a timeline. 90 days is the common default, more or less depending on severity, capacity to fix... ➤ During that window both sides keep it secret while the vendor fixes and ships. ➤ Once users are protected, both sides publish. The ecosystem learns. The researcher usually gets paid. The issue now is the barrier is so low that anyone can surface a finding with no security background, and some skip straight to the audience: ❗Presenting a reproduction of an already-fixed bug as a live compromise. ❗Full disclosure of a bug that is not fixed yet. ❗"Critical vulnerability found" teasers, dripping details for engagement. Call it what it is: attention farming with someone else's risk. When the bug sits between a user and their funds, this is reckless. Especially in crypto, where there is no chargeback. But the damage doesn't require live funds to be at stake. Manufactured panic causes harm of its own, because it drives people away from self-custody, and that damages the whole ecosystem. So I have three asks: 1️⃣ For users: software and hardware have bugs, always. The single most effective thing you can do is stay updated and follow basic security hygiene. That has never mattered more than today. The time between releases and malicious actors exploiting the vulnerabilities have shrunk dramatically due to LLMs and that one can't afford to be passive and postpone security updates any more 2️⃣ For new researchers with a fresh model and a real, validated finding: welcome, we need you. Use the vendor's disclosure process. That is not bureaucracy. It is the difference between making the ecosystem safer and putting users in the crosshairs for a few likes. Remember that security communication must be accurate and proportionate. State the severity, affected versions, and fix status in the first sentence, not the tenth. 3️⃣ And to everyone building in this industry, vendors and researchers alike: let's make coordinated disclosure the norm we defend out loud, not the fine print. Reward the researchers who do it right. Refuse to amplify the ones who trade user safety for reach. This is how we win, together. Some of the actors already support the initiative. @Ledger @Trezor @FoundationHQ @AnchorWatch @_SEAL_Org and others Spread the message.

There's some FUD circulating about Ledger signers, pushed by a "smart contract security" company claiming a vulnerability in the Ledger Ethereum app. There was a bug concerning certain clear signing flows. It was found by the @DonjonLedger using their AI-powered vulnerability research suite. It was fixed and deployed two weeks ago. If you keep your Ledger apps up to date, you are protected. That's the whole story. Now the framing. What actually happened: this company reached out to our bounty program after the fix was already shipped, and did not follow responsible disclosure, they actually never discussed with the bounty program team. Then they published a thread implying the problem is unsolved. It is not. That's not security research. That's manufacturing fear for attention. Here is the uncomfortable part. AI changes the security landscape for everyone, defenders and attackers alike. The @DonjonLedger is leading on exactly this: using AI to find real bugs before they reach users. But AI-speed research only makes the ecosystem safer if the people doing it still follow basic security principles. Disclose responsibly. Verify before you publish. Don't confuse noise with a finding. An actor who skips all of that is net negative for the ecosystem, regardless of the tooling behind them. The takeaway for you is simple. Keep your Ledger signers up to date (update the FW, update the apps), keep your software up to date in general, and you benefit from the latest security work automatically. Ignore the FUD. Stay safe.

💥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.