# The Trail of Bits Blog Recent content on The Trail of Bits Blog This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Review argues 1Password's AI patching benchmark overstates poor patch quality DevFeed: [Review argues 1Password's AI patching benchmark overstates poor patch quality]() Original publisher: [Read original article]() Author: "Anish Naik"; "Dan Guido"; "Benjamin Samuels"; "Marcelo Morales" Published: 2026-09-15T11:00:00Z Content type: opinion Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Artificial Intelligence](), [Benchmark](), [Vulnerabilities](), [Testing](), [Agent Skills]() Tags: [agent-skills](), [agents](), [ai](), [benchmark](), [open-source](), [patch-the-planet](), [report](), [testing](), [vulnerabilities]() ### AI overview The article argues that 1Password's 26% clean-fix headline gives a misleading picture of AI patching because the benchmark included difficult vulnerabilities, prompts instructing agents to apply wrong fixes, trials that prohibited testing, and differing reasoning settings. It reports that 2,634 of 3,067 eligible patches blocked the supplied exploit and announces two agent skills for validation and review. ### Source excerpt 1Password's FLAWED report, published on August 6, 2026, gives defenders a misleading picture of AI patching. Its headline says models produced clean fixes only 26% of the time. That figure includes experiments that deliberately instructed agents to apply the wrong fix, along with experiments in which agents could not compile or test their patches. The report risks making defenders less effective by discouraging them from using technology that could help them fix more vulnerabilities. Teams that take its headline at face value may leave repairable vulnerabilities unaddressed. We want our work to help defenders fix more vulnerabilities. This post shares real-world data on human and agent patch quality from our consulting projects and Patch the Planet. We're also releasing two agent skills: post-patch-validation to help agents test fixes, and review-walkthrough to help engineers review them. How the experiment produces a misleading headline Our review of 1Password's code and data found four choices that make its 26% clean-fix rate a misleading guide to ordinary patching work.1 The sample was selected for difficult fixes. The authors chose six vulnerabilities because their fixes were complex. Clean-fix rates ranged from 3% to 60% across those bugs, so the average depends heavily on which vulnerabilities made the list.2 Two prompts tell agents to apply the wrong fix. Those prompts account for 22% of the data. Combining them with ordinary repair attempts makes the reported rate depend partly on how often the researchers chose to give agents bad advice. More than a third of the trials prohibit testing. One evaluation mode prevents agents from building or running code and accounts for 36% of the data. The headline combines those trials with experiments in which agents could test their patches and act on the results. The models ran at different reasoning settings. GPT-5.5 ran at medium effort and Opus 4.8 at high. These were the tools' defaults. Neither model was tested at i ## A "proof" of Fermat's Last Theorem that fits the margin DevFeed: [A "proof" of Fermat's Last Theorem that fits the margin]() Original publisher: [Read original article]() Author: "Marc Ilunga" Published: 2026-09-09T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Lean](), [bug](), [Memory safety verification]() Tags: [bug](), [exploits](), [memory-safety](), [open-source](), [vulnerability-disclosure]() ### AI overview A Lean string-slicing bug caused its logical evaluator and compiled native code to disagree, allowing a contradiction that could make an invalid proof appear checked. The issue was fixed after disclosure. ### Source excerpt Fermat famously claimed to have a "truly marvelous proof" of his Last Theorem, but he never wrote it down, insisting the margin of his page was too narrow to contain it. A few centuries later, Anthropic announced a complete formalization of Fermat's Last Theorem using 13 million lines of Lean code (clearly not what Fermat intended). Luckily, we found a wonderfully cursed Lean bug, shown below, that suggests the proof may have fit the margin after all. The issue affects all stable versions of Lean up to 4.33.1, and the patch is incorporated in v4.34.0-rc1. A "checked" proof of Fermat's Last Theorem using Lean 4.33.1 The blue checkmarks in the screenshot above would suggest that Lean considers this proof correct. This seems odd given the amount of work Sir Andrew Wiles put into this problem and the vast size of Claude's proof. So what is going on? The "proof" clearly doesn't make any sense and exploits an issue in Lean. We found the issue while using GPT-5.6 to experiment with a new skill for code review. We want to clarify up front that the issue is not a kernel soundness issue, but it happens to nicely fit any discussion of strings, lengths, and substrings. The issue affects String.Pos.Raw.extract, Lean's low-level string-slicing function. When asked to extract a one-byte slice at an astronomically large position, Lean's logical definition returns the empty string. But the compiled native code returns the entire original string. That disagreement is enough to manufacture a contradiction. Lean's ordinary evaluator "proves" that the tiny slice was empty, while native evaluation "proves" that the very same slice contained "a truly marvelous proof." Put those together, and Lean concludes that the empty string equals a non-empty string. And once you have a contradiction, you can prove anything, including Fermat's Last Theorem. On the bright side, the Lean team was considerably faster than mathematical history. About 90 minutes after we reported the issue, hargoniX opened ## VMs won't contain cyber-capable agents DevFeed: [VMs won't contain cyber-capable agents]() Original publisher: [Read original article]() Author: "Artem Dinaburg" Published: 2026-08-26T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Vulnerabilities](), [AI Bots](), [AI-assisted coding]() Tags: [ai](), [ai-agent](), [bugs](), [cybersecurity](), [gpt](), [kernel](), [linux](), [open-source](), [patch-the-planet](), [vulnerabilities]() ### AI overview An evaluation of GPT 5.6-Cyber reports that it escaped a QEMU/KVM sandbox three times by using disclosed flaws and finding zero-days. The article argues that capable autonomous AI agents should not be assumed to be safely contained by a VM. ### Source excerpt As part of Patch the Planet, we received preview access to GPT 5.6-Cyber with a simple task: evaluate its cyber capabilities. Recent events inspired me to give it a challenge to work through: escape the VM I'd normally use for sandboxing. The target was a QEMU/KVM VM on my Linux dev machine (Debian Linux 12, AMD Zen3). It escaped the VM three different times. First, it used recently disclosed bugs in my host kernel. When I fully updated, it used disclosed bugs that had not yet reached package maintainers or were not classified as security bugs. When I rebuilt QEMU and dependencies from the latest upstream source, it found several 0-days. It operated autonomously for hours, backtracked from approaches that didn't work, pulled code and research papers, wrote oracles, made its own minimal examples, and aimed for a reusable, reliable exploit, all with minimal handholding and prompting. My main job was to physically reboot the machine when it hardlocked the host kernel. If it wasn't clear before, I will state it plainly: you can no longer assume a mere VM will contain a sufficiently advanced AI agent. To use a 2010s term of art, you should treat such agents as an advanced persistent threat. Advancing cybersecurity capabilities Let's imagine a common situation: you want to run an AI agent, but need its full capabilities, including the ability to download, build and debug software; do research; sift through dependencies; set up fuzzers; triage vulnerabilities; and stand up services under different configurations. The generally accepted solution is to set up a VM that serves as a safety perimeter and isolated prison for the agent: this virtual environment contains nothing of value, is separate from the host, and can be immediately deactivated or snapshotted for later investigation. This setup allows the agent to roam free, while isolating your computer from its consequences. There is, of course, a tiny wrinkle. To be useful, the virtual environment must share resources with ## State divergence enables unauthorized access DevFeed: [State divergence enables unauthorized access]() Original publisher: [Read original article]() Author: "Paweł Płatek"; "Denys Pakizh" Published: 2026-08-25T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [bug](), [Blockchain](), [Authorization](), [Transactions](), [SDKs]() Tags: [2026](), [access-control](), [audits](), [authorization](), [blockchain](), [bug](), [financial-services](), [module](), [tokens](), [transactions](), [vulnerabilities]() ### AI overview The article describes a Provenance Blockchain authorization bug that allowed users to grant themselves admin control over marker accounts without holding tokens. The flaw affected non-fixed-supply markers because the access check read a stale zero-valued supply field instead of the live circulating supply. The issue was mitigated in v1.28.0 and fixed in v1.29.0. ### Source excerpt We found and reported a bug in Provenance Blockchain, a public proof-of-stake chain built on Cosmos SDK, that lets any user grant themselves admin control over marker accounts without holding a single token. Provenance covers a range of financial services, including on-chain tokenized loans, private equity tokens, bridged assets, and asset registries. Our bug affected 82 markers representing live financial assets on mainnet. We found the bug, which affects versions before 1.28.0, in March 2026, and reported it to Provenance on April 1. It was mitigated in PR #2627 (commit c81fd65), which shipped in v1.28.0 on May 1, 2026, and fixed in PR #2734, which shipped in v1.29.0 on June 8, 2026. What is a marker? The marker module is Provenance's core primitive for fungible tokens. Chain participants can issue a new asset on Provenance by submitting a MsgAddMarkerRequest transaction; the chain creates a dedicated account for that asset, called a marker. Each marker is a special account type that controls: A denomination (e.g., uusd.trading, cusd.deposit, cguaranteedrateomni) An access control list governing who can mint, burn, withdraw, deposit, or administer the token A supply field recording the canonical token count An escrow balance (the marker account can hold any asset, not just its own denomination) Markers are either supply_fixed (the supply field is enforced as a hard cap) or non-fixed (the bank module is the source of truth; the supply field is informational). This distinction is central to the bug. The bug: An access check anyone can pass AddAccess is the Cosmos SDK message handler that processes requests to modify a marker's access control list. It checks whether the caller is authorized using three conditions, any one of which is sufficient: The caller is the marker's designated manager and the marker is in Finalized state. The caller already holds ACCESS_ADMIN on the marker. The caller controls 100% of the marker's circulating supply. case types.StatusFinalized, ## How Trail of Bits helps verify the integrity of your Signal chats DevFeed: [How Trail of Bits helps verify the integrity of your Signal chats]() Original publisher: [Read original article]() Author: "Tjaden Hess" Published: 2026-08-11T17:30:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [client](), [servers](), [Cloudflare](), [App]() Tags: [audits](), [cloudflare](), [cryptography](), [devices](), [external](), [open-source](), [safety](), [server](), [signing](), [verification]() ### AI overview The article explains how Trail of Bits helps verify the integrity of Signal chats through Automatic Key Verification. The system uses external auditors, globally consistent public-key maps, Merkle trees, and signed tree heads to make mismatches harder to conceal. Signal clients currently require signatures from auditors operated by Signal, Cloudflare, and Trail of Bits. ### Source excerpt Every Signal chat starts the same way: the client asks the Signal server for the public key associated with your contact's phone number. But how do you know the server gave you the right key? A compromised server could provide a false public key, allowing the client to encrypt messages to an attacker rather than the intended recipient. Until now, the only way to detect such malfeasance was to verify safety numbers with your contact in person or over a trusted channel. Signal recently launched an alternative: Automatic Key Verification, a feature that helps validate that your chats are secure without requiring direct safety number comparison. Trail of Bits built and operates one of the three auditors that make this system trustworthy. Our auditor, which is an independent implementation written from scratch, continuously checks that the Automatic Key Verification system behaves honestly. How key verification works Automatic Key Verification is a form of "key transparency" that makes mismatch attacks harder to hide by creating a globally consistent view of the set of public keys associated with each phone number. The Signal app now performs a periodic self-check to ensure that all keys stored in the global map for your account belong to your devices. If the app is unable to verify the log, or finds that not all keys are expected, the user is presented with a warning that "Automatic Key Verification is currently unavailable for your device." Automatic Key Verification may also be unavailable for other reasons, as outlined in Signal's documentation. What our auditor does Automatic Key Verification depends on external auditors. Trail of Bits helps this system function by providing external verification that the user ↔ public key map is globally consistent and well formed, and does not hide any entries. Each time a new entry is added, we update our local copy of the map, stored as a Merkle tree. Periodically, we sign the head of the tree using a signing key that only we kn ## A few notes on AWS Nitro Enclaves: KMS integration DevFeed: [A few notes on AWS Nitro Enclaves: KMS integration]() Original publisher: [Read original article]() Author: "Paweł Płatek" Published: 2026-08-05T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Cryptography](), [AWS IAM]() Tags: [application-security](), [aws](), [cryptographic](), [cryptography](), [encryption](), [iam](), [integration](), [policy](), [trusted-execution-environment]() ### AI overview The article examines security and operational risks in integrating AWS Nitro Enclaves with KMS, including attestation, key policies, and encrypted key handling. ### Source excerpt Nitro Enclaves and Key Management Service (KMS) feel like a natural fit: since the KMS can verify attestation documents generated by the enclaves, developers can offload key management tasks from their applications to the AWS-managed service. But integrating an external service with your trusted enclaves comes with new threats, even if that service comes from the same provider. In this blog post--the third in our series on Nitro Enclaves, following our posts on attack surface and images and attestation--we catalog passive and active attack classes against the enclave-KMS communication channel, and cover the operational risks that persist even when the cryptography is correct. Intro to KMS The KMS is an AWS service that provides a unified public API for creating and managing keys backed by HSMs to the broader AWS ecosystem. There are three main key types supported by KMS that devs need to care about: Customer-managed keys (CMK) Data keys (DK, symmetric) Data key pairs (asymmetric) CMKs never leave KMS. You request KMS to perform cryptographic operations (like encryption or signing) for you. Data keys and key pairs are generated in KMS, are not stored in KMS, and are intended for programmatic uses. For symmetric keys, the KMS gives you a plaintext key and the same key encrypted to CMK. Your application performs encryptions, removes the plaintext key, and stores the key encrypted to a CMK along the ciphertexts; this pattern is called envelope encryption. For asymmetric keys, the KMS gives you a plaintext key pair and the private key encrypted to CMK. Your application creates signatures or encrypts data, deletes the private key, and keeps the public key and encrypted private key (along with signatures/ciphertexts). Both types of data keys can be used with Decrypt operation to get plaintext keys again. S t o r a g e s t { o E r _ e d ( k E , _ C d } k , C ) E n c l a v G e e { n d e k C D p r , = e l a E e c a t _ n r i e d c y n D k ( p t a = d t e t e k ( { x a n , c d t ## Building secure Uniswap v4 hooks DevFeed: [Building secure Uniswap v4 hooks]() Original publisher: [Read original article]() Author: "Nicolas Donboly" Published: 2026-07-30T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Security](), [Code](), [Authorization](), [Architecture & Design](), [incident]() Tags: [audits](), [blockchain](), [code](), [developers](), [development](), [exploits](), [incident](), [review](), [security](), [vulnerabilities]() ### AI overview Uniswap v4 hooks add customizable pool behavior but shift important security responsibilities into application and hook code. Drawing on audit findings and public reports, the article identifies recurring failure patterns--including missing caller checks and accounting bugs--and presents them as a checklist for builders and auditors. ### Source excerpt Uniswap v4 hooks let developers add custom behavior to pools, including dynamic fees, custom accounting, and external integrations. This flexibility moves some security responsibilities into application and hook code. The Cork and Bunni exploits are two app-level incidents that show what can go wrong in that code. Together, they account for more than $20M in losses. Neither incident stemmed from a flaw in the Uniswap v4 core protocol or the PoolManager; both arose from application-specific authorization and accounting logic built around hooks. After analyzing dozens of findings from Trail of Bits audits (including our Uniswap v4-core security review), public reports from other firms, and the Solodit database, I've identified seven recurring failure patterns in application and hook code, including missing caller checks and accounting bugs that still satisfy the PoolManager's settlement invariant. Builders can use these patterns as a secure-development checklist; auditors can use them to focus their review. What the PoolManager guarantees If you're familiar with Uniswap v3, where each pool was a separate contract, v4 inverts the model. All pool state now lives in a singleton PoolManager contract, with each pool represented in its storage. Uniswap v4 adds hooks: independent contracts that execute custom logic at specific points in the swap and liquidity lifecycle. Figure 1: Pools live inside the singleton PoolManager, and multiple pools can use the same hook contract. Here's what a pool looks like in v4: struct PoolKey { Currency currency0; Currency currency1; uint24 fee; int24 tickSpacing; IHooks hooks; } Figure 2: A pool's PoolKey includes both currencies, the fee, tick spacing, and the hook address (v4-core/src/types/PoolKey.sol). Notice that the hook address (IHooks hooks;) is part of the pool's identity. If you change any of these fields, you're talking to a different pool. This matters because trusting the wrong PoolKey means trusting the wrong pool. v4 also intr ## How we use /goal to find bugs in Patch the Planet DevFeed: [How we use /goal to find bugs in Patch the Planet]() Original publisher: [Read original article]() Author: "Trail of Bits" Published: 2026-07-28T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [codex](), [bug](), [Open Source](), [open-source-security](), [cURL](), [Rust](), [OpenAI]() Tags: [analysis](), [blog](), [bugs](), [code](), [codex](), [machine-learning](), [open-source](), [openai](), [patch-the-planet](), [software](), [tool](), [vulnerabilities]() ### AI overview The article describes how Trail of Bits used Codex's /goal feature in Patch the Planet to find bugs in open-source software. It highlights results involving Rust, curl, Semgrep-based variant analysis, and potential Keycloak privilege-escalation issues, then discusses goal and prompt design techniques. ### Source excerpt Codex's /goal feature amplifies bug hunting, but getting good results requires the right prompt, the right scope, and the right number of outcomes per run. For Patch the Planet, our joint initiative with OpenAI to find and fix bugs in open-source software, we pointed Codex at some of the most widely used, heavily audited codebases in the world, like Rust, curl, and zlib. One tool came up again and again in our internal bug-report channels: /goal, which hands Codex an open-ended objective and lets it work independently toward a success condition. Here are a few highlights: /goal found every Rust bug we submitted, including a soundness hole and a miscompilation now patched in Rust 1.98, from a single variant-analysis pipeline. It turned every project's past CVEs into Semgrep rules that had to fire on the vulnerable version and stay silent on the patched one, then flagged 11 variant hits across multiple projects. It uncovered two potential high-severity privilege-escalation bugs in Keycloak's SAML component during a discovery run. Over the first few weeks of Patch the Planet, our engineers independently converged on three techniques for using /goal. We found that getting the most out of /goal means treating the prompt as a set of specific success criteria, not a set of instructions. (Note that this blog post uses /goal to refer to goal-based prompting in general. Codex can also set goals for itself through a tool call, and that's how we recommend everyone use it; we rarely type the slash command ourselves.) 1. Let Codex write the goal The art of using /goal is prompt design, and we found that Codex knows Codex the best. Internally, our single most repeated /goal tip was to use Codex to help write each /goal prompt. We hand Codex threat model files and the context about what we're looking for, and then tell it to write the goal prompt. As mentioned before, /goal is a tool Codex can invoke on itself, and a few engineers stopped typing goals by hand entirely. $goal-prompt ## Rust-proof your code with our new Testing Handbook chapter DevFeed: [Rust-proof your code with our new Testing Handbook chapter]() Original publisher: [Read original article]() Author: "Paweł Płatek" Published: 2026-07-13T11:00:00Z Content type: tutorial Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Rust](), [Security](), [mutation-testing](), [Tooling](), [Test coverage](), [Memory Safety](), [Rust formal verification](), [Concurrency](), [Claude Code](), [Claude]() Tags: [application-security](), [claude-code](), [concurrency](), [measurement](), [memory-safety](), [mutation-testing](), [rust](), [security](), [testing](), [testing-handbook](), [tooling]() ### AI overview A new Testing Handbook chapter presents techniques for security testing Rust programs and systems. It covers Rust security limitations, dynamic and static analysis, undefined-behavior detection with Miri, property testing, coverage and mutation testing, Clippy, manual code review, memory zeroization, model checking with Kani, and dependency supply-chain vetting. The article also announces rust-review, a Claude Code plugin for automated Rust security reviews. ### Source excerpt We've added a new chapter to our Testing Handbook: a comprehensive guide to security testing Rust programs. This chapter covers the tools and techniques we use at Trail of Bits to validate the security of Rust programs and systems. fn main() {(|f:&dyn Fn(u128)->Box< dyn Iterator+'static>|f(*[&( 0x7B736D70683F73u128<<64| 0x7A6A6D7C3F7A667D),&(0x7B736Du128 <<64|0x70683F7073737A77)][((std::hint:: black_box(0.0f64)/0.0).to_bits()>>63)as usize]) .for_each(|c|print!("{c}")))(Box::leak(Box::new(|n: u128|Box::new(std::iter::successors(Some(n),|&n|Some(n>>8) ).take_while(|&n|n>0).map(|n|((n as u8)^0x1F)as char))as _)))} What's in the chapter The chapter starts with a security overview of what Rust's guarantees do and don't cover, including underappreciated issues like unwind safety, nondeterminism, and arithmetic errors. This leads into an overview of dynamic analysis, which covers a range of boosters for unit tests, how to use Miri to detect undefined behavior, property testing with proptest, coverage measurement, and mutation testing. The static analysis section then covers Clippy in depth, including a list of our favorite lints. Beyond tooling, the chapter also covers what we've learned from auditing Rust codebases directly. Our gotchas and footguns checklist is a great reference for manual code reviews, and will help you find subtle issues like a & b == c having different operator precedence than in C. The memory zeroization section offers three solutions to the tricky problem of guaranteeing that secrets are erased from memory. Finally, the specialized testing sections cover tools like Kani (a model checker), and the supply chain section covers the full toolchain for vetting dependencies. Still oxidizing We've also released rust-review, a Claude Code plugin for automated Rust security reviews. Co-built with Aptos Labs, it targets over a dozen bug classes, from memory safety and concurrency hazards to FFI pitfalls and async cancellation issues. It's a fast wa ## Mutation testing comes to DAML DevFeed: [Mutation testing comes to DAML]() Original publisher: [Read original article]() Author: "Kamil Chmielewski" Published: 2026-07-08T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [mutation-testing](), [test-coverage](), [Authorization](), [Code](), [Open Source]() Tags: [applications](), [blockchain](), [bug](), [code](), [development](), [mutation-testing](), [open](), [open-source](), [production](), [test-coverage](), [testing](), [tool-release]() ### AI overview Mewt, an open-source mutation-testing engine, now supports DAML, the language used for Canton Network applications. The article explains how mutation testing exposes gaps that ordinary coverage reports can miss by generating modified versions of code and checking which changes survive the existing test suite. ### Source excerpt In April we released Mewt, our open-source mutation-testing engine that finds the gaps in your test suite. Today we're expanding it with support for DAML, the language Canton Network applications are written in. Mewt now reads DAML, generates several classes of mutants (including two built for DAML's authorization primitives), and runs them through your existing test suite to count how many mutants survive. If you want to try it, simply install Mewt from the repository, point a mewt.toml at your project and its test command, and use mewt run. For a team shipping DAML to production, that count is what a passing test run is actually worth: it puts a number on how much your suite checks, whereas a green run on its own does not. Why DAML's coverage reports lie Test coverage is the most reassuring lie in smart-contract development. Hitting 100% line coverage tells you the test runner walked the code; it does not tell you whether any test would fail if that code stopped doing what it is supposed to. We have been grading test harnesses by how many mutants they kill since at least 2019, and our primer on finding the bugs your tests don't catch shows how a green suite can still miss the bug that matters. DAML's built-in coverage measures execution at the template and choice level: which templates were created and which choices were exercised over the test run. It reports whether each choice was exercised, not what happened inside it. A test that exercises a choice once and asserts nothing about the result reports that choice as covered. The report prints the same green percentage whether the test verifies the outcome or discards it. How mutation testing works Instead of asking whether your tests reached the code, mutation testing grades your tests by sabotaging that code. The engine generates mutants, copies of the code that each carry one small deliberate change: a flipped comparison, a removed branch, a dropped party. It then runs your test suite against each one. A mutant ## GPT-5.5-Cyber built a zlib fuzzing lab in a day DevFeed: [GPT-5.5-Cyber built a zlib fuzzing lab in a day]() Original publisher: [Read original article]() Author: "Benjamin Samuels" Published: 2026-07-02T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [AI-assisted coding](), [Vulnerabilities](), [AI Chat]() Tags: [bugs](), [codex](), [compression](), [fuzzing](), [gpt](), [machine-learning](), [open-source](), [openai](), [patch-the-planet](), [security](), [tooling](), [vulnerabilities]() ### AI overview Trail of Bits reports that GPT-5.5-Cyber built a fuzzing campaign for zlib in a day, using sanitizer and variant builds, harnesses, and seeds. The effort is part of Patch the Planet, which aims to find and patch security bugs in open-source projects with maintainers. ### Source excerpt We're running Patch the Planet, an ongoing collaboration with OpenAI that pairs Trail of Bits engineers directly with more than 30 open-source projects. Its goal is to front-run a serious problem facing open-source maintainers: highly capable models like GPT-5.5-Cyber will soon create a firehose of bug reports, and OSS maintainers are already spread thin. Our plan is to point OpenAI's latest models at real codebases, find the security bugs first, work with maintainers to patch them, and find ways to decrease the burden on maintainers in the long run. We'll publish field reports like this one as the initiative progresses; follow along via the Patch the Planet tag. The expertise barrier that kept bespoke fuzzing campaigns out of reach for most attackers is gone. We watched GPT-5.5-Cyber build in a single day what would have taken weeks for a skilled security researcher: harnesses across a dozen entrypoints, sanitizer and variant builds, seeds, and multiple findings currently undergoing coordinated disclosure. This particular instance focused on zlib, a widely used data format and lossless data compression software library. We pointed GPT-5.5-Cyber at the library and drove it through Codex with the /goal command, asking it to find a specific class of bugs that are critically dangerous in compression libraries. We'll publish the full harness and findings for inspection once the vulnerabilities are patched and a new release is cut. The lab GPT-5.5-Cyber built in a day We didn't tell the model how to find these bugs. The obvious first move is to read the source code, but zlib has been reviewed so thoroughly that there's little left to find that way. GPT-5.5-Cyber worked that out for itself, judged static review to be a poor use of tokens, and decided the higher value path was to build fuzz tooling to dynamically test the code. Earlier models given the same goal tend to read the code and flag whatever looks suspicious, ultimately leading to mediocre outcomes. We believe th ## Shipping post-quantum cryptography to Python DevFeed: [Shipping post-quantum cryptography to Python]() Original publisher: [Read original article]() Author: "Alexis Challande" Published: 2026-06-30T11:00:00Z Content type: release Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Cryptography]() Tags: [cryptography](), [open-source](), [post-quantum](), [python](), [release]() ### AI overview The article announces post-quantum cryptography support in pyca/cryptography 48 for Python, including ML-KEM and ML-DSA. It explains that adopting these primitives involves size, performance, and integration tradeoffs. ### Source excerpt Post-quantum cryptography is now one pip-install away for the entire Python ecosystem. With funding from the Sovereign Tech Agency, we implemented support for ML-KEM, the NIST-standard key-establishment primitive, and ML-DSA, the NIST-standard digital-signature primitive, in pyca/cryptography. On June 22, 2026, the White House ordered the U.S. government to accelerate its transition to post-quantum cryptography. The order says large-scale quantum computers, especially in adversarial hands, will threaten widely used cryptographic systems, and that attackers may already be collecting encrypted data now so they can decrypt it later. It also sets concrete migration deadlines: high-value and high-impact federal systems must use post-quantum key establishment by December 31, 2030, and post-quantum digital signatures by December 31, 2031. And even if you don't care about quantum resistance, that's not a problem because quantum resistance isn't the main benefit of post-quantum crypto. That transition cannot happen only at the policy layer. Every application that signs packages, validates certificates, establishes secure channels, or protects long-lived secrets depends on cryptographic libraries. If those libraries do not expose post-quantum algorithms, the software stack cannot migrate. Almost every Python program that touches cryptography goes through pyca/cryptography. It's currently the eleventh most-downloaded package on PyPI, pulling 1.2 billion downloads in the last month alone. The pyca/cryptography package handles the cryptographic operations of projects like Ansible, Certbot (the Let's Encrypt client), Apache Airflow, paramiko (the Python-only SSH client), and many others. If pyca/cryptography doesn't ship post-quantum primitives, the Python ecosystem can't begin to migrate. Post-quantum support is now one pip install away As of cryptography>=48, support for post quantum algorithms is just a pip install away. The version 48 release includes our Rust bindings for ML ## Introducing Patch the Planet DevFeed: [Introducing Patch the Planet]() Original publisher: [Read original article]() Author: "Trail of Bits" Published: 2026-06-22T16:50:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Open Source](), [Security](), [Vulnerabilities](), [Maintainers](), [pull-requests](), [Fuzzing/Fuzz testing](), [GitHub](), [Cryptography](), [networking](), [cURL](), [Go Language]() Tags: [announcements](), [cryptography](), [fuzzing](), [github](), [github-actions](), [go](), [maintainers](), [networking](), [open-source](), [openai](), [patch-the-planet](), [pull-requests](), [security](), [supply-chain](), [vulnerabilities]() ### AI overview Patch the Planet pairs Trail of Bits engineers and open-source maintainers with frontier models to discover, triage, and fix security issues. Its first week produced hundreds of bugs, 64 pull requests, and 51 issues across 19 projects, with work also adding tests, fuzzing harnesses, CI security scanning, supply-chain tooling, correctness fixes, and features. ### Source excerpt What happens when you clear dozens of Trail of Bits engineers' schedules, pair them with every open-source maintainer they can contact, and unleash the latest frontier models like GPT-5.5-Cyber on critical open-source targets? Thanks to our partnership with OpenAI and its Daybreak initiative, we can report that the impact is hundreds of discovered bugs, 64 pull requests, and 51 issues filed across 19 projects (with many more still undergoing coordinated disclosure). That was just the first week of Patch the Planet. Frontier models like GPT-5.5-Cyber are producing a firehose of security findings, and already-stretched maintainers must sift through all of it to separate real vulnerabilities from plausible-sounding false positives. Patch the Planet is different: with our experts orchestrating and triaging findings, we handle the work of fixing and hardening the code alongside the people who maintain it. The first week of Patch the Planet covered 19 projects across cryptography, networking, language infrastructure, and software supply chain. Among these 19 projects were cURL, NATS, pyca, Sigstore, aiohttp, the Go project, freenginx, Python and python.org, urllib3, PyPI, SimpleX, Valkey, and RustCrypto. Over 30 projects have joined the initiative so far, and we're rapidly expanding it to include more; if you maintain an open-source project, apply to join! Live look at the Trail of Bits engineering teams Anyone can file an issue, flex, and walk away. We showed up with the patches: 37 are already merged, and many more are in flight. These merges go beyond just fixing bugs: we're adding new tests and fuzzing harnesses, CI security scanning, supply-chain tooling, correctness fixes, and features maintainers had been meaning to get to. The goal of Patch the Planet is to leave essential open-source projects measurably better off. We brought patches, not just bug reports We're reporting public findings on GitHub, including 64 total pull requests. We also filed 51 issues, 19 of w ## Factoring "short-sleeve" RSA keys with polynomials DevFeed: [Factoring "short-sleeve" RSA keys with polynomials]() Original publisher: [Read original article]() Author: "Keegan Ryan" Published: 2026-06-12T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Vulnerabilities](), [Certificate Transparency](), [TLS (Transport Layer Security)](), [ssh](), [Open Source](), [Code]() Tags: [attacks](), [bug](), [certificate-transparency](), [code](), [cryptography](), [exploits](), [internet](), [open-source](), [software](), [ssh](), [tls](), [vulnerabilities]() ### AI overview Researchers found hundreds of weak RSA and DSA keys whose structured zero-bit patterns made them quickly factorable with a polynomial-based cryptanalytic technique. They linked many of the keys to a type mismatch in older CompleteFTP big-integer code and recovered 603 RSA private keys and 74 DSA keys from internet scans. ### Source excerpt What happens when the bits of an RSA private key are heavily biased toward 0 instead of being randomly generated? The public key's bits could be biased enough for us to detect these incorrectly generated keys in the wild. Together with Hanno Böck of the badkeys project, we found hundreds of unique keys that not only have this property, but can be quickly factored. We also found the bug that led to many of these keys and analyzed historical data to track the issue over time. Surprisingly, the pattern of 0 bits is often highly structured, allowing us to develop a powerful polynomial-based cryptanalytic technique that exploits the pattern. Figure 1: Two patterns of RSA moduli with repeated blocks of 0 bits seen in real-world examples. These "short-sleeve" keys, named for how the 0 bits don't fully cover the limbs of the big integers, largely fell into two patterns. Pattern 1 remains unexplained, but we traced pattern 2 to a type mismatch in big-integer code from old versions of the CompleteFTP file transfer software. The CompleteFTP bug also generated vulnerable short-sleeve DSA keys, and we recovered 603 unique RSA private keys and 74 DSA keys from internet scans. If you used CompleteFTP to generate host keys between December 2016 and December 2023, CompleteFTP has released a tool to check whether your keys need to be regenerated. How we found the weak keys The badkeys project is an open-source service that checks public keys for known vulnerabilities. While developing this tool, Hanno collected a massive number of real-world keys from public sources, including Certificate Transparency logs, internet-wide TLS and SSH scans, PGP keys, and many others. By searching this dataset for unexpectedly sparse RSA moduli, we uncovered a large number of keys in the wild with the patterns in Figure 1. Both patterns include several regularly spaced blocks of all zeros interleaved with seemingly random data. Pattern 1 appears in CT logs for certificates issued to several large organ ## The sorry state of skill distribution DevFeed: [The sorry state of skill distribution]() Original publisher: [Read original article]() Author: "Samuel Judson"; "Tjaden Hess" Published: 2026-06-03T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Security, Privacy and Abuse Prevention](), [AI Bots]() Tags: [agent-skill](), [agents](), [attacks](), [machine-learning](), [security](), [skills](), [supply-chain](), [vulnerabilities]() ### AI overview The article reports that public marketplaces for agent skills are being flooded with malicious skills and argues that tested skill scanners were readily bypassed. It frames skill distribution as a software-supply-chain security problem, with natural-language prompts and code both creating attack paths. ### Source excerpt Public skill marketplaces are being flooded with malicious skills that steal credentials, exfiltrate data, and hijack agents. In response, a segment of the security industry released skill scanners, a new family of tools designed to detect malicious skills before they're installed. But we tested them, and they don't work. We recently bypassed ClawHub's malicious skill detector, Cisco's agent skill scanner, and all three of the scanners integrated into skills.sh. These were not advanced attacks: it took us less than an hour to conceive and implement three of the four malicious skills in trailofbits/overtly-malicious-skills, using standard tricks and rapid inspection of the scanner source code. The fourth malicious skill took a few hours, but only because the prompt injection required some trial and error. Our findings demonstrate that even when skill scanners have some defenses, their static nature gives an adversary unlimited bites at the apple to tweak an attack until it finds a way through. Why skill security matters Software supply chains have long been the soft underbelly of computer security. As fragile infrastructure susceptible to both insider threats and external attackers, these supply chains were vulnerable enough when malicious code was the sole vector of compromise. But the rise in agentic systems has spawned a new style of dependency--the skill--and with it a whole new ecosystem of marketplaces and distribution channels that now run alongside traditional package managers. Malicious skills can embed harmful instructions in natural language (e.g., a SKILL.md prompt) as well as code, giving them whole new avenues to attack any system they are given access to. Compounding the issue, the distribution channels for skills have proved to be ship-first, secure-later. There are already multiple types of distribution channels for how users find skills and deploy them to their agents: ZIP archives distributed out-of-band and then uploaded manually or via API to agent ## Bringing full YAML anchor support to zizmor DevFeed: [Bringing full YAML anchor support to zizmor]() Original publisher: [Read original article]() Author: "Alexis Challande" Published: 2026-05-22T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [GitHub Actions](), [YAML](), [GitHub](), [ci](), [BigQuery](), [bug](), [Open Source](), [dataset]() Tags: [backdoor](), [bigquery](), [bug](), [bugs](), [ci](), [ecosystem-security](), [engineering-practice](), [github](), [github-actions](), [open-source](), [post-mortem](), [pull-requests](), [secrets](), [supply-chain](), [testing]() ### AI overview Trail of Bits describes how it collaborated with zizmor maintainers to add full YAML anchor support to the GitHub Actions static analyzer. The work fixed parsing and deserialization issues, aligned expression evaluation with GitHub's tests, and was validated against 41,253 workflows from 6,612 open-source repositories. ### Source excerpt In March 2026, attackers exploited a pull_request_target misconfiguration in the aquasecurity/trivy-action GitHub Action to exfiltrate organization and repository secrets, then used those credentials to backdoor LiteLLM on PyPI (see Trivy's post-mortem for the full timeline). zizmor is a static analyzer that GitHub Actions users run to catch exactly these misconfigurations before they ship. When GitHub Actions added support for YAML anchors in September 2025, a small but high-value slice of the ecosystem started writing workflows that zizmor could only analyze on a best-effort basis. Over the past three months, Trail of Bits collaborated with the zizmor maintainers to bring zizmor's anchor support up to full coverage. First, we fixed parsing bugs that caused crashes, produced wrong-location findings, and silently mishandled aliased values. Second, we surfaced deserialization edge cases that broke zizmor on otherwise valid workflows. Finally, we helped align zizmor's expression evaluator with GitHub's own Known Answer Tests. We validated all of this against a new corpus of 41,253 workflows from 6,612 high-value open-source repositories. The result: 20 filed issues, 15 merged pull requests. Building the test corpus To understand how anchors are used in CI today and to stress-test zizmor against the full variety of YAML it encounters in the wild, we built a corpus of real workflows. We used BigQuery's GitHub dataset to identify the 10,000 most-starred repositories created between 2022 and 2025, filtered to the 6,612 that use GitHub Actions, and downloaded every workflow file. That gave us 41,253 YAML files. Figure 1: Building a testing corpus When we ran zizmor against the corpus, it crashed on 45 of the 41,253 workflows. That's a low rate, but each crash means a bug in zizmor. How anchors are used in the wild zizmor's anchor support was deliberately limited, and for good reason. YAML anchors make workflows non-local: an alias defined in one place changes behavior else ## gosentry brings LibAFL-grade fuzzing to Go's native interface DevFeed: [gosentry brings LibAFL-grade fuzzing to Go's native interface]() Original publisher: [Read original article]() Author: "Kevin Valerio" Published: 2026-05-12T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Go Language](), [C++]() Tags: [bug](), [c](), [c-plus-plus](), [cache](), [cli](), [fuzzing](), [go](), [research-practice](), [rust](), [security](), [testing](), [tool-release](), [toolchain](), [tooling](), [vulnerabilities](), [workflow]() ### AI overview Gosentry is a fuzzing-oriented fork of the Go toolchain that retains Go's native fuzzing interface while using LibAFL by default. It adds native struct fuzzing, Nautilus grammar-based fuzzing, additional bug detection, and campaign coverage reporting without requiring existing Go fuzz harnesses to be rewritten. ### Source excerpt Go's native fuzzing is useful, but it stands far behind state-of-the-art tooling that the Rust, C, and C++ ecosystems offer with LibAFL and AFL++. Path constraints are hard to solve. Structured inputs usually need handmade parsing. It doesn't even detect several common bug classes, such as integer overflows, goroutine leaks, data races, and execution timeouts. So to make it better, we built gosentry, a fuzzing-oriented fork of the Go toolchain that keeps the standard testing.F workflow while using a stronger fuzzing stack underneath to tackle those issues. With gosentry, go test -fuzz uses LibAFL by default. It can fuzz structs natively, run grammar-based fuzzing with Nautilus, detect bug classes that it couldn't detect before, and create a fuzzing campaign coverage report in one command. If you already have Go fuzz harnesses, you don't need to rewrite them. Point them at gosentry's binary and you get all of the above through the same go test -fuzz interface, with a few new flags: ./bin/go test -fuzz=FuzzHarness --focus-on-new-code=false --catch-races=true --catch-leaks=true Figure 1: Basic gosentry usage gosentry keeps the harness API and changes the engine and the surrounding tooling -- you just tweak the CLI. You can also generate coverage reports from an existing campaign with --generate-coverage. Run it from the same package with the same -fuzz target, and no corpus path is needed; gosentry stores the campaign state under Go's fuzz cache index by package and fuzz target, so restarting the campaign resumes from the existing corpus. Why we built gosentry We started this project after we released go-panikint to improve Go fuzzing's integer overflow detection. We realized that integer overflow detection wasn't enough. Go's fuzzing ecosystem was still missing techniques that Rust, C, and C++ researchers already use every day. We often faced these gaps in our own security work using Go's vanilla fuzzer: Program comparisons (path constraints) were impossible to solve: ## Escalating a Windows driver registry bug to a kernel write primitive DevFeed: [Escalating a Windows driver registry bug to a kernel write primitive]() Original publisher: [Read original article]() Author: "Graham Sutherland"; "Paweł Płatek" Published: 2026-05-05T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [C++](), [Security](), [Vulnerabilities](), [Code](), [Linux](), [Windows]() Tags: [attacks](), [blog](), [bug](), [c-c-plus-plus](), [c-plus-plus](), [large-language-models](), [linux](), [security](), [testing-handbook](), [vulnerabilities](), [windows]() ### AI overview This Trail of Bits article walks through two C/C++ security challenges: a Linux ping program with command injection and an inet_ntoa global-buffer pointer bug, and a Windows driver registry type-confusion issue that can escalate from local denial of service to a kernel write primitive. It also introduces the c-review Claude skill, which turns the security checklist into platform- and threat-model-aware LLM prompts for finding bugs in codebases. ### Source excerpt We recently added a C/C++ security checklist to the Testing Handbook and challenged readers to spot the bugs in two code samples: a deceptively simple Linux ping program and a Windows driver registry handler. If you found the inet_ntoa global buffer gotcha or the missing RTL_QUERY_REGISTRY_TYPECHECK flag, nice work. If not, here's a full walkthrough of both challenges, plus a deep dive into how the Windows registry type confusion escalates from a local denial of service to a kernel write primitive. Since we first released the new C/C++ security checklist, we also developed a new Claude skill, c-review. It turns the checklist into bug-finding prompts that an LLM can run against a codebase. It's also platform and threat-model aware. Run these commands to install the skill: claude skills add-marketplace https://github.com/trailofbits/skills claude skills enable c-review --marketplace trailofbits/skills The Linux ping program challenge The Linux warmup challenge we showed you in the last blog post has an obvious command injection issue. #include #include #include #include #define ALLOWED_IP "127.3.3.1" int main() { char ip_addr[128]; struct in_addr to_ping_host, trusted_host; // get address if (!fgets(ip_addr, sizeof(ip_addr), stdin)) return 1; ip_addr[strcspn(ip_addr, "\n")] = 0; // verify address if (!inet_aton(ip_addr, &to_ping_host)) return 1; char *ip_addr_resolved = inet_ntoa(to_ping_host); // prevent SSRF if ((ntohl(to_ping_host.s_addr) >> 24) == 127) return 1; // only allowed if (!inet_aton(ALLOWED_IP, &trusted_host)) return 1; char *trusted_resolved = inet_ntoa(trusted_host); if (strcmp(ip_addr_resolved, trusted_resolved) != 0) return 1; // ping char cmd[256]; snprintf(cmd, sizeof(cmd), "ping '%s'", ip_addr); system(cmd); return 0; } There are three validations that have to be bypassed before the system call can be reached with malicious inputs: The inet_aton function "converts the Internet host address from the IPv ## Extending Ruzzy with LibAFL DevFeed: [Extending Ruzzy with LibAFL]() Original publisher: [Read original article]() Author: "Matt Schwager" Published: 2026-04-29T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Fuzzing/Fuzz testing](), [Ruby](), [Rust](), [LLVM](), [Dockerfile](), [Linux](), [Security]() Tags: [application-security](), [complex-systems](), [developers](), [fuzzing](), [linux](), [llvm](), [ruby](), [rust](), [tool-release](), [tools]() ### AI overview The article describes adding LibAFL support to Ruzzy, a coverage-guided fuzzer for pure Ruby code and Ruby C extensions. It covers building LibAFL as a standalone library, integrating it through a Dockerfile, and investigating ELF and linker issues encountered during the integration. ### Source excerpt LibAFL is all the rage in the fuzzing community these days, especially with LLVM's libFuzzer being placed in maintenance mode. Written in Rust, LibAFL claims improved performance, modularity, state-of-the-art fuzzing techniques, and libFuzzer compatibility. For these reasons, I set out to add LibAFL support to Ruzzy, our coverage-guided fuzzer for pure Ruby code and Ruby C extensions. This gives Ruby developers and security researchers access to a more advanced and actively maintained fuzzing engine without changing how they write their fuzzing harnesses. Ruzzy was originally built on top of LLVM's libFuzzer, so using LibAFL's compatibility layer should be easy enough. However, digging around in the internals of complex systems is never quite as simple as it seems. In this post, I will investigate some of the deep plumbing inside these fuzzing engines, take a detour into executable and linkable format (ELF) files, and ultimately add LibAFL support to Ruzzy. Building with libafl_libfuzzer Ruzzy currently supports Linux, so I use a Dockerfile for development and for production fuzzing campaigns. To that end, using a similar Dockerfile for LibAFL support is the simplest integration point. LibAFL provides excellent documentation and build scripts to use it as a standalone library. We need to build LibAFL as a standalone library because Ruzzy uses libFuzzer as a library. Following along with the standalone libafl_libfuzzer documentation, and with the build.sh script in hand, we can build libFuzzer.a. This is the archive that will ultimately be linked into Ruzzy's C extension and used to fuzz our target. Here are the relevant lines from our new Dockerfile: # Install Rust nightly via rustup RUN wget -qO- https://sh.rustup.rs | sh -s -- \ -y \ --default-toolchain nightly \ --component llvm-tools ENV PATH="/root/.cargo/bin:${PATH}" # Clone LibAFL RUN git clone --depth 1 https://github.com/AFLplusplus/LibAFL /libafl # Build libFuzzer.a from LibAFL's libfuzzer runtime WORKDIR ## Trailmark turns code into graphs DevFeed: [Trailmark turns code into graphs]() Original publisher: [Read original article]() Author: "Scott Arciszewski" Published: 2026-04-23T12:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Graphs](), [mutation-testing](), [Claude](), [Code](), [Claude Code](), [test-coverage](), [Tree-sitter](), [Python]() Tags: [ai](), [claude](), [claude-code](), [code](), [graphs](), [mutation-testing](), [open-source](), [python](), [research-practice](), [software](), [testing](), [tool](), [tool-release]() ### AI overview Trailmark is an open-source library that parses source code into queryable call graphs and exposes them through a Python API that Claude skills can call. The article explains how graph-level reasoning can help analyze codebases, triage surviving mutation-testing mutants by security relevance, and support Claude Code skills for tasks such as test vector generation and protocol diagramming. ### Source excerpt We're open-sourcing Trailmark, a library that parses source code into a queryable call graph of functions, classes, call relationships, and semantic metadata, then exposes that graph through a Python API that Claude skills can call directly. Install it now: uv pip install trailmark "Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win." John Lambert's widely cited observation about network security applies just as well to AI-assisted software analysis. When Claude reasons about a codebase, it reasons about lists: findings from static analyzers, surviving mutants from mutation testing, and line-by-line coverage reports. But the question that actually matters is a graph question: can untrusted input reach this code, and what breaks if it's wrong? We built Trailmark to answer that question. It gives Claude a graph to think with instead of a list. We're also releasing eight Claude Code skills we've built on top of it, designed for mutation triage, test vector generation, protocol diagramming, and more. When lists fall short Mutation testing is a great example of a method that benefits from graph-level reasoning. It's one of the best ways to measure test quality. It makes small changes to your source code (e.g., swapping a < for <=, replacing + with -) and checks whether your tests catch the difference. Mutants that survive reveal gaps in your test suite that code coverage metrics might miss. The downside is that a mutation testing run on a real codebase can produce hundreds of surviving mutants of varying significance. This is very much a list. Some surviving mutants are equivalent: the mutation doesn't change the program's behavior because of structural or mathematical constraints that the mutation testing tool can't see. Some are in dead code; some are in error message formatting; some are in the finite field arithmetic that underpins every cryptographic operation in your library. A flat list of surviving mutants doesn't tell you ## We beat Google's zero-knowledge proof of quantum cryptanalysis DevFeed: [We beat Google's zero-knowledge proof of quantum cryptanalysis]() Original publisher: [Read original article]() Author: "Keegan Ryan" Published: 2026-04-17T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Zero-knowledge proof](), [Cryptography](), [Google](), [Vulnerabilities](), [Memory Safety](), [Rust](), [Code](), [Ethereum]() Tags: [code](), [cryptography](), [google](), [memory](), [memory-safety](), [quantum](), [rust](), [vulnerabilities](), [zero-knowledge]() ### AI overview Trail of Bits presents a zero-knowledge proof that improves on Google's reported resource bounds for quantum circuits. The article attributes the result to memory-safety and logic vulnerabilities in Google's Rust prover code, explains the zkVM-based proof setup, and describes the released proof-forging code. ### Source excerpt Two weeks ago, Google's Quantum AI group published a zero-knowledge proof of a quantum circuit so optimized, they concluded that first-generation quantum computers will break elliptic curve cryptography keys in as little as 9 minutes. Today, Trail of Bits is publishing our own zero-knowledge proof that significantly improves Google's on all metrics. Our result is not due to some quantum breakthrough, but rather the exploitation of multiple subtle memory safety and logic vulnerabilities in Google's Rust prover code. Google has patched their proof, and their scientific claims are unaffected, but this story reflects the unique attack surface that systems introduce when they use zero-knowledge proofs. Google's proof uses a zero-knowledge virtual machine (zkVM) to calculate the cost of a quantum circuit on three key metrics. The total number of operations and Toffoli gate count represent the running time of the circuit, and the number of qubits represents the memory requirements. Google, along with their coauthors from UC Berkeley, the Ethereum Foundation, and Stanford, published proofs for two circuits; one minimizes the number of gates, and the other minimizes qubits. Our proof improves on both. Resource Type Google's Low-Gate Google's Low-Qubit Our Proof Total Operations 17,000,000 17,000,000 8,300,000 Number of Qubits 1,425 1,175 1,164 Toffoli Count 2,100,000 2,700,000 0 Table 1: Resource upper bounds reported in different proofs for circuits computing the correct output across 9,024 randomly sampled inputs Our proof fully verifies when using Google's unpatched verification code. It has the same verification key as their original proofs and is cryptographically indistinguishable from a zero-knowledge proof resulting from actual algorithmic improvements to the quantum circuit. We are releasing the code we developed to forge the proof, and a summary of our proof follows. Circuit SHA-256 hash: 0x7efe1f62bb14a978322ab9ed41d670fc0fe0f211331032615c910df5a540e999 Groth16 pr