The Register asked for my opinion on the Mozilla blog post that pumps up Mythos. I gave them a short answer. Here’s the long form.

As a disinformation historian, I see tell-tale signs in the marketing from Mozilla beyond it just being disguised as engineering report. A conclusion comes first; examples get curated to support it; an authority signs; urgency closes; whatever would falsify has been pushed off the table to the floor.

To be fair, modern marketing follows the same shape as disinformation because they are rooted in the same thing in America, the WWI propaganda office. Mozilla’s new post on hardening Firefox with Claude Mythos Preview adheres to doctrine at length.

A marketing claim would be that you cannot run a mile under six minutes without drinking Coca-Cola. Then a sponsored athlete says they just did it. Compare that with measurement, which would say before Coca-Cola the athlete ran six minutes and after Coca-Cola, five. One is just a reading, a belief. The other is research, science.

The fundamental problem with the Mozilla post is that logically it keeps stabbing itself with its own swordplay. There are three claims that all need to stay alive at the same time for the post to make sense, and yet they are in danger of killing each other.

1. Security work over time has been rigorous.
2. 271 latent bugs survived it.
3. Mythos was uniquely necessary to surface them.

Any two of these break the third.

If prior work was rigorous and 271 bugs survived, the bugs were findable under concentrated effort with existing tools. Mythos drops to one option among several. The uniqueness claim falls.

Try betting on rigor with uniqueness instead, and the marginal yield should be small. 271 is far past small. The rigor claim breaks.

If you try to read prior work as inadequate, the 271 fits. The post becomes a rebranding of old underinvestment as new capability. And the whole framing collapses.

The chart in the post shows this three-way collision. Twenty to thirty fixes per month for fourteen months, then suddenly 423. The prior baseline represented either diligent attention or sustained underinvestment. April’s number forces a big choice, an explanation, and the post avoids it entirely. It lays on the floor.

Let’s look at it from the top down. The post opens by naming exactly two causes for the breakthrough.

First, the models got a lot more capable. Second, we dramatically improved our techniques for harnessing these models.

Two, not one. Two.

A real finding would next isolate which of these produced which effect. Mozilla names two causes and then jumps straight to attribution of the single result to just one of them. 271 bugs, credited to Mythos Preview. No explanation why. Mozilla built the harness. Anthropic gets the credit. Something isn’t right there, particularly because the harness could in fact be the entire difference in findings. The post rules out clean attribution in its opening and then drops a dirty one as its headline.

Next, Mozilla admits Opus 4.6 was already producing in the same pipeline. This is one of the most important facts that needs to be highlighted in every conversation about Mythos.

We began with small-scale experiments prompting the harness to look for sandbox escapes with Claude Opus 4.6. Even with this model, we identified an impressive amount of previously-unknown vulnerabilities.

A controlled comparison would specify the Opus 4.6 baseline and then move towards Mythos as a delta. Mozilla published the Mythos number and left the baseline blank, a propagandist wave of the hand. The marginal contribution of Mythos over Opus 4.6 sits unstated. And if you read the Anthropic initial Mythos announcements, even they suggest Sonnet and Opus were doing far better discovery, leaving Mythos to a marginal, minor role. We have Mozilla floating 271 in the air without any way to get it to ground truth.

And then Mozilla admits the model itself is fungible.

Once the end-to-end pipeline is in place, it’s trivial to swap in different models when they become available.

Ok, ok, this is actually a huge swipe at Anthropic. Different models doesn’t specify same provider. Agnosticism crept into a religious tome, because users naturally want to be free of vendor lock-in. If models swap into a Mozilla security pipeline freely, then the most important variable is that pipeline and not the model. Mozilla built the thing that hooks into any model. The post then sleepwalks into credit for the model. That allocation of credit runs against the post’s own technical claim.

At this point, I’m ready to shred the Mozilla post, open the chicken coop and put down some new bedding. However, dear reader, apparently their show must go on and so I present you another logic flaw.

AI analysis provides much more comprehensive coverage of this critical surface.

More comprehensive than what, exactly? That’s a comparison statement without any comparison. Eating your shoe provides much more fiber for your belly. I fear the people writing never took a philosophy 101 course. The post gives literally no elements needed to stand up the comparison. This bomb of a sentence is dropped with the form of a finding, and lands a dud, with the content of an assertion.

