When the model finds the bug

Two and a half weeks ago, Anthropic published a piece on its Frontier Red Team blog describing what an internal preview model called Claude Mythos has been doing for the past few weeks. The headline numbers are now public: thousands of zero-days across every major operating system and every major browser, a 27-year-old TCP SACK bug in OpenBSD, a 16-year-old H.264 vulnerability in FFmpeg that survived five million fuzz hits, fully autonomous Linux kernel privilege escalation chains, a working remote-root exploit against FreeBSD’s NFS server (CVE-2026-4747), and 271 vulnerabilities in a single recent Firefox build.

Anthropic has been straightforward about the implication: this is a different kind of threat surface. Mythos isn’t a clever fuzzer or a YARA rule. It reads code the way a senior reverse engineer reads code, hypothesises bugs, runs the target, refines the hypothesis, and writes a working proof of concept — at a unit cost measured in tens of dollars and a wall-clock cost measured in hours. The 27-year-old OpenBSD bug cost under fifty dollars to find.

We build PostQ. We are a post-quantum cryptography control plane: the scanner, the hybrid signing API, the policy engine, the SDKs, the CLI. So we are going to talk about Mythos from a fairly specific angle — not the whole frontier-AI security debate, which is being covered well elsewhere, but the part of it that lives squarely in our lane: the cryptography in your stack.

The honest version is that PostQ does not stop Mythos. Nothing stops Mythos. What PostQ does is shrink the part of your attack surface that Mythos — or any of the models that come after it — can productively chew on, and give you the operational tooling to react quickly when something does land. That is a meaningful distinction, and it’s the one this post is about.

The category nobody is talking enough about: cryptography libraries

Buried halfway down the Frontier Red Team writeup is a section called “Cryptography Libraries”. It is short, and it is the part of the post we have re-read the most. The quotable line:

“Mythos Preview identified a number of weaknesses in the world’s most popular cryptography libraries, in algorithms and protocols like TLS, AES-GCM, and SSH. These bugs all arise due to oversights in the respective algorithms’ implementation that allows an attacker to (for example) forge certificates or decrypt encrypted communications.”

The one finding from that section that is already public is a critical certificate-validation bypass in Botan (GHSA-v782-6fq4-q827). Botan is not an obscure library. It ships with OpenBSD, it’s embedded in industrial-control kit, it backs a long list of TLS implementations and HSM integrations. A certificate-authentication bypass in a library at that level of the stack is the kind of bug that, in pre-Mythos timelines, gets a conference talk written about it. We now expect several more like it per quarter.

Anthropic has committed SHA-3 hashes for two further crypto-library findings that aren’t yet patched, so we don’t know what they are. But the public Botan bug is a useful prior. Cryptography libraries are exactly the codebases Mythos-class models are best at: small, dense, heavily-spec’d, with a long history of subtle implementation errors that sit in published RFCs. They are the inverse of the “million-line web framework” problem where the model has to do real architecture inference. A modular inverse, a constant-time comparison, a length check on a length-prefixed field — these are exactly the bug shapes a large language model can reason about end-to-end without losing the thread.

And the consequences of getting them wrong are wholesale, not retail. A bug in your front-end React component leaks one user’s data. A bug in your TLS stack’s certificate parser changes who, on the entire internet, your servers will trust.

What “Harvest Now, Decrypt Later” looks like in a Mythos world

Before Mythos, the post-quantum migration story had a comfortable rhythm to it. NIST ran a competition, finalized FIPS 204 (ML-DSA), FIPS 203 (ML-KEM), and FIPS 205 (SLH-DSA), and the conversation among architects shifted from “will quantum break this” to “when do we have to be done”. NIST’s draft IR 8547 transition timelines and CISA’s quantum guidance told you the answer: deprecate classical signatures and key exchange by 2030, disallow them by 2035.

The threat model behind those dates was “Harvest Now, Decrypt Later” (HNDL): an adversary capturing TLS sessions today and decrypting them when a cryptographically-relevant quantum computer eventually exists. That model assumes a patient attacker with a long time horizon and a known terminal capability.

