The Anthropic Mythos Leak: Boring CMS Misconfigs Caused It — Yours Probably Has the Same Bug

On March 26, 2026, a CMS misconfiguration on Anthropic's website exposed roughly 3,000 unpublished assets to the public internet — including a draft blog post describing a new model tier internally codenamed "Capybara" and its first model, Claude Mythos. Fortune broke the story the same day. Anthropic told reporters: "an issue with one of our external CMS tools led to draft content being accessible" — attributing it to "human error" (Fortune, March 26 2026).

TL;DR — what actually happened

Assets uploaded to Anthropic's CMS were public by default. Each new asset was assigned a guessable URL and indexed somewhere a researcher could find it. No SQL injection, no zero-day, no nation-state — just a CMS where "public" was the default state and someone uploaded drafts assuming "draft" meant "private." Zscaler called it correctly: "this wasn't a hack" (Zscaler analysis).

Why this matters now

Every Indian SMB we audit in 2026 has this exact bug somewhere. WordPress media library set to public. Sanity/Contentful "preview URL" that doesn't require auth. S3 bucket holding draft PDFs with ACL "public-read". Next.js /api/preview route with the token in the URL instead of a signed cookie. The Anthropic leak is your CMS, with a bigger blast radius.

The four CMS misconfigurations that cause 80% of "AI lab" leaks

We've reviewed CMS setups for 40+ Indian firms in the last year. These four show up in nearly every audit, and they're the exact pattern that bit Anthropic.

The CMS exposure audit you can run today

Run these against your own domain — substitute yourcompany.com with yours.

Check 1: directory listing on your media folder

# If this returns an HTML listing of files, you're exposed.
  curl -s https://yourcompany.com/wp-content/uploads/2026/03/ | grep -i "index of"
  curl -s https://yourcompany.com/uploads/ | grep -i "<title>Index of"
  curl -s https://yourcompany.com/assets/ | grep -i "<a href"
  

Check 2: your S3 bucket is listable

# Replace with your actual bucket. If you get XML listing, you're exposed.
  curl -s https://your-bucket-name.s3.amazonaws.com/
  curl -s https://your-bucket-name.s3.ap-south-1.amazonaws.com/
Also try the path style — some clients use this:
  curl -s https://s3.ap-south-1.amazonaws.com/your-bucket-name/
  

Check 3: draft routes are accessible without auth

# Common draft URL patterns — test each:
  curl -s -o /dev/null -w "%{http_code}\n" https://yourcompany.com/api/preview
  curl -s -o /dev/null -w "%{http_code}\n" https://yourcompany.com/admin
  curl -s -o /dev/null -w "%{http_code}\n" https://yourcompany.com/wp-admin/admin-ajax.php
  curl -s -o /dev/null -w "%{http_code}\n" https://yourcompany.com/_next/data/
  

A 200 or 401 is fine. A 200 with content, or a 403 with a "Disallow" hint in robots.txt that points to a real path — that's where you'll find the leak.

Check 4: Google has indexed something you didn't want

Search Google for: site:yourcompany.com inurl:draft, site:yourcompany.com filetype:pdf, site:yourcompany.com "internal". If you find pages tagged "draft" or "do not publish," they're indexed. Anthropic's drafts were almost certainly findable this way.

The fix — a 6-step checklist

• Set your S3/GCS/Azure Blob storage bucket policy to "block all public access". Move public assets to a separate bucket explicitly meant to be public, with a CDN in front.
• For Sanity, Contentful, Strapi: rotate preview tokens monthly. Require auth on the preview route — don't trust the token alone. Use signed, short-lived URLs.
• Disable directory listing in Nginx (autoindex off;) and Apache (Options -Indexes). Verify with curl after the change.
• Move every "draft" or "preview" route behind a real authenticated session — same auth as your admin panel. No path obfuscation, no token-in-URL.
• Add a robots.txt that doesn't reveal sensitive paths (don't list /admin-secret/ there — it tells attackers exactly where to look).
• Set up Google Search Console for your domain. Subscribe to "Crawled — currently not indexed" alerts. If anything sensitive appears, file a removal request the same day.

A comparison: how three CMSes default

Best for security-first teams: a CMS where private is the default and you opt in to public — currently Payload CMS, Directus, or a self-rolled Next.js + signed-URL pattern.

Counter-example — when this audit is overkill

If your "CMS" is a static Next.js site with all content committed to git, no admin panel, no preview routes, and assets served from a Vercel domain you own — you do not have a CMS misconfig problem. You have a git repo problem (don't commit secrets, set the repo private, check). The audit above only applies if there's a separate authoring tool with a database behind it.

The two things Anthropic did right after the leak

Worth calling out, because most companies do this badly. Within 24 hours, Anthropic confirmed the exposure to Fortune on the record, named the cause ("an issue with one of our external CMS tools"), and accepted that it was human error rather than blaming a vendor. They didn't issue a non-statement, didn't sue the security researchers who found it, and didn't try to walk back the leaked Mythos draft. Compare that to the Adobe response two weeks later (silence as of mid-April). The reputational difference between "we screwed up, here's what" and "no comment" is the difference between a 48-hour news cycle and a 6-week one.

Common mistakes that turn a CMS misconfig into a 10x worse incident

Three patterns we've seen in post-mortems. First: the team rotates the leaked content but not the underlying CMS configuration — six weeks later, the next batch of drafts leaks the same way. Second: PR teams move faster than security and publish a "we've contained the issue" statement before the audit log review is complete — then have to retract when more leaks surface. Third: legal sends takedown letters to the security researchers who found the leak, which guarantees the story stays in the headlines for an extra week and discourages future responsible disclosure. Don't do any of these.

Real example — what we found in 90 minutes

A Pune-based EdTech firm (12 people, Sanity-backed Next.js site) asked us to look. In 90 minutes we found: their Sanity preview token committed to a public GitHub repo (rotated 14 months ago, still valid); /api/preview route accessible with the token and no IP allow-list; their AWS S3 bucket for course PDFs set to public-read. Total exposure: every draft course module for the next 6 weeks, plus 280 PDFs they'd marked "internal use." Fix: 4 working hours, plus a 30-minute training for the team on Sanity preview-mode auth. The Sanity docs they'd read 18 months ago had been updated — they hadn't checked.

For more on how seemingly-boring CMS bugs become embarrassing leaks, our founder writes about security for fast-moving startup teams — same pattern, more case studies.

FAQ

Was the Anthropic Mythos leak actually a hack?

No. It was a CMS misconfiguration where draft assets were public by default. Anthropic confirmed this to Fortune, calling it "human error" with an external CMS tool. No vulnerability was exploited; no system was bypassed. Researchers Roy Paz (LayerX Security) and Alexandre Pauwels (Cambridge) found the assets via standard reconnaissance.

What does "public by default" mean in a CMS?

When you upload an asset (image, PDF, video) to a CMS, the system has to choose: is this asset public on the internet, or only accessible to logged-in editors? Many CMSes default to public — because most content eventually becomes public — which means a draft uploaded "for review" is already live the moment it hits the storage layer.

How do I check if my WordPress install has this bug?

Try yourdomain.com/wp-content/uploads/ in a browser. If you see a directory listing, disable it. Try yourdomain.com/?p=99999 for various high IDs — if your drafts have low IDs, they may render even unpublished. Install Wordfence or similar and enable "Hide WordPress version" plus directory protection.

Is Sanity safe if I'm careful with preview tokens?

Safer than WordPress, riskier than a fully auth-gated CMS. Sanity's preview pattern relies on a shared secret in the URL. Treat the token like a password: rotate quarterly, never commit to git, never paste in Slack, and require auth on top of the token (Vercel team SSO, Cloudflare Access, etc.).

How does Google end up indexing my drafts?

Three ways: a developer or editor accidentally shares the draft URL externally (Slack, email — referer headers leak it); a sitemap.xml file includes draft slugs; or a third-party preview service like Sanity's hosted preview UI itself is crawlable. Always set drafts to noindex via headers — even behind auth — as defense in depth.

Are these CMS misconfigs reportable under DPDP?

If the leaked content contains personal data — yes. India's Digital Personal Data Protection Act requires breach notification for material exposure of personal data. A misconfigured S3 bucket exposing customer KYC PDFs is a notifiable event, even if no "attacker" downloaded them. Treat misconfig findings as breaches until proven otherwise.

What's the cheapest tool to scan for these issues continuously?

We run a combination of subfinder, httpx, and nuclei (all open-source, free) weekly against client domains. Total cost: a t3.micro EC2 instance running cron. Findings get emailed to a security inbox. The setup takes a half-day; we wrote about it in our internal runbook. Reach out if you want the bash scripts.