Five Crypto Wallets Drained of 5.7 Million Dollars via CryptoJS RNG Flaw

# Five Crypto Wallets Drained of 5.7 Million Dollars via CryptoJS RNG Flaw The most interesting story on the wire today isn't a breach of a government agency or a massive leak of credentials. It's a math problem. Just under 5.7 million dollars have been drained from five different cryptocurrency wallet applications because they all relied on a weak random number generator in the CryptoJS library. The tradecraft here is deceptive in its simplicity: the failure of entropy. For those not steeped in cryptography, think of a recovery phrase (those 12 or 24 words you write down) as a very long password. To be secure, that password must be truly random. If it's generated by a Pseudo-Random Number Generator (PRNG) that doesn't have enough "noise" (entropy) from the system, the sequence of numbers it produces becomes predictable. When an attacker knows exactly how a PRNG is seeded and which algorithm it uses, they don't need to steal your private key. They can simply simulate the generator until they produce a set of keys that match active wallets with funds in them. It's essentially like knowing a locksmith uses the same master key for every lock in a specific neighborhood; you don't have to pick the lock if you already have the key. I have high confidence that this is a systemic library failure rather than a targeted attack on the wallet vendors themselves. The evidence is in the distribution: five different apps, one shared dependency. To move my confidence from "high" to "certain," I'd need to see the specific commit history of those wallets to confirm they weren't overriding the CryptoJS defaults with their own flawed logic. This rhymes with the 2008 Debian OpenSSL disaster. In that case, a maintainer accidentally removed a line of code that added entropy to the seed, resulting in a limited pool of predictable SSH keys across thousands of servers. The difference is that while the Debian flaw was an accident of maintenance, this CryptoJS issue suggests a failure in selecting a library fit for purpose in a high-stakes environment. The second-order effect here isn't just the loss of 5.7 million dollars. It's the collapse of trust in "non-custodial" wallets. The entire value proposition of these apps is that the user holds their own keys. If those keys are mathematically predetermined, the security boundary is an illusion. This will likely trigger a wave of audits for any other financial tool relying on CryptoJS for key generation, potentially exposing thousands more wallets before they're drained. Turning to the build pipeline, CISA has added CVE-2026-63077 to its Known Exploited Vulnerabilities catalog. This is a critical unauthenticated remote code execution (RCE) flaw in JetBrains TeamCity. The incident is straightforward: an attacker can execute code on the server without needing credentials. But the spine of the story isn't the CVE; it's who uses TeamCity. It's the heart of the CI/CD pipeline for some of the largest software shops in the world. If you control the build server, you don't need to hack the production environment: you just bake your backdoor into the next official update and let the vendor distribute it for you. I have moderate confidence that we'll see a spike in supply-chain compromises linked to this over the next 90 days. I'm cautious because many organizations have moved toward ephemeral build runners, which limits the persistence an attacker can gain. However, if I start seeing anomalous outbound traffic from corporate build environments to unknown IPs in Eastern Europe or East Asia, my confidence will shift to high. The risk here extends two steps downstream. The immediate victim is the company running TeamCity. The secondary victim is every customer who downloads a signed binary from that company. We're looking at a potential "SolarWinds" scenario where the breach happens in a tool the security team often overlooks because it's viewed as "internal infrastructure." Then there is the situation in South Korea, where authorities have restricted the operations of Lotte Card. The trigger was a data breach affecting millions of users. While the wire is focused on the regulatory fallout (the government effectively putting a brake on the company's business), the real story is the speed of the response. South Korean regulators are notoriously aggressive. Seeing them restrict operations in real-time suggests they believe the breach wasn't just a leak, but an ongoing failure of systemic controls. I distrust the early chatter suggesting this was a state-sponsored hit. Fast attribution is usually a guess dressed up as intelligence. My confidence in any specific actor for the Lotte Card breach is low. To move that needle, I'd need to see the exfiltrated data being used in a coordinated influence operation or seeing the malware samples share code with known APT frameworks. Until then, it's just as likely to be a criminal group looking for a payday. Looking at the broader numbers for the week, the noise is overwhelming. We've seen 438 data breaches and 383 policy regulation stories in seven days. Technology remains the most targeted sector, with 331 stories this week alone, followed by government at 218. The sheer volume of "breaking" news often masks the actual trend. The trend isn't that we're seeing more zero-days; it's that attackers are getting better at finding the one weak link in a chain of dependencies. Whether it's a flawed RNG library in a crypto wallet or an unpatched build server, the point of entry is almost always a piece of trusted software that someone forgot to verify. We tend to treat these as isolated events: a "crypto bug" here, a "CI/CD flaw" there. But they're parts of the same problem: the outsourcing of trust. We trust the library, we trust the build tool, and we trust the vendor. The uncomfortable question is how many other "predictable" keys are currently sitting in production environments because a developer imported a library without checking if its random number generator was actually random. I suspect the number is far higher than the current list of victims suggests.