Then comes the big closer.

Anyone building software can start using a harness with a modern model to find bugs and harden their code today. We recommend getting started now.

Research papers invite you to try to reproduce, validate, see if you get the same outcome. Replication is satisfying to those who want more than “believe me, this snake oil really cures you”. Sales pitches close deals. The Mozilla post shouldn’t fool anyone familiar with America’s troubled history with carnival barkers.

Mozilla makes a particularly troubling move at this point. They try to spin their empty narrative into an industry standard, which smells yet again like Anthropic trying to corner the security industry. Best-practice claims by a vendor and a big customer of their should not suddenly become liability baselines. A team running libFuzzer, AddressSanitizer, ThreadSanitizer, and CodeQL at full intensity should not face presumptive negligence claims if a bug surfaces that one VC-backed PE-pushed vendor’s harness might have caught. If you link the bar to rhetoric, you get a rhetorical bar detached from engineering ethics. That is regulatory capture by a vendor making a self-fulfilling recommendation to preempt regulation, let alone legislation. Belief is produced and weaponized into liability.

It’s like how Coca Cola ran marketing that was effectively “Drink Fanta for health” in Nazi Germany as if not drinking it was unhealthy.

A better Mozilla report would have run Mythos and existing tooling head-to-head against the same code, then published the overlaps and the unique finds.

Mozilla published a 1940s Fanta health benefits brochure instead.

To be clear. Real bugs are real. Faster fixes help fix. It’s the hand-wavy self-dealing capability claim that makes the missing study somehow turn into this logically flawed press release.

Science publishes methods. Science is transparent. Mozilla did the opposite by writing outcomes and skipping straight to saying readers should adopt the approach. Why? Based on what, exactly? If they don’t invite scrutiny, and pull back the curtain, they are peddling hopes and prayers.

And given that Anthropic is saying customers will now have their data handed over to Elon Musk, I suggest you seriously consider whether you want any of if in his Hitler-saluting hands.

Sponsored athlete crosses the finish line and holds up the Fanta bottle. The camera zooms in close, frames the Nazi regime refreshment as a cause of great success. The control case is cut out of view, after running in the next lane without the logos. Jesse Owens posts a time far better than the uber Fanta man. The authority-controlled frame chooses for you which curated data point gets pushed to your attention.

Github has a serious breach problem. Someone pointed me to a repo called ClawCode and immediately I saw the telltale signs of an integrity breach. It has 187k stars against 0 releases, 0 packages, 0 visible contributors, and a deprecated crates.io stub that redirects elsewhere. Inflated social proof on a shell means the repo is nothing more than hot air, an attention seeking circus act. They used AI to write a Rust CLI that calls the Anthropic API, and branded it to ride Claude Code’s name recognition.

Paper Claw is more like it. It’s the same github “star” fraud pattern I already called out with OpenClaw. And I have to point out Dr. Seuss warned children about exactly this a long time ago. We have no excuses for rewarding “star” systems being simplistically gamed by charlatans. OpenClaw shipped on November 24, 2025 and the measure of what really matters since then is not stars. It has accumulated 433 published CVE records in just five months, which works out to a stunningly high disclosure rate of roughly 2.6402439 security failures per day. Call it three strikes every day, give or take. Has any software ever been this bad?

We’re talking AI “vibe” coding here so the machines pump out a patch cadence to try and pace with the mistakes reported against what they just made, which is what circular speed metrics measure when the codebase produces vulnerabilities this fast.

More tokens! More code! More spend! Worse software.

Four of the five modes of failure that recur have received targeted fixes. The fifth, route-level authorization, clearly regenerates itself in every new platform integration. The shipping defaults, as bad as they are, also persisted unchanged through the fixes. To put it another way, an unbelievable 63 percent of internet-reachable instances of OpenClaw run with authentication disabled today and I’m not seeing any effort to improve.

Authentication disabled by default on “personal” data management, folks.

In 2026.

The stupid, it burns. OpenClaw looks seriously cooked. Next thing you know, someone will tell me they have authentication disabled on the OpenClaw controlling their Tesla, as if nobody on the Internet is going to inject prompts to drive them off a cliff? Then again, since 2013 on this blog I have said Tesla is cooked and by 2016 I had been warning for years it would kill a lot of people, and look at how that turned out.

So please don’t take my word for how bad this is, again. Look at the numbers yourself, with all the denominators. Anthropic hasn’t cornered the market on vulnerabilities yet, to turn safety work into a proprietary rate-based secret, so I offer you here an OpenClaw flaw transparency report.

The cvelistV5 directory holds 413 PUBLISHED records that name OpenClaw as of the 2026-05-06 corpus snapshot at jgamblin/OpenClawCVEs. The live counter called days-since-openclaw-cve.com reads 433 accumulated, against a project that first shipped 164 days ago. That’s just wild! It’s perhaps the worst software ever released in history. Of the 413 in the analytical snapshot, 376 sit under VulnCheck as the assigning CNA, 34 under GitHub_M, and 3 under MITRE.

If you know the story of the Vasa, you know what I’m talking about here. It was Sweden’s flagship trying to claim most heavily armed warship in the world at its August 1628 launch, with 64 bronze cannons across two gun decks. King Gustavus Adolphus pushed for a second gun deck, the master shipwright died mid-build, the stability tests failed and were ignored, the ship sailed 1300 meters and capsized on its maiden voyage without even leaving the Stockholm harbor.

It was the definitive OpenClaw buzz of 1628. Not to get too deep into history here, technically the Vasa was a state propaganda ploy under a monarch who needed a Baltic war splash. Today’s “viral consumer launch” looks to me like NVidia and OpenAI leaders rushing into another Vasa splash… but I digress.

The GitHub Advisory Database holds 113 GHSAs for the project. 39 of those carry CVE IDs and are visible in NVD. 74 remain unassigned. There are six BlueBubbles records, for example, that appear in cvelistV5 without GHSA narrative.

That gives us a working population for category analysis of 119 advisories.

CWE and CVSS metadata is fully populated on the 39 published-with-CVE subset. The 74 unassigned GHSAs carry CWE labels but lack a CVSS string. The cvelistV5-only records carry CWE plus CVSS without GHSA discussion threads. That means my analysis of the CVSS distribution below uses the 39 records, while analysis of the CWE category uses the 119 records. It’s a messy business yet we still see insights.

Since the public counter at days-since-openclaw-cve.com tracks the longest CVE-less streak (12 days, between February 7 and February 18, 2026) I figure I should look at that first. Inside the 39 subset, the gap from the fix release to advisory publication has a range from 0 to 13 days. Sometimes the GHSA goes out the same day the patch ships, sometimes it trails by two weeks. A patch turnaround like this is measuring how the project runs its robots. Far more interesting is the uptake numbers, which unfortunately read very different as I’ll explain in a minute.

The GHSA timeline splits into two clear groups. Between February 17 and 18 there were 11 advisories from a small group of researchers. Then on April 17 suddenly 39 GHSAs appeared in just one day, of which 24 received CVE IDs through VulnCheck. The NVD publications followed in waves. April 28 carried 11 CVEs into NVD, using the GHSAs published April 24 and 25. May 5 published another 25, all but one coming from the April 17 batch.

VulnCheck, a CNA broker, has been the assigner on 376 of the 413 cvelistV5 records. The reporter line on 11 of the 24 with-CVE entries from April 17 lists zsxsoft and KeenSecurityLab paired together, with the same pair extending across the broader April 17 batch. Across all the April advisories, I found 21 distinct credit logins. February had just 9, which led me to realize the credit count right now vastly overstates the discovery population. When you factor in qclawer, it collapses into a pattern.

A GitHub user named qclawer (id 274765497) created a profile on 2026-04-09, last updated eight days later. The account holds no commits, no other repository activity, no other public artifacts. Inside the GHSA system, qclawer appears as credit-type tool, which the GHSA pipeline auto-maps to the sponsor credit category. Notably, 20 GHSAs fall under this credit, while 11 of those 20 still have no CVE ID.

It looks to me that KeenSecurityLab was setup as a placeholder organization. The pairing of zsxsoft, a previously published researcher, with KeenSecurityLab on 24 GHSAs is a single human driving an automated tool. The 21 credit logins in April look like the resultant robot output surge. There is one tool, one triager, with a credit field filled in simply to satisfy the GHSA submission schema. That’s how the April 17 batch reads to me like a single dumpster, not 39 independent discoveries.

The Five “Flobster” Failures: An architectural swing and a miss

Over 100 advisories, five types

1. Trust-boundary collapse (47 advisories). Webhook authenticity, message platform allowlists, and identity validation across direct-message and group context. CVE-2026-25474 covers a missing Telegram webhook secret that allowed unsigned event injection. CVE-2026-22172 records a WebSocket scope elevation in shared-token connections, where the gateway accepted whatever scope the client claimed. CVE-2026-32987 documents a bootstrap pairing replay against the device pairing flow. Webhook signature verification, scope binding to the authentication token, and pairing nonce checks are first-week design decisions for a multi-platform agent gateway. The codebase shipped without them.
2. Authorization scope (41 advisories). Route-level authorization gaps for already-authenticated callers. CVE-2026-32916 covers synthetic admin scopes through plugin subagent routes. CVE-2026-35639 covers scope validation on the device.pair.approve path. CVE-2026-42434 covers sandboxed agents escaping exec routing through a host=node override. The shared anti-pattern is client-declared authorization. The route accepts a scope label from the caller and treats that label as the policy decision, with no server-side check that the principal is entitled to operate at that scope. This is the one that regenerates with every new platform integration.
3. Exec-boundary injection (18 advisories). Shell, environment, and file-path injection into command construction. CVE-2026-25157 records OS command injection through the project root path in sshNodeCommand. CVE-2026-32917 records remote command injection through unsanitized iMessage attachment paths in SCP. CVE-2026-27487 records shell injection in the macOS keychain credential write path. argv-mode subprocess invocation is the documented default in both Node and Python and avoids this entire category. The codebase used string concatenation into shell commands.
4. Control-plane exposure (10 advisories). Unauthenticated network surfaces that assumed loopback-only delivery. CVE-2026-28485 records missing authentication on Browser Control HTTP endpoints. CVE-2026-28458 records the Browser Relay /cdp websocket missing auth, allowing cross-tab cookie access. CVE-2026-26317 records CSRF on loopback browser mutation endpoints. The assumption embedded across this bucket is that localhost binding is itself an authentication boundary. SecurityScorecard’s STRIKE team has identified 42,900 instances where it never was, because the listener defaults extended past loopback to public addresses.
5. LLM-surface (3 advisories). Prompt-injected execution paths that route model output back into host operations. CVE-2026-24764 records remote code execution through system prompt injection in Slack channel descriptions. CVE-2026-43534 records agent hook events that accept unsanitized external input as if it were a trusted system signal. CVE-2026-43533 records arbitrary local file read through QQBot media tags. This bucket sits inside what Simon Willison calls the lethal trifecta. The architecture consumes model output as a control signal.

Based on these five, now look at the disconnection from CWEs.

CWE-862 (Missing Authorization) and CWE-863 (Incorrect Authorization) carry the largest counts in the published-with-CVE subset, with 10 instances of CWE-863 alone. They sit across multiple instances.

The same CWE-862 label covers a webhook with no authentication at all (CVE-2026-43572 on the Microsoft Teams SSO invoke handler), an authorization function that returned the wrong sentinel for empty approver lists (CVE-2026-43574), and a route that included untrusted workspace plugin shadows in catalog lookups (CVE-2026-43571). Three architecturally distinct surfaces collapse into one taxonomic bucket. The CWE label describes how the authorization layer failed, with no purchase on why each surface needed its own handwritten check in the first place.

CWE-770 (Allocation of Resources Without Limits or Throttling) is cleaner. All four CWE-770 cases in the corpus map to trust-boundary collapse: webhook bodies, base64 media decoding, archive extraction, voice-call WebSocket frames. CWE-829 (Inclusion of Functionality from Untrusted Control Sphere) is also clean: workspace .env files, MCP stdio environment loads, plugin shadow loads. The taxonomy works when the underlying flaw is narrow. It collapses when the underlying flaw is “this surface was built to take adversarial inputs as policy decisions”.

There also was a large notable shit, oops, I meant shift from February to April.

The February cluster is dominated by platform-surface bugs. Stored XSS in the control UI. Command injection in shell construction. Missing webhook secrets. CSRF on loopback endpoints. The upstream fixes for these are bounded. The loopback HTTP server got an authentication requirement in 2026.1.29. The shell wrapper moved partway to argv-mode. The webhook handler picked up a required signing secret on the platforms where users complained loudest. Once the upstream patch landed, that specific bug stopped reappearing.

The April cluster, however, is dominated by route-level authorization failures across plugin subagent endpoints, device pairing, scope claim parsing, and channel-specific permission boundaries. New platform integrations ship with route-level authorization checks that have to be written by hand. QQBot, Matrix, Microsoft Teams SSO, Synology Chat, Nostr, voice-call WebSocket, Discord events, BlueBubbles. The integration count is the bug count. Each surface carries its own scope schema and validation logic, written from scratch on the project side, then surfaced months later by automated discovery on the researcher side. The maintainer reads patches and ships fixes. Plugins ship faster than either side can catch up.

That suggests the February-shape bugs were addressable with a targeted fix, while April-shape bugs were reproduced with the next plugin. That’s just patching logic. Far more dangerous is that neither matters to the 63 percent of running instances that never enforced authentication in the first place and probably have no idea in how much danger they are.

The architectural picture so far has described the flaws in a deeply troubled codebase. When we shift our gaze to the deployment ecosystem, it gets much worse. Bitsight’s late-January scan found over 30,000 exposed instances. SecurityScorecard’s STRIKE team raised that to 42,900 by February 9, with 15,200 directly vulnerable to RCE at that snapshot. The Register reported 135,000 plus by February 12, of which 63 percent ran with no authentication layer. Infostealer families now ship with OpenClaw configuration paths in their target lists.

ClawHub, the project’s package registry, within the first six weeks became a malware distribution channel. Koi Security’s early-February audit of 2,857 skills flagged 341 as malicious, with researcher Oren Yomtov tracing 335 of the 341 to a single coordinated campaign tagged ClawHavoc, primarily delivering Atomic macOS Stealer. Kaspersky‘s coverage in the same window described an earlier figure of around 230. By mid-February, VirusTotal Code Insight reviews of more than 3,000 skills produced hundreds of flags. By March, the working figures sat near 900 across an expanded registry, per Bitdefender estimates. The publication threshold for any skill at the time was a GitHub account at least one week old.

How such predictable harm to the market and users is still legal, I’ll leave the lawyers to figure that out.

[OpenClaw] coughed it all up… “all of her API keys, all of her usernames and passwords, and pretty much everything we’d been talking about so far. Not only did she leak it on the WhatsApp group, but she put it on a publicly available website.”

Maginnis added: “There’s this thing with AI called the lethal trifecta, which is: if they’ve got access to private information, if they’ve got internet access, and if someone can give them an instruction that’s untrusted, then they’re not safe.”

…that is the uncomfortable bit of this because once an agent has your passwords and your accounts and your bank details, all it takes is someone who knows what to say.”

Ultimately, by some metrics, the agent was a failure. Fry concluded: “[OpenClaw] didn’t make us any money at all. And, in a lot of ways, she was a disaster. She spent hundreds of dollars on paper clips and leaked our passwords to a total stranger.

Oasis Security documented an attack chain that gives any visited website silent full control over a developer’s running OpenClaw agent, with no plugins, extensions, or user interaction. The chain combines brute-forceable localhost auth, an auto-approving pairing flow, and the gateway’s loopback-trust assumption. SonicWall Capture Labs published a single advisory and detection signatures for CVE-2026-25253, the gatewayUrl auth-token-exfiltration RCE. Microsoft‘s Defender Security Research Team has stated OpenClaw should be treated as untrusted code execution with persistent credentials and is unsuited to a standard personal or enterprise workstation.

I guess I could go on, but OpenClaw is so cooked it’s become an embarrassment to engineering, an indictment of the lack of a code of ethics that would prevent slop and taint from collecting “stars” as the only measure of success.

The deployment problem is a real problem. Detecting OpenClaw is becoming like detecting any malware. Focusing on forcing a signed release that fixes the next route-level authorization bug still doesn’t get us out of the doghouse of running instances exposed to exploitation. The malicious skills already installed sit underneath that, having modified the persistent memory files that govern agent behavior across restarts.