Mythos doesn’t change the quantum part of that equation, but it does change the “patient” part. The same posture that left a quarter-century-old TCP SACK bug in OpenBSD is the posture that leaves a half-implemented constant-time check in a TLS stack, or a buggy ASN.1 parser in a certificate library, or a missing tag-length validation in an AES-GCM implementation. Those bugs don’t need quantum computers to be catastrophic. They are catastrophic right now, and a Mythos-class model can find them at a unit cost the offensive side has never seen before.

So the practical effect of Mythos on the PQC roadmap is not “move faster because quantum is sooner”. It is: the period during which classical cryptography is still in production is a period during which classical cryptographic implementations are getting hammered by automated zero-day discovery. The migration window got more dangerous, not just longer.

What we built PostQ to do, restated for this moment

PostQ has three product surfaces: a scanner, a hybrid signing API, and a policy engine. The pitch we’ve been giving for those three pieces, even before Mythos was a public name, was “reduce the half-life of bad cryptography in your environment”. That sentence ages well.

The scanner: knowing what you actually have

The first thing every defender we’ve talked to since the Mythos announcement has wanted is a current, machine-readable answer to a deceptively simple question: which cryptographic primitives are live in my production right now, and where? Not what your architecture diagram says. What an actual TLS handshake says.

The PostQ scanner (available as a hosted web tool, a 2 MB Go CLI, and an in-cluster agent) does that the boring way: real TLS handshakes, full certificate-chain walks, key-algorithm and signature-algorithm inventory, KMS enumeration across AWS, Azure, and GCP, and a static pass over source for hardcoded RSA keys, MD5 hashes, and the SSH configs everyone has forgotten about. It produces a single machine-readable inventory: this endpoint is RSA-2048 signed by SHA-256-RSA, that KMS key is ECDSA-P256, this Helm chart bundles a 1024-bit DH parameter file from 2014, and so on.

Why this matters in the Mythos era is straightforward. The first thing you need when a new critical CVE drops in a crypto library is to know whether you ship that library, and on which surfaces. The gap between “Botan released a security advisory” and “our SRE team knows which seventeen services in our fleet link Botan and which two of them terminate TLS” used to be measured in days. In the new patch-cycle reality Anthropic itself is asking the industry to plan for, that gap needs to be measured in minutes. A live cryptographic inventory is the prerequisite for everything else.

Hybrid signing: not betting the farm on one algorithm

The second surface is the hybrid signing API. You sign once and get back a composite signature: classical (Ed25519, ECDSA-P256, or RSA depending on what you’re interoperating with) and a NIST-standardized post-quantum signature (ML-DSA from FIPS 204, optionally SLH-DSA for hash-based defence-in-depth). The verifier requires both to be valid.

The standard story for hybrid is “quantum hedging”: if one of the two algorithm families is later found to be broken, the other still holds. That’s true. The Mythos-shaped story is the same property applied at a different timescale: if a Mythos-class model finds a critical implementation flaw in your ECDSA stack tomorrow, your hybrid signatures still verify. If it finds one in your ML-DSA stack a week later, your classical signature still binds. You have rotated the failure mode of a single library bug from “every artifact you’ve ever signed is suspect” to “the verifier policy temporarily relaxes the broken half while you patch”.

That’s a fundamentally different operational posture than single-algorithm signing, and it’s the posture you want when the people writing your cryptography library and the people writing attacks against it are both, increasingly, the same kind of model.

The policy engine: pulling the lever fast

The third surface is the PostQ policy engine: centralized rules about which algorithms, key sizes, certificate chains, and signature suites are acceptable across your stack, and the runtime hooks (sidecar, SDK middleware, agent) that enforce them. “No new RSA-2048 endpoints in production”. “Reject any certificate signed with a SHA-1 anywhere in the chain”. “Require ML-DSA on every artifact uploaded to the release bucket after May 1.”

