- Organisation
- Casa
- Evidence role
- Secondary analysis
- Published
- 2026-08-06
- Source changes
- 0
- Detected differences
- 2
- Unreviewed
- 0
- Copies held
- 3
Jameson Lopp's 6 August essay for Casa, and two things at once: a restatement of the incident for a general reader, and Casa's account of its own security practice. It argues that the economics of finding a vulnerability have inverted now that a frontier model can read a large codebase cheaply, that a point-in-time audit is "a photograph, not a film", and that the defect survived review because it sat in build glue rather than in the cryptographic library everyone scrutinised. It then describes what Casa says it does: regular full-scope external penetration tests, targeted audits before launch, event-driven re-engagement, and an AI penetration-testing harness run against its own code. Casa is a custody provider with a commercial interest in the comparison it draws, and its account of its own internal practice is not observable from this archive. Its statement that researchers believe the vulnerability was most likely found by a frontier model is an attribution the record holds as contested; see the AI discovery material.
Every check is recorded, including checks that found no text change. A detected edit is therefore bounded between two checks. The publisher's exact save time is not observable from this record. Last checked .
This post is held twice: here, with this project's own note on why it matters, and again as part of the conversation captured at , which is polled for changes. Both copies are the same post; neither is a separate event.
Snapshot and diff bodies for this chain monitor are held in the local evidence archive but withheld from the public site because they can contain the addresses of people who published nothing themselves. Capture times and reviewed change summaries remain available below.
Held captures
-
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 0 lines
Extracted text as captured
Bitcoin Security Product Updates Casa Website Search Sign up Log in Casa Blog - Bitcoin Security Made Easy AI The Rise of the Machines by Jameson Lopp 5 hours ago 8 min read What the Coldcard vulnerability means for Bitcoin security and what Casa is doing about it. On July 30, 2026, roughly 1,200 Coldcard wallets were drained in about 40 minutes. More than 1,000 bitcoin (tens of millions of dollars) moved to an attacker's wallet in a quick burst. No devices were touched. No phishing emails were sent. No seeds were leaked. The attacker never needed to. Security researchers at Block, working with others across the industry, traced the root cause of the theft to a firmware integration error: a build configuration check was written in a way that silently disabled Coldcard's hardware random number generator. In its place, the firmware fell back to a deterministic software pseudo-random generator seeded from values an attacker can predict or reconstruct - the chip's serial number and its clock state. On older devices, the effective space of possible seeds collapsed from 128 bits to something on the order of 40. An attacker can enumerate every seed those devices could ever produce, derive the addresses, and check them against the public blockchain - entirely offline. Any match is a wallet they can control. The detail that should focus every security team in this industry: the source code was viewable the entire time. Human reviewers looked at it for years. They confirmed the hardware RNG existed. Nobody checked whether the seed generator actually called it correctly. Researchers now believe the vulnerability was most likely found by a frontier AI model - someone pointed the best available model at the public source, and it surfaced what human eyes had missed. Whether or not that attribution is ever confirmed, it doesn't matter. It is plausible today, and it will be normal tomorrow. The threat environment has changed, and we'd like to talk plainly about what Casa is doing. The lesson: assume machines read your code The economics of vulnerability discovery have inverted. Reading a large codebase well enough to find a subtle logic flaw used to require a scarce, expensive expert and weeks of their time. It now requires an API key and an afternoon. Attackers know this. They are running frontier models against every line of security-critical public code they can find - firmware, wallet libraries, smart contracts, custody platforms. The only rational response for defenders is to run the same machines first, and to run them continuously. The accelerating pace of vulnerability discovery should be a wake up call for all software developers! The threat landscape has changed. If you wish to retain a strong defensive posture then you MUST adopt the same LLM tooling that attackers are using to find vunerabilities. — Jameson Lopp (@lopp) August 6, 2026 Manual audits and pentests: necessary, yet nowhere near sufficient We've had a standing concern about security audits for years, and the Coldcard incident is a perfect illustration of it: an audit is a photograph, not a film. A traditional audit or penetration test is a point-in-time engagement. Smart, bounded humans review a scoped slice of your system over a few weeks and produce a report. The day that report ships, it begins to rot. Code changes daily. New dependencies land. A build flag flips somewhere in a firmware integration, and the photograph from six months ago is now a picture of a system that no longer exists. Coldcard's firmware was public and had been reviewed by numerous security researchers. The bug survived anyway - because the bug wasn't in the cryptographic library everyone scrutinized. It was in the build system: one wrong macro check that rerouted entropy to a fallback nobody thought to question. Glue is often where catastrophic bugs live, and glue is exactly what scoped, time-boxed human review tends to skip. This doesn't mean audits are worthless. It means they are one layer, and you should be honest about their limits. Casa's practice: External penetration tests across the platform on a regular cadence - at least annually, full-scope - covering our APIs, web applications, and mobile apps. Targeted audits for major new features and services before launch, so new code gets expert scrutiny while it's still cheap to change. Event-driven re-engagement: when the threat environment moves - a new attack class, an industry incident like this one - we don't wait for the calendar. We scope a fresh review around the lessons of the incident. Continuous layers underneath the point-in-time ones, so the gaps between audits are covered by something that never sleeps. That last bullet is where we think the industry has to go, and it's where we've invested the most resources over the past year. Fighting AI with AI If frontier AI models can find vulnerabilities like this one, we intend to find ours first. Earlier this year we built an AI penetration-testing harness that runs across all of our code on a recurring basis. We’re using it to regularly audit our code using the latest frontier models, like Kimi K3 and Qwen 3.8 Max. We're also pleased to share that Casa has been accepted into Anthropic's Cyber Verification Program, which gives our security engineering team access to the full capabilities of Anthropic's newest models for vulnerability exploitation analysis, adversarial reasoning, and exploit-chain modeling. The same class of reasoning an attacker would point at us, now gets pointed by us, first.Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
2 presentation-noise differences. Sidebar, ticker and other page chrome churn that our review classified as not being changes to what the source says.
- +3 -1 Only the article's relative age label and the adjacent newer-post navigation link changed.
- +1 -1 Only the relative timestamp on the Casa article rolled. The article body was unchanged.
The excerpts and plain unified diffs above show the text this project held and how it changed. To verify a quotation, compare it against the page itself or against the Internet Archive's copies, which are independent of this project.
Complete captures are held offline rather than mirrored here, so this page shows diffs and excerpts. If a quotation is ever disputed, the full copy can be produced. Ask.
Compare the screenshot or a quotation against the original while it is available.