Loading story…
Researchers demonstrated that a Java web application using a fixed AES-GCM nonce for every encryption under the same key could be subverted despite authentication-tag validation. The application encrypted predictable sequential note identifiers and reused the AES key value, YELLOW_SUBMARINE, as its GCM nonce, allowing an attacker to collect ciphertexts produced with the same nonce and recover candidate GCM authentication subkeys.
Using those values, the proof of concept generated a valid authentication tag for an attacker-chosen ciphertext, forged an encrypted note identifier, and retrieved another user’s note. AES-GCM requires a unique nonce for every operation using a given key; nonce reuse can both enable tag forgery and reveal XOR relationships between plaintexts. Organizations should ensure nonces are generated uniquely per key, are never derived as fixed application constants, and rotate affected keys where reuse may have occurred.
See affected versions and whether adversaries are exploiting it.
1 event from the most recent confirmed update back to the earliest known activity.
A demonstrated Java pastebin-style application reused the AES key bytes as a fixed AES-GCM nonce for every note-ID encryption. Using two ciphertexts, the proof of concept recovered candidate GHASH authentication subkeys, forged a valid ciphertext and tag for a chosen note identifier, and retrieved another user's note despite tag validation.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A critical flaw tracked as **`CVE-2026-59099`** was disclosed in **Apereo CAS**, the open-source single sign-on platform, affecting versions **7.3.0 through 8.0.0-RC5**. The bug stems from **AES-GCM nonce reuse** caused by a fixed all-zero IV being used with the same encryption key for the life of the server, allowing an unauthenticated remote attacker to collect client-side webflow execution tokens from the login page and use known-plaintext techniques to decrypt webflow conversation state. The issue can expose sensitive session, identity, and application data, and was rated **critical** with **CVSS 4.0 9.3** and **CVSS 3.1 9.1**. The disclosure highlights how cryptographic implementation mistakes can turn protected traffic or tokens into recoverable plaintext, echoing earlier SSL/TLS weaknesses such as attacks against **RC4** that similarly enabled partial plaintext recovery from encrypted sessions. Apereo was notified on June 16, fixed the issue on June 17, and released patched versions on June 18; affected organizations were urged to upgrade to **`8.0.0-RC6`** or the relevant patch release and to rotate signing and encryption keys if they had operated vulnerable deployments.
Jul 12, 2026
Researchers showed that **ECDSA implementations can fail catastrophically when nonce handling or cryptographic execution leaks even tiny amounts of information**. The *LadderLeak* paper demonstrated private-key recovery from less than one bit of nonce leakage by exploiting side-channel weakness in ECDSA implementations that use the Montgomery ladder, and reported that several OpenSSL versions were vulnerable. The attack combined probabilistic leakage of the nonce’s most significant bit with improved Hidden Number Problem techniques to recover keys on curves including `sect163r1` and `NIST P-192`. Related reporting highlighted broader implementation risk across hardware and software cryptography stacks, including surveys of **deterministic ECDSA per `RFC6979`** in open-source libraries such as **Mbed TLS, GnuTLS, and OpenSSL**, checks for RFC6979 support in smart-card and HSM environments, and a separate report of **memory corruption in the Java Card Runtime Environment (JCRE)** that could affect unpatchable HSM devices and expose private keys. Together, the references show that weak nonce generation, side-channel leakage, and hardware runtime flaws can all undermine ECDSA key protection even when standard cryptographic algorithms are used.
Aug 16, 2026
Multiple reports and research references describe Bitcoin wallet compromise scenarios in which weak, reused, or low-entropy ECDSA nonces allow attackers to recover private keys from public signatures. Several sources tie the risk to the so-called **Phantom Curve** and **Dark Skippy** attack patterns, claiming that malicious firmware or flawed random-number generation in hardware and software wallets can leak enough signing material for key recovery after as few as two transactions. Related writeups also connect the issue to broader entropy failures, including alleged hardware-wallet weaknesses such as `CVE-2025-27840`, and to historical examples like the PlayStation 3 signing flaw, Android OpenSSL wallet compromises, and weak web-wallet RNG implementations. The references also promote tools such as **KeySilentLeak** and other blockchain-scanning projects that purportedly analyze Bitcoin signatures for nonce bias, reuse, or reduced entropy and then apply methods including Pollard’s Kangaroo, lattice techniques, and other discrete-logarithm attacks to reconstruct wallet secrets. While some claims are framed as demonstrations involving specific Bitcoin addresses and recovered funds, the underlying security concern matches established cryptographic research showing that biased or repeated nonces can expose keys at scale from passive blockchain analysis. Recommended mitigations across the sources include adopting **RFC 6979** deterministic nonce generation, auditing PRNG and entropy sources, enforcing secure boot and firmware verification on hardware wallets, and hardening devices against nonce exfiltration and other signing-side attacks.
Jun 29, 2026