Anthropic’s own advice to defenders is pointed: shorten your patch cycles, tighten your enforcement windows, treat dependency bumps that carry CVE fixes as urgent. That advice is correct, and it’s also unsatisfying without machinery to back it up. Pulling a known-bad cryptographic primitive out of a fleet of services in under an hour is not a thing humans can do reliably. It is, however, exactly the thing a centrally enforced cryptographic policy can do, because the work is changing one rule and letting the runtime hooks reject everything else.

The same policy engine handles the boring everyday case too — you set “all new internal services must use hybrid signing” once, and the gradient toward post-quantum posture happens automatically as services ship. But the tail-risk case — “a CVE just dropped against the X25519 implementation in our SDK, kill it now everywhere” — is where it earns its keep.

The case studies, mapped to PostQ

It’s easy to talk about all this in the abstract. Anthropic gave us actual case studies, so let’s walk three of them and be honest about which parts of the picture PostQ touches and which parts it doesn’t.

Case 1: the OpenBSD SACK bug

The 27-year-old TCP SACK vulnerability is a remote denial-of-service against any OpenBSD host responding over TCP. It’s a kernel networking bug, not a cryptography bug. PostQ doesn’t find it, patch it, or mitigate it. We are not going to pretend we do.

What PostQ doesdo, in the same neighborhood: when this class of bug lands and an emergency patch reboot rolls through your fleet, the certificates being re-issued and the keys being rotated during that mass-rotation event will frequently get re-issued carelessly. We have watched teams rotate hundreds of certificates in an afternoon, and end up with a small but nonzero count signed by weaker chains than the ones they replaced. The scanner’s job is to tell you when that happens; the policy engine’s job is to refuse to accept the bad reissues in the first place.

Case 2: the Botan certificate authentication bypass

This is the one that’s squarely in our lane. A certificate-validation bypass in a widely-deployed cryptography library means a class of TLS connections your services thought were authenticated were not. There are three things you want from your tooling the moment that advisory drops:

1. An inventory query that takes seconds, not days. “Which of my services link Botan, and at what version?” The PostQ scanner’s static pass and KMS enumeration answer this directly; the in-cluster agent answers it for everything behind a service mesh.
2. Defence in depth on the signatures themselves. If your release artifacts are hybrid-signed, an attacker who can briefly forge classical certificates against your CDN still cannot forge a valid ML-DSA signature on a binary. The blast radius of the certificate bypass shrinks from “serve arbitrary content” to “serve content the verifier still rejects”.
3. A policy lever you can pull globally. “Block all certificate chains validated by Botan < 3.x.y” should be one rule change, not a rolling deploy across forty services.

This is, concretely, the workflow PostQ was designed for. We’d rather not have a market reason to keep building it. We do.

Case 3: the FreeBSD NFS RCE (CVE-2026-4747)

Mythos turned a 17-year-old stack overflow in FreeBSD’s NFS server into a full unauthenticated remote-root exploit. Like the OpenBSD case, this is a kernel bug; PostQ doesn’t find it. But it’s a useful reminder of one thing: the exploit chain uses the host’s public key material (its UUID, derived hostid, and nfsd start time) to defeat a defence-in-depth check. Predictable, long-lived host identifiers are no longer a free design choice. PostQ’s scanner already flags long-lived machine certificates with weak entropy in their identifiers; in the next release we’re extending that to NFS, SMB, and Kerberos host keys specifically because of this CVE class. We’ll write that one up separately.

A short, candid note on what we are and aren’t claiming

We don’t want to oversell this. PostQ is a cryptographic control plane. It is not a SAST suite, not an EDR, not an incident-response platform, and not an answer to the broader question of how the security community absorbs the next several quarters of Mythos-class output. The list of things we don’t help with after a Mythos disclosure is genuinely long: kernel memory-safety bugs, browser sandbox escapes, JIT-spray exploits, web-application logic flaws. The Project Glasswing partners are better placed for most of those — CrowdStrike, AWS, Microsoft, Palo Alto Networks, and the Linux Foundation are all already publishing concrete plans on those fronts.

Where we will plant a flag: cryptographic exposure is one of the few security domains where the right answer is already written down. The algorithms are standardized. The migration patterns are well-understood. The hard part has always been operational: knowing what you have, getting the new primitives wired into your build pipelines, and being able to pull a single lever when something breaks. Mythos compresses the timeline on every one of those operational tasks. PostQ exists to make those tasks cheap enough to do at the new tempo.

Where the industry is going

Anthropic’s own framing is that the long-run equilibrium favours defenders — that the same capabilities that let Mythos find subtle bugs also let it patch them and write better code in the first place. That’s the bet behind Project Glasswing, and we share it. The DARPA Cyber Grand Challenge a decade ago made roughly the same prediction about autonomous patching, and the trajectory since then has been broadly encouraging.

The transitional period — the next twelve to twenty-four months — is going to be uncomfortable. The defenders who come out of it in good shape will be the ones who treated cryptographic agility as table stakes rather than as a long-horizon project. The historical analogues are good: NIST launched the SHA-3 competition in 2006 with SHA-2 still unbroken, and the post-quantum effort formally began with NISTIR 8105 in 2016, more than a decade before fault-tolerant quantum hardware looked credible. Both decisions look obvious in retrospect. The decision to build cryptographic agility into your stack now, before a Mythos-class model finds the bug that forces you to, is the same kind of obvious-in-retrospect call.

What we’re shipping in response

A few concrete commitments from our side over the next few weeks:

• Faster scanner cycles. We’re moving the agent’s default sweep interval from 24 hours to 4, and adding push-based re-scan triggered by CVE feeds (NVD plus the GitHub advisory database). When a Botan advisory drops, your inventory should reflect it before your on-call sees the email.
• SLH-DSA in hybrid signing. We already support ML-DSA for the post-quantum half of hybrid signatures. We’re adding FIPS 205 SLH-DSA as an option for callers who want a hash-based fallback, specifically for the “Mythos finds an ML-DSA implementation bug” failure mode. Slow but conservative; the right primitive when conservatism matters more than throughput.
• Per-library policy rules. Today the policy engine reasons in terms of algorithms and key sizes. We’re extending it to library identity and version, so “reject anything terminating TLS through Botan < 3.x.y” is a one-line policy rather than a scripted workaround. The recent Botan advisory was the trigger; we suspect it won’t be the last of its kind this year.
• CVE-aware exit codes in the CLI. The PostQ CLI already exits non-zero on Critical and High findings. We’re adding a separate exit code for “a cryptography library you depend on has an open advisory that matches your fingerprint”, so CI gates can distinguish “new bad crypto introduced” from “old crypto just became bad”. Different humans should be paged for those two cases.

None of these are revolutionary. They are exactly the boring, operational improvements the moment calls for. The Mythos era is not going to be won by clever new primitives; it’s going to be won by the teams that can move from “advisory published” to “safely no longer affected” in a single working day, on repeat, for years.

The closing thought

We are sympathetic to the impulse to look at the Mythos numbers and conclude that the entire defensive game has changed. In some sense it has. But the part of the game that’s in our lane — knowing your cryptographic posture, having defence in depth on your signatures, and being able to evict a primitive from production at short notice — was already changing for other reasons. NIST published the post-quantum standards. The 2030/2035 deprecation deadlines were already on the calendar. The control plane needed to exist regardless.

Mythos just made the case more urgent, and made it harder to put off. If you’ve been treating cryptographic agility as a 2027 project, it isn’t one anymore. Talk to us if you want to compare notes on what your environment looks like. We’re running the scanner against every Project Glasswing partner’s public TLS surface as a free benchmark; happy to share what we’re seeing.

Further reading: Anthropic’s full Mythos Preview writeup on the Frontier Red Team blog, the Project Glasswing announcement, VentureBeat’s playbook piece, Ars Technica’s Firefox findings, and SecureWorld’s industry summary.