Where Was Mythos When WordPress Fell?  🔗 **Source:** [Where Was Mythos When WordPress Fell?](https://patrik.re/where-was-mythos-when-wordpress-fell/) > [!note]+ Document Notes > tags: [ai-security, wp2shell, vulnerability-research, ai-marketing-claims, maintainer-burden, wordpress-security] > author: [Patrik (patrik.re)] > source: [patrik.re] > reference: [https://patrik.re/where-was-mythos-when-wordpress-fell/] > date created: 2026-08-07 00:00 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > > [!warning] **Conflict of interest disclosure.** This analysis was generated by Claude, made by > > Anthropic — the company whose marketing claims this article criticises. Discount accordingly. > > I have tried to apply the same standard used on every other document in this batch: credit the > > strong reasoning, name the fallacies, and neither defend nor amplify. Where I judge a criticism > > sound I have said so plainly; where I judge an argument weak I have said that too, and you should > > weigh the second category more sceptically than the first given who is writing it. > > # 🏷️ Title: Where was Mythos when WordPress fell? (patrik.re) > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [🔗 References](#-references) - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [📚 References](#-references-primary) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🧱 Refactor Appendix](#-refactor-appendix) ### 🔗 References - Article: https://patrik.re/where-was-mythos-when-wordpress-fell/ (published 2026-08-05, ~1,079 words) - Anthropic update of 2026-05-22 (the source of the scanning figures) - WordPress 7.0.2 release notes (reporter credits) - Adam Kues / Searchlight Cyber — discoverer of the pre-auth WordPress core RCE ("wp2shell") - Daniel Stenberg's curl evaluation · Bruce Schneier's commentary - Cloudflare's published account of operationalising the model ## 📝 Summary - **What happened.** A sceptical audit of the gap between Anthropic's claims for its Mythos security model and the observable public record — prompted by the fact that a pre-auth RCE in WordPress core was found by a human researcher using a *different* model, not by the system marketed as "securing critical software for the AI era." - **Why it matters for you specifically.** The methodology it describes — Adam Kues pointing an agent at a WordPress tree with git history stripped so it could not cheat by reading patches — **is the direct source of the agent code-analysis guardrails in your own `CLAUDE.md`**. This article is the critical context around that prompt. - **Key stakeholders.** Open source maintainers receiving AI-generated vulnerability reports; security researchers; anyone evaluating AI security tooling claims; the WordPress security team. - **Risks and tradeoffs.** The strongest material is quantitative and verifiable. The weakest is an argument from absence — that Anthropic's non-appearance in WordPress credits proves WordPress was not scanned, which does not strictly follow. - **Bottom line.** The self-assessment critique and the maintainer-overload finding are sound and important. The framing question ("where were they?") is rhetorically effective and evidentially weaker than the numbers it sits alongside. ## 📖 Main Content - **The setup, with self-deprecation.** The author opens by disclaiming expertise — > [!quote] at the end of the day we prompt that API and hope something useful comes out of it — and describes a feed full of people certain "the Messiah had arrived and that cybersecurity was basically solved." - **Programme context.** Mythos Preview was released to a limited set of trusted entities under **Project Glasswing**, with the stated aim of "securing critical software for the AI era." By June, the article states, the US government invoked export control powers and Anthropic shut off access to Fable 5 and Mythos 5 entirely. - **The central question.** Anthropic's 22 May update said Mythos Preview had scanned > [!quote] more than 1,000 open-source projects, which collectively underpin much of the internet—and much of our own infrastructure. The author's challenge is simply: **which thousand?** If WordPress — running on hundreds of millions of sites — were among them, why did it not surface the pre-auth core RCE that Adam Kues subsequently found? - **The pre-emption and the rebuttal.** He acknowledges the obvious defence — disclosed vulnerabilities are a lagging indicator, findings sit inside 90-day windows, not everything is publishable — and argues it does not cover this case, because the **WordPress 7.0.2 release notes credit the reporters and Anthropic is not among them**. - **The numbers, read closely — the article's strongest section.** Of 23,019 total findings, 6,202 were rated high or critical, and > [!quote] those severity ratings are the model's own estimate of its own work. Of those 6,202, exactly **1,752 had been independently assessed** by a security firm at time of writing, and **a little over 60%** of the checked subset held up as high or critical. His summation: > [!quote] a model grading its own homework, and the part where somebody else marked the homework covered about a quarter of it. - **What actually reached the public record.** Roughly **40 CVEs**, of which **28 are Firefox and 9 wolfSSL** — a browser and a cryptography library. > [!quote] There's no PHP in that list, no CMS, nothing that resembles the web most people actually use. - **Independent evaluations.** Daniel Stenberg ran it against curl: five reported findings, one real, low severity, and a conclusion that the hype was "primarily marketing." Bruce Schneier is cited as arguing the common wisdom that Mythos is better than other models at finding vulnerabilities "is just not true." The author's framing: > [!quote] Two people with nothing to sell, saying so in public, months ago. Did it change anything at all? Not that I noticed. - **The part that bothers him most — and the part that most corroborates other sources in this batch.** Around **530 high/critical bugs were reported to open source maintainers, of which 75 had been patched** at time of publication, and > [!quote] several maintainers told them they were so overloaded that they asked Anthropic to slow the disclosures down. His conclusion: securing critical software arrived "as a queue of tickets landing on unpaid volunteers who were already drowning." - **Cloudflare's operational reality.** Testing against 50+ of their own repositories, a single agent session covers > [!quote] maybe a tenth of a percent of the surface in a useful way before the context window fills, so they built an **eight-stage pipeline** around the model to extract anything useful. - **What Kues actually did — the methodological core.** Pointed GPT5.6 Sol Ultra at a **clean WordPress tree with git history stripped out so it could not cheat by reading patches**, capped it at four agents, and left it running. Ten hours later he had the exploit chain, at a cost of about **$25**. Kues' own conclusion, which the author endorses: no security researcher could have found and completed that chain in ten hours without AI. - **The "20 minute experts."** After disclosure, AI-security companies raced to reverse-engineer wp2shell, some claiming their systems figured it out in twenty minutes. The author's retort is the article's rhetorical centre: **where were those systems before the bug was public?** He notes open source projects are the obvious free promotional playground, so their absence beforehand is telling. - **The questions he ends on, unanswered by design.** Was it luck, or the prompt? Is it repeatable under the same conditions? > [!quote] Is steering the model eventually more important than advertised capabilities? He states plainly he has no answers, closing with the claim that > [!quote] a lot of influential people in this industry blindly follow marketing claims. ### 🗒️ Notes - The Kues result is a genuine and significant AI-assisted security finding — the article never disputes this, and explicitly credits it. Its target is the *marketing gap*, not the capability. - The cost figure (~$25 for a novel pre-auth RCE chain in a CMS running much of the web) is the most striking number in the piece and gets almost no emphasis. - The 60%-of-checked-findings figure is presented as damning without any comparison baseline — see Logical Validity. - Export controls and access shutoff are stated as fact with links; not independently verified here. ## 📚 References (primary) - Anthropic's 2026-05-22 update (the 23,019 / 6,202 / 1,752 figures) - WordPress 7.0.2 release notes (credit attribution) - Daniel Stenberg's published curl evaluation - Bruce Schneier's commentary - Cloudflare's engineering account of the eight-stage pipeline - Adam Kues / Searchlight Cyber's wp2shell writeup and prompt - **Your own `~/.claude/CLAUDE.md`** — the "Agent code-analysis / audit tasks" section derived from the Kues prompt ## 🗣️ Paraphrase - **The premise.** A model marketed as securing critical software did not find the most significant WordPress vulnerability of the period; a human with a different model did. - **The arithmetic.** Most of the impressive findings were graded by the system that produced them, and only about a quarter were independently checked. - **The output.** The public CVE record is narrow — mostly one browser and one crypto library — and contains nothing resembling the ordinary web. - **The independent checks.** Two well-known practitioners with no commercial stake tested or assessed it and were unimpressed, publicly, months ago. - **The externality.** Hundreds of high-severity reports landed on volunteer maintainers who asked for the pace to slow. - **The operational truth.** A single agent session covers a fraction of a percent of a real codebase; useful results required substantial scaffolding. - **The counter-example.** A careful researcher with a stripped repository, a capped agent count, ten hours and $25 found a real chain. - **The open question.** Is the differentiator the model, or the steering? ## 📰 Newsletter **A model graded its own homework and the industry printed the score** This is the most useful sceptical piece I've read on AI security tooling, and it's built almost entirely from numbers the vendor published themselves. The claim was that Mythos Preview scanned over a thousand open-source projects underpinning much of the internet. The finding count sounds enormous: 23,019 total, 6,202 rated high or critical. Except those severity ratings are the model's assessment of its own output. An independent firm checked 1,752 of them — about a quarter — and a little over 60% held up. Then look at what actually reached the public record: roughly 40 CVEs, 28 of them Firefox and 9 wolfSSL. A browser and a crypto library. No PHP, no CMS, nothing resembling the web most people use. Meanwhile the pre-auth RCE in WordPress core — the one that actually mattered to hundreds of millions of sites — was found by Adam Kues at Searchlight Cyber, pointing a *different* model at a clean WordPress tree with the git history stripped so it couldn't cheat by reading the patches. Four agents, ten hours, about twenty-five dollars. That last detail is why this article matters beyond the scorekeeping. Kues' setup is a methodology, not a lottery ticket: remove the answer key, pin the environment, cap the fan-out. The question the author leaves open is the right one — **is steering the model more important than the advertised capability?** And the part that should bother everyone: around 530 high or critical bugs went to open source maintainers, 75 got patched, and several maintainers asked for the disclosures to *slow down* because they were drowning. Securing critical software for the AI era arrived as a ticket queue for unpaid volunteers. **Links:** [the article](https://patrik.re/where-was-mythos-when-wordpress-fell/) ## ✅ Action Items - **DevRel** - `#action/h1` "A model grading its own homework" is the sharpest available phrasing for AI self-evaluation. It is also, precisely, the failure your own deep-read skill's maker/checker gate exists to prevent. - `#action/h2` Write the piece on **steering versus capability** — the article raises it and abandons it, and it is the most underexplored question in agentic tooling. - **OSPO** - `#action/h1` Policy question this forces: what is your intake posture for unsolicited AI-generated vulnerability reports at volume? Maintainers asking a vendor to slow down is a governance failure, not a compliment. - `#action/h2` Treat vendor-reported finding counts as unaudited until you know the independent-assessment fraction. Ask "how many were checked by someone else?" before "how many did you find?" - `#action/h3` Cloudflare's eight-stage pipeline is the realistic operational picture; a single agent session covering ~0.1% of surface is the planning assumption. - **Community** - `#action/h1` The maintainer-overload finding is the humane centre of this piece and deserves amplification: 530 reported, 75 patched, and explicit requests to slow down. - **WordPress (by team)** - Core / Meta: wp2shell is the reference case. The methodology — stripped git history, pinned environment, capped agents — is reusable for defensive auditing of core and of the directories. - Plugins / Themes: if a $25 ten-hour run finds a core RCE, the same method against directory plugins is trivially affordable to an attacker. That is the actual threat-model update. - Core AI: this is the cautionary case for any claim WordPress makes about AI-assisted security. Publish independent-assessment fractions, not raw counts. - Support / Documentation: nothing directly applicable beyond general advisory hygiene. - Core Performance, Core Program Team, Mobile, Playground, Community, Training, Marketing, Design, Photos, TV, Polyglots, Accessibility, CLI, Hosting, Tide, Openverse: Not applicable to this source. - **The WPOCC** - `#action/h1` Directly on-mission. Volunteer maintainers absorbing an AI-generated disclosure queue is an unfunded-labour problem with a governance answer, and the collective is positioned to say so. - **FAIR** - `#action/h2` Relevant to threat modelling: cheap AI-assisted vulnerability discovery changes the economics of attacking a distributed plugin ecosystem, where defensive capacity is unevenly distributed across mirrors and maintainers. - **Personal (Courtney)** - `#action/h1` Your `CLAUDE.md` "Agent code-analysis / audit tasks" section derives from the Kues prompt described here. **This article is the missing critical context for it** — link them in the vault so the guardrails carry their provenance. ## 🧪 Hypotheses 1. Model-self-rated severity systematically overstates true severity relative to independent assessment. *Partially evidenced — ~60% of the checked subset held up — but uninterpretable without a human-researcher baseline.* 2. The Kues result is reproducible under the same conditions (stripped history, pinned environment, four agents, ~10 hours). *The article's central open question and the single most valuable experiment available.* 3. Prompt/harness design ("steering") contributes more variance to agentic vulnerability discovery than base model capability. *Testable by holding the model constant and varying the harness, and vice versa.* 4. Unsolicited AI-generated disclosure volume measurably reduces maintainer patch throughput. *530 reported / 75 patched is suggestive; testable against pre-AI baselines.* 5. Public CVE output is not representative of total findings because of disclosure windows. *The article's own steelman of the opposing view; testable retrospectively as windows expire.* 6. Directory plugins are discoverable-vulnerable at similar cost to core. *Directly testable, and the most defensively urgent item here.* ## 📊 Methodology **Of the source:** a well-sourced opinion piece, not research. Its notable strength is that the damaging figures are **the vendor's own published numbers**, read carefully — 23,019 / 6,202 / 1,752 / ~60% are not the author's estimates, and the arithmetic he performs on them (that roughly a quarter was independently checked) is straightforward and checkable. Secondary claims are attributed and linked: Stenberg's curl test, Schneier's assessment, Cloudflare's account, the WordPress 7.0.2 credits. The weakest evidentiary move is inferential rather than factual — inferring from Anthropic's absence in credits that WordPress was not scanned. No original testing was performed; the author is explicit about not being an expert. **Of this analysis:** full article text read from Reader's `html_content` capture (~1,079 words). All claims trace to explicit statements. **None of the linked sources were independently fetched or verified** — the export-control claim, the Anthropic update figures, Stenberg's and Schneier's positions, Cloudflare's numbers, and the WordPress 7.0.2 credits are all reported *as the article states them*. Given the conflict of interest disclosed above, that verification gap matters in both directions and should be closed before anything here is cited. The connection to your `CLAUDE.md` guardrails is drawn from the memory context available in this session. ## ❓ Questions - Which thousand projects? This remains the article's unanswered core, and it is answerable only by Anthropic. - What is the baseline? Human security researchers also submit findings that fail independent triage — without that rate, "60% held up" cannot be scored as good or bad. **This is the biggest analytical gap in the piece.** - Has anyone attempted to reproduce Kues' result under identical conditions? Repeatability is the whole question and nobody appears to have tried. - How much of the outcome is attributable to the *stripped git history* specifically — i.e. how much does removing the answer key actually change agent behaviour? - What is the maintainer-side cost per AI-generated report, in hours? - Did any of the 530 reports prove to be duplicates or false positives after maintainer triage? - Would the same $25 method work against the top 100 plugins by install count? Nobody should publish the answer, but somebody defensive should know it. ## 🔮 Future Research - Reproduce the Kues methodology on a codebase with a known post-cutoff vulnerability — the cleanest available test of steering-versus-capability. - Establish baseline false-positive rates for human-submitted vulnerability reports, so model self-assessment can be scored against something. - Measure maintainer triage cost per AI-generated report, joining this to the Grafana talk's queue problem in the same batch. - Ablation study on the guardrails themselves: stripped history, pinned environment, capped agents, approach-family fan-out — which actually contributes? - Longitudinal tracking of whether the disclosure windows eventually vindicate or further undermine the scanning claims. ## 💡 Implications - **Practice.** Demand the independent-assessment fraction alongside any AI finding count. A raw count where the finder graded itself is not evidence. - **Policy.** Mass automated disclosure to volunteer maintainers is an externality. "We reported 530 bugs" is only good news if someone can process them. - **Security.** The economics have shifted: ~$25 and ten hours produced a novel pre-auth RCE in core. Defensive programmes should assume attackers have the same arithmetic. - **Education.** The Kues guardrails — remove the answer key, pin the environment, read the dependency source, fan out by approach family — are teachable and generalise well beyond security. - **Funding.** Maintainers absorbing AI-generated report volume is unfunded labour, which is precisely the gap Sustain 292 describes. Two documents in this batch, same hole. ## 🧠 Learning Styles Assessment - **Visual.** Not served. Dense prose with no charts, tables, or diagrams, despite carrying six or seven numbers that would benefit enormously from a single table. - **Aural.** Not applicable to this source — text-only, no audio component. - **Verbal.** Strongly served. Punchy, rhythmic, quotable prose; the argument is carried entirely by language and it works. - **Kinesthetic.** Weakly served directly, but the Kues methodology is concretely reproducible if you go to the primary source. - **Logical.** Well served on the quantitative sections — the arithmetic is laid out step by step and is easy to follow. Less so on the framing argument, which relies on rhetorical questions rather than stated premises. - **Social.** Moderately served — it positions itself within a public conversation, citing Stenberg and Schneier and gesturing at "my feed on X." - **Solitary.** Well served — short, self-contained, readable in five minutes. - **Naturalistic.** Not applicable to this source. - **Reading level.** Roughly grade 13–14. Prose is conversational, but comprehension requires substantial context: pre-auth RCE, CVE lifecycle and disclosure windows, export controls, context windows, agent harnesses, severity ratings. It assumes you already know what wp2shell was. ## 📊 Accessibility Assessment Mapped to WCAG 2.2 AA. 1. **Perceivable — text alternatives.** ✅ No images in the captured content; nothing to describe. 2. **Perceivable — time-based media.** ✅ Not applicable — no audio or video. 3. **Operable — keyboard.** ⚠️ Not verifiable from capture; a personal blog with dense inline linking, which is generally keyboard-friendly. 4. **Operable — enough time.** ✅ Static text, self-paced. 5. **Understandable — readable.** ⚠️ The weakest area. Numbers arrive in rapid prose sequence — 1,000 projects, 23,019, 6,202, 1,752, 60%, 40 CVEs, 28, 9, 530, 75 — with no table or list. Holding that in working memory while following the argument is genuinely demanding, and it is the one place where form fights content. 6. **Understandable — predictable.** ✅ Good. Clear descriptive section headings ("The numbers, if you read them", "Some people actually checked", "Enter the 20 minute experts") that accurately preview each section. 7. **Robust — compatible.** ✅ Semantic headings and links present in the captured markup. Heavy inline linking is good practice for verification. **Priority fix:** put the figures in a table. The article's strongest evidence is quantitative and is currently delivered in a form that resists comprehension and citation alike. ## 🌍 DEIB Assessment - **Cultural breadth.** Limited and largely irrelevant to the subject. Frame of reference is Western security-industry and US-regulatory (export controls, X/Twitter discourse, US-headquartered vendors). One genuinely global note is carried implicitly: WordPress "runs on roughly hundreds of millions of websites," so the population affected by the unfound vulnerability is worldwide while the actors discussed are concentrated in a small industry. - **Inclusive language.** Mostly fine, with a sardonic register. No exclusionary language. Mild snark ("almighty Mythos," "the 20 minute experts," "the Messiah had arrived") targets institutions and hype rather than identifiable individuals. Named people — Kues, Stenberg, Schneier — are treated with straightforward respect and credited by name. - **Neurodiversity support.** Mixed. Strengths: short, clearly-signposted sections with descriptive headings, and a consistent argumentative through-line. Weakness: the dense unstructured number sequence in the central section imposes real working-memory load, and rhetorical questions (several in a row at the close) can be genuinely ambiguous for readers who process language literally — it is not always obvious which are real open questions and which are rhetorical. The closing paragraph mixes both. - **Representation.** Narrow. Three named practitioners, all men, all established figures in Western security. The maintainers who are the article's moral centre — the "unpaid volunteers who were already drowning" — are discussed in aggregate and never quoted or named. That is a real gap in a piece whose strongest ethical claim is about their burden. - **Psychological safety.** Not applicable in the interpersonal sense — a single-author blog post with no dialogue. Worth noting the author's own posture: he opens by disclaiming expertise, closes by stating > [!quote] I don't have any answers for those questions, and credits the researcher whose work anchors the piece rather than positioning himself as the discoverer. That epistemic modesty is unusual in adversarial commentary and makes the piece more trustworthy, not less. ## ✅ Logical Validity **Strong reasoning** - **The self-assessment critique is the article's best work and is genuinely sound.** It uses the vendor's own published figures, performs simple checkable arithmetic, and reaches a defensible conclusion: 6,202 findings self-rated, 1,752 independently checked, so roughly three quarters of the headline number rests on the system evaluating its own output. That is a legitimate methodological objection, not a rhetorical one. - **The public-record check is a fair and falsifiable test.** Counting the CVEs that actually emerged (~40, dominated by Firefox and wolfSSL) is exactly the kind of verification that marketing claims should survive. - **He steelmans the opposing argument before rebutting it** — explicitly raising the lagging-indicator and 90-day-window defence rather than ignoring it. - **The maintainer-overload point is the strongest and most humane finding**, and it is independently corroborated elsewhere in this batch by the Grafana vulnerability-response talk describing the same queue pressure from the receiving end. - **The steering-versus-capability question is the article's most original contribution** and is genuinely underexplored in the wider discourse. - **He credits the work he is not criticising.** Kues' result is treated as real and significant throughout; the target is the marketing gap, not the capability. **Fallacies** 1. **Argument from absence — the framing weakness.** *Located:* Anthropic is not among the WordPress 7.0.2 reporter credits, therefore WordPress was presumably not among the thousand scanned projects. *Why it fails:* absence from credits establishes only that Anthropic did not report *this* vulnerability. WordPress could have been scanned and the chain missed, or scanned with findings still inside a disclosure window, or scanned with findings deemed lower severity. The author pre-empts the window objection but the credits fact does not carry the weight placed on it. *Fix:* the honest claim is narrower — "Mythos did not find this bug" — which is still notable. 2. **Missing baseline — the most consequential analytical gap.** *Located:* "a little over 60 percent held up as high or critical," presented as damning. *Why it fails:* no comparison is offered. Human researchers also submit findings that fail independent triage, sometimes at high rates, and automated static analysis notoriously so. Without a baseline, 60% is uninterpretable — it could be excellent or poor. *Fix:* compare against human-submitted or conventional-scanner triage-survival rates. 3. **Rhetorical questions substituting for argument.** *Located:* > [!quote] where were those projects, models and promises of a secure internet when open source projects like WordPress needed it most? *Why it's weak:* it is a strong rhetorical move and not a premise. It presumes those systems could have found it and chose not to look, which is exactly what is unestablished. *Mitigating:* he explicitly labels his closing questions as unanswered rather than implying answers. 4. **Appeal to disinterest.** *Located:* > [!quote] Two people with nothing to sell, saying so in public. *Why it's weak:* absence of commercial motive is a reason to weight testimony higher, not a substitute for evidence. Also n=2, and Stenberg's test is a single codebase (curl) — a hard target with an unusually mature security history, which is not representative. 5. **Selective sampling of the public record.** *Located:* the ~40 CVE count as evidence of narrow real-world output. *Mitigating:* he raises the lagging-indicator objection himself. *Still:* using a deliberately lagging metric as the primary output measure, having acknowledged it lags, is having it both ways. 6. **Loaded framing.** *Located:* "the almighty Mythos," "the Messiah had arrived," "the 20 minute experts." *Effect:* enjoyable and rhetorically effective; it also pre-loads the reader's conclusion before the evidence arrives. The evidence is strong enough that it did not need the help. 7. **Hasty generalisation about industry credulity.** *Located:* the closing claim that > [!quote] a lot of influential people in this industry blindly follow marketing claims. *Why it's weak:* supported by one observed feed and two dissenting experts. Probably true; not demonstrated. **Tone of voice.** Irritated, sardonic, and disarmingly self-deprecating. It opens by disclaiming expertise and closes by disclaiming answers, which buys it considerable licence for the sharpness in between. The register is practitioner-blog rather than journalism — first person, visible frustration, rhetorical questions, and a willingness to say "I don't know." Criticism is aimed at institutions, marketing, and industry credulity rather than at named individuals; the people named are named to be credited. The strongest sections are the quietest ones, where he simply does arithmetic on published numbers and lets it sit. ## 🛡️ DARVO Analysis **Not applicable in the clinical sense.** DARVO describes a defensive pattern deployed *by an accused party*. This article is the accusing side of a critique of corporate marketing claims, and no individual is accused of personal wrongdoing. - **Deny.** ⚪ Absent, and inverted — the author is the one *refusing* to accept a denial-shaped defence, and he states the counter-argument (disclosure windows) fairly before rejecting it. He also denies nothing about his own limits, opening with an explicit disclaimer of expertise. - **Attack.** 🟡 **Present in mild, targeted form, and worth naming honestly.** The article does attack — "the almighty Mythos," "the 20 minute experts," "the marketing department of Anthropic," and the closing claim about influential people following marketing blindly. These land on institutions and an unnamed class of hype-followers rather than on identifiable individuals, and criticism of a company's public claims is legitimate commentary rather than a DARVO component. But the rhetorical heat is real and it does some of the work the evidence should be doing alone. Do **not** tag `#darvo/attack` — this is ordinary polemic, not a defensive manoeuvre. - **Reverse victim and offender.** ⚪ Absent. No inversion occurs. If anything the article does the opposite of victim-reversal: it identifies the genuinely burdened party (unpaid maintainers receiving 530 reports) and keeps them in that role rather than centring itself or the vendor as aggrieved. Do not tag this document with any `#darvo/*` value. ## 🎯 Conclusion **Bottom line.** Two findings here are solid and should survive any discount you apply for my conflict of interest, because both rest on the vendor's own published numbers or on independently linked accounts. First: roughly three quarters of the headline finding count was severity-rated by the system that produced it, with about a quarter independently checked — a model grading its own homework, with partial external marking. Second, and more important: around 530 high-severity reports landed on volunteer maintainers, 75 were patched, and several asked for the pace to slow. That is an externality being described as a public good. Two things are weaker. The framing inference — Anthropic's absence from WordPress credits proving WordPress went unscanned — does not strictly follow; the honest claim is the narrower "Mythos did not find this bug," which remains notable. And the 60%-held-up figure is presented as damning with **no baseline**, which is the article's biggest analytical gap: human researchers and conventional scanners also produce findings that fail triage, and without that comparison the number cannot be scored. The most valuable thing in the piece is the least polemical: Kues' method. Strip the git history so the model cannot read the patch, pin the environment, cap the agents, let it run. Ten hours, $25, one novel pre-auth RCE in software running much of the web. That is a methodology and a threat-model update, and it is the direct ancestor of the audit guardrails already in your `CLAUDE.md`. **Next steps.** 1. Link this article to the "Agent code-analysis / audit tasks" section of your `CLAUDE.md` — those guardrails came from the Kues prompt and currently carry no provenance. 2. Verify the linked primaries before citing any figure from this piece anywhere. I did not fetch them, and the conflict of interest above makes that gap matter more than usual. 3. Cross-link with the Grafana talk: maintainers asking a vendor to slow disclosures is the same queue pressure Grafana described from the receiving end. Two independent sources, same failure. 4. The genuinely urgent WordPress action: if $25 and ten hours finds a core RCE, the same method against top-install directory plugins is trivially affordable. That is a defensive planning assumption, not a hypothetical. ## 🧱 Refactor Appendix ### Literature Split Pad #### L1 — A model grading its own homework `#atom/literature/h1` > [!quote] the number that kept popping up in my feed was a model grading its own homework, and the part where somebody else marked the homework covered about a quarter of it. Claim: 6,202 high/critical findings were self-rated; 1,752 were independently assessed; ~60% of that checked subset held up. Sound methodological objection built from the vendor's own figures. #### L2 — Securing critical software arrived as a ticket queue `#atom/literature/h1` > [!quote] several maintainers told them they were so overloaded that they asked Anthropic to slow the disclosures down. Claim: ~530 high/critical reported, 75 patched. Automated discovery at scale externalises cost onto unpaid maintainers. Independently corroborated by the Grafana talk in this batch. #### L3 — The public record is narrow `#atom/literature/h2` > [!quote] There's no PHP in that list, no CMS, nothing that resembles the web most people actually use. Claim: ~40 CVEs, 28 Firefox, 9 wolfSSL. Falsifiable check on marketing scope — weakened by the author's own acknowledgement that CVEs lag. #### L4 — Remove the answer key `#atom/literature/h1` Claim: Kues pointed an agent at a **clean WordPress tree with git history stripped** so it could not shortcut by reading patches, capped at four agents, ~10 hours, ~$25 → a novel pre-auth RCE chain. Methodology, not luck — and the direct source of the audit guardrails in `CLAUDE.md`. #### L5 — Agent coverage is a fraction of a percent `#atom/literature/h2` > [!quote] maybe a tenth of a percent of the surface in a useful way Claim (Cloudflare, 50+ repos): a single session covers ~0.1% before context exhaustion, requiring an eight-stage pipeline. The realistic operational planning assumption. #### L6 — Steering may matter more than capability `#atom/literature/h2` > [!quote] Is steering the model eventually more important than advertised capabilities? Claim: harness design, prompt, and constraint may contribute more variance to outcomes than base model capability. The article's most original and least developed idea. #### L7 — 60% without a baseline `#atom/literature/h3` `#fallacy/missing-baseline` Claim: the checked-findings survival rate is presented as damning with no comparison to human-researcher or conventional-scanner triage-survival rates. The article's biggest analytical gap. ### Atomic Split Pad - **Z1 — Self-assessment is not evidence `#atom/zettel/z1`.** When the system producing an output also grades it, the grade carries no independent information. Always ask what fraction was externally verified. Directly parallels the maker/checker gate in the deep-read skill — `[[the-maker-should-not-grade-its-own-homework]]`. - **Z2 — Discovery externalises onto remediation `#atom/zettel/z1`.** Scaling detection without scaling triage capacity converts a capability gain into a burden transfer. Finding is cheap; fixing is not, and the finder rarely pays. Links to `[[verification-cost-asymmetry]]` and `[[prerequisite-starvation]]`. - **Z3 — Remove the answer key `#atom/zettel/z1`.** To test whether a system can *derive* rather than *recall*, delete the artifacts encoding the known solution — git history, changelogs, patch diffs. Applies to any agent evaluation, not just security. - **Z4 — Steering versus capability `#atom/zettel/z1`.** Outcome variance in agentic work may be dominated by harness design rather than model tier. If true, the correct investment is prompts, constraints, and scaffolding — not upgrades. Links to `[[skills-as-source]]` and `[[scaffolding-vs-capability]]` from the Penpot doc; three sources in this batch now circling the same claim. - **Z5 — Count without denominator `#atom/zettel/z1`.** A raw finding count means nothing without the verified fraction and a baseline rate. This cuts both ways — it is why the vendor's 6,202 is weak evidence *and* why the critic's 60% is weak counter-evidence. ### Fleeting Queue - `#atom/fleeting/f1` This is the missing provenance for the "Agent code-analysis / audit tasks" section of my CLAUDE.md. Link them. - `#atom/fleeting/f1` "A model grading its own homework" and the deep-read skill's "The Maker Should Not Grade Its Own Homework" are the same principle discovered independently. That convergence is worth a short post. - `#atom/fleeting/f1` Third source in this batch on maintainers drowning in AI-generated reports: Grafana (receiving end), Harbuz (funding), this (the disclosing end). All 2026, none citing each other. - `#atom/fleeting/f1` $25 and ten hours for a pre-auth core RCE. The defensive planning question nobody is asking: what does that same budget find in the top 100 plugins? - `#atom/fleeting/f1` Nobody has tried to reproduce the Kues result. Repeatability is the entire question and it is sitting there untested. - `#atom/fleeting/f1` The 60%-with-no-baseline gap is a good teaching example — a sound critic making an unsound comparison, in a piece whose other numbers are solid. - `#atom/fleeting/f1` Note for the skill: I analysed a critique of my own maker here. Disclosure worked, but it is worth a standing rule — flag conflicts of interest in notes rather than hoping the reader infers them. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Where Was Mythos When WordPress Fell.md|Where Was Mythos When WordPress Fell? by patrik.re]] ## Highlights - If you actually read [the update](https://www.anthropic.com/research/glasswing-initial-update), the numbers don’t quite add up. Mythos Preview found what Anthropic describes as 6,202 high or critical severity vulnerabilities out of 23,019 in total, and those severity ratings are the model’s own estimate of its own work. Of those 6,202, exactly 1,752 had been assessed by an independent security firm at the time of writing, and of the ones that got checked, a little over 60 percent held up as high or critical. So the number that kept popping up in my feed was a model grading its own homework, and the part where somebody else marked the homework covered about a quarter of it. Would you put that number in a press release? ([View Highlight](https://read.readwise.io/read/01kzecape5x8zctdgva63mb7nh)) - Note: L1 — The article's best work: built entirely from the vendor's own published figures with checkable arithmetic. 6,202 self-rated high/critical, 1,752 independently assessed (~28%), ~60% of that subset held up. Self-assessment carries no independent information — always ask what fraction was externally verified. Exactly parallels the maker/checker gate in your deep-read skill ("The Maker Should Not Grade Its Own Homework"), discovered independently. CAVEAT tagged: the 60% figure is presented as damning with NO BASELINE. Human researchers and conventional scanners also produce findings that fail triage; without a comparison rate, 60% is uninterpretable. That's the article's own biggest analytical gap. (Disclosure: I'm made by Anthropic — weigh my defence of this point more sceptically than my endorsement of the two above.) - Tags: atom/literature/h1, ai-marketing-claims, fallacy/missing-baseline, atom/zettel/z1 - And then there’s the part that bothers me the most. Anthropic [reported around 530 high or critical bugs](https://www.anthropic.com/research/glasswing-initial-update) to open source maintainers, of which 75 had been patched by the time they published that update, and several maintainers told them they were so overloaded that they asked Anthropic to slow the disclosures down. So securing critical software for the AI era arrived, in practice, as a queue of tickets landing on unpaid volunteers who were already drowning. ([View Highlight](https://read.readwise.io/read/01kzeca5zmqearc8766t6r2n66)) - Note: L2 — The humane centre of the piece and the strongest claim in it: ~530 high/critical reported, 75 patched, and maintainers explicitly asking for the pace to SLOW DOWN. Scaling detection without scaling triage capacity converts a capability gain into a burden transfer — finding is cheap, fixing is not, and the finder rarely pays. THIRD independent source in this batch on the same failure: Grafana describes the queue pressure from the receiving end (01kze55kgja0yyhwtzewnpq8b1), Harbuz describes who funds the triage (01kze559r334xe6j6d5y210wj6), this describes the disclosing end. All 2026, none citing each other. - Tags: maintainer-burden, open-source-sustainability, atom/zettel/z1, atom/literature/h1 - What Adam did, for the record, was point GPT5.6 Sol Ultra at a clean WordPress tree with the git history stripped out so it couldn’t cheat by reading patches, cap it at four agents, and leave it running. Ten hours later he had the chain, and it cost him about 25 dollars. His own conclusion is that no security researcher could have found and completed that exploit chain in ten hours without AI, and I believe him, which is exactly why the rest of this bothers me. ([View Highlight](https://read.readwise.io/read/01kzeca04fjf87p2rbenbyp1da)) - Note: L4 — THE methodology, and the direct ancestor of the "Agent code-analysis / audit tasks" guardrails in your own ~/.claude/CLAUDE.md. Remove the answer key (strip git history so the model can't shortcut by reading patches), pin the environment, cap the fan-out (4 agents), let it run. 10 hours, ~$25, one novel pre-auth RCE in software running hundreds of millions of sites. This is a methodology, not a lottery ticket — and nobody has tried to reproduce it, which is the whole open question. DEFENSIVE PLANNING UPDATE: if $25 finds a core RCE, the same budget against top-install directory plugins is trivially affordable to an attacker. - Tags: atom/zettel/z1, wordpress-security, vulnerability-research, atom/literature/h1, wp2shell