Mythos at the Gate: Why 2026 Is Worse Than 2000

200,000 vulnerable MCP servers, 271 zero-days in a single browser, a 17-year-old RPC bug exploited across 15 requests. Y2K was coordinated panic followed by a non-event. Mythos is arriving without coordination — and your Odoo is one leaked API key away from a full takeover.

On April 7, 2026, Anthropic announced — and immediately withheld from public release — a model called Claude Mythos Preview. The reason: Mythos autonomously identifies zero-day vulnerabilities and writes working exploits against every major operating system and every major web browser. Over roughly a month of evaluation it surfaced more than a thousand critical-severity zero-days, and on AISI's 32-step "Last Ones" simulated corporate-attack scenario it completed a full network takeover in 30% of attempts — an objective the UK AI Security Institute estimates would take a competent human pentester roughly 20 hours.

This is the vendor itself deciding their own model is too dangerous to ship, locking it inside a 12-partner program called Project Glasswing for defensive use only. For the first time among major frontier-AI labs, a vendor has publicly stated: "our own model is too powerful to release."

If you run an Odoo deployment — for yourself, for a client, or for a startup selling €25 trials — this story affects you directly. Here is why.

1. Why I'm bringing up the year 2000

Y2K was predictable, visible, and coordinated. We knew about the bug five years before the deadline. Governments, banks, and software vendors lined up resources in lockstep. On January 1, 2000, nothing happened. Y2K became a non-event because it was a coordinated panic.

Mythos is arriving now, with no equivalent coordination. There are 200,000 vulnerable MCP servers in the wild, and after five months of disclosure correspondence Anthropic declined to modify the protocol, framing the STDIO transport's command-execution surface as a deliberate operator-responsibility boundary rather than a defect to patch. That's a defensible architectural position — protocols routinely push hardening to the deployment layer — but it leaves every implementer downstream owning a problem whose blast radius they did not design.

Y2K was coordinated panic followed by a non-event. Mythos risks being uncoordinated drift followed by a parade of incidents that have already started. Per Gravitee's 2026 industry survey, 88% of organizations confirm or suspect an AI-agent security incident in the past twelve months. That's before Mythos even reaches commercial production.

2. What exactly Mythos can do

Publicly documented capabilities (UK AI Security Institute evaluation + Anthropic's own red-team report):

• 181 working exploits written autonomously against Mozilla Firefox, plus 29 cases with confirmed register control (210 confirmed exploit primitives in total) across several hundred attempts. The previous-generation Opus 4.6 cleared two on the same benchmark.
• A 27-year-old dormant flaw in OpenBSD — a security-focused operating system — discovered without targeted prompting.
• A 16-year-old bug in FFmpeg and a 17-year-old remote code execution in FreeBSD NFS (CVE-2026-4747) — we'll come back to this one in a moment, because the exploit technique matters for ERP integrators.
• A multi-stage chain of four separate vulnerabilities assembled into a single browser sandbox escape with a JIT heap spray that breaks out of both the renderer process and the OS sandbox simultaneously.
• Once inside a network: automatic system mapping, lateral movement, custom data-exfiltration tooling. All within hours, not days.

And the most unsettling detail: these capabilities were not explicitly trained. They emerged as a downstream consequence of broader improvements in code reasoning and autonomy. The previous Claude Opus 4.6 had a near-zero success rate on autonomous exploit development. Between 4.6 and Mythos there is no incremental staircase — there is a jump.

This matters because it means Mythos is not the end of the curve. It is the first publicly documented point on it. The next models — from Anthropic, OpenAI, xAI, Chinese labs — will share the same capabilities, but without a Project Glasswing wrapper around them.

3. MCP — the invisible layer under our feet

The Model Context Protocol is the standard that defines how AI agents reach external systems — ERPs, CRMs, databases, file servers, Git repositories. In 2025 it was the toast of the industry. In 2026 it is the attack surface of the entire agentic AI ecosystem.

Concrete numbers (OX Security, April 2026):

• 150 million MCP package downloads.
• 7,000 publicly accessible MCP servers.
• 200,000 vulnerable instances, hijackable through command injection on the STDIO interface.

In a single month — April 2026 alone — these CVEs landed:

• CVE-2026-40933 (Flowise, CVSS 9.9) — sandbox bypass with RCE.
• CVE-2026-22252 (LibreChat) — authenticated RCE through the MCP STDIO transport.
• CVE-2026-22688 (WeKnora) — injection.
• CVE-2026-39974 (n8n MCP server) — SSRF.
• Plus the recurring token-mismanagement issues catalogued in OWASP MCP Top-10 2025.

When researchers pressed Anthropic for a protocol-level fix, the response after five months was: this transport surface is "expected, designed this way". The substance is defensible — every protocol committee at some point draws a line between what the protocol guarantees and what the deployment must enforce — but the consequence stands: defense is your responsibility, not the protocol's.

4. The bypass vector — direct RPC abuse

This is where the discussion becomes concrete. Remember the 17-year FreeBSD NFS bug Mythos found and exploited on its own? The way it did it is a textbook for what's coming for us.

The vulnerability is a stack buffer overflow in the RPCSEC_GSS handler — a 128-byte stack buffer with a length check that permits up to 400 bytes (≈304 bytes of overflow, after the RPC framing header). Classic overflow, but with a hard constraint: kernel pages are randomized, and a single write isn't enough. Mythos "slices" the exploit into six sequential RPC requests that write progressively into kernel BSS memory, assembling the full payload across them.

Every defense you have built into the MCP layer — RBAC, audit logs, rate limits, capabilities — sees nothing. The AI agent never went through MCP at all. It is talking to Odoo directly.

This is the Mythos vector. And it is the core structural vulnerability of every proxy-only MCP server — which, without exception, includes every Odoo MCP integration you can find on public GitHub today.

5. The competitive landscape

We ran a systematic audit of 12 publicly-available Odoo and generic MCP servers. Their results against the OWASP MCP Top-10 (especially MCP01:2025 — Token Mismanagement) are surprising in a bad way:

Let me underline this: even the official Anthropic reference servers (for GitHub, Postgres, SQLite, Slack, Drive) carry their own SECURITY.md disclaimer — "not production-ready". Yet integrators ship them in production anyway, because they're labelled "official."

Eight of the ten public Odoo MCP servers we surveyed store credentials in plaintext .env files — which is the Twelve-Factor norm and, in itself, not a vulnerability. The vulnerability is what comes around the storage: no key rotation, no audit trail, no rate-limited revocation path. When a .env reaches the wrong place — a leaked git history, a backup landing in the wrong S3 bucket, an SSH-compromised developer machine — the recovery checklist is "rotate the Odoo password and pray nothing else has been touched yet." There is no surgical key-revocation step because there were no surgical keys.

6. What we shipped in odoo-claude-mcp v3.0.0-alpha.6

Five releases across eight days (alpha.2 through alpha.6), one of which is a 121-case regression suite. The concrete changes:

6.1 RBAC API keys with three independent axes

• Role — admin or tenant. A tenant key cannot call /provision, period.
• Scope — for the tenant role, a non-empty list of explicit client_id values; the wildcard ["*"] is reserved for admin only.
• Capabilities — concrete verbs (provision, destroy, read, issue_keys). A tenant gets destroy and nothing else by default.

6.2 HMAC-SHA256 + server-side pepper, not argon2

Argon2 is the right tool for low-entropy passwords. For 256-bit random tokens it is the wrong tool — slow (50-100 ms per verify), making a denial-of-service vector trivial: 50 stored keys × one argon2 verify each = a 5-second blocked event loop per malformed request. We replaced it with HMAC-SHA256 plus an external pepper held in environment variables (MCP_KEY_PEPPER, minimum 32 bytes). Without the pepper, every verify fails closed. A file leak without an env leak ⇒ the keys remain useless.

6.3 O(1) verify via key_id prefix

The plaintext format changed from mcpv3_<random> to mcpv3_<key_id_hex>_<random>. The prefix permits O(1) lookup in the active-key map — verification performs one HMAC operation, not N argon2 verifies. We kill the DoS surface and the timing oracle in the same change.

6.4 Force-revoke of legacy keys

We ship migrate_legacy_keys.py — a one-shot operator script that snapshots the audit log and then forcibly revokes every key without RBAC fields. We do not auto-promote them to admin (which would be a critical regression: a leaked old key suddenly grants root). Manual reissue via provision_issue_api_key is the audit checkpoint.

6.5 Auto-issue of a destroy-only tenant key on /provision

When an admin key provisions a new tenant, the response also includes a freshly-issued destroy-only tenant key, scoped to the new client_id. The client stack saves it for future teardown without ever depending on the operator's admin key. After a successful /destroy, the tenant key auto-revokes. One key, one lifecycle.

6.6 RPC dispatcher hardening (alpha.3)

Beyond the API-key layer, the RPC dispatcher itself was rebuilt around four hardening points:

• Header redaction in audit logs — Authorization, Cookie, X-API-Key, and bearer-pattern values are masked. Pre-alpha.3, full headers landed verbatim in provisioning_audit.log; one disk leak ⇒ key recovery.
• hmac.compare_digest at the four sites that previously used == on secrets — closes a timing-oracle Mythos-class agents will use without hesitation.
• tool_security.PROTECTED_FROM_WRITE covers 21 sensitive Odoo models (ir.model, ir.model.fields, ir.actions.server, res.users, res.groups, ir.config_parameter, etc.). Tenant tokens cannot write/unlink them through the proxy; admin tokens require an explicit mcp_elevate elevation call first.
• DANGEROUS_METHOD_EXACT blocks the recognised takeover surface (execute, _register_hook, install, uninstall, etc.) at the dispatcher layer rather than relying on Odoo ACL alone.

The startup also now hard-fails if MCP_TLS_VERIFY_ALWAYS=1 is set and any outbound HTTP client has TLS verification disabled — the historic "self-signed lab cert" workaround can no longer leak into production.

6.7 Path traversal & symlink TOCTOU defenses (alpha.3 + alpha.6)

Eight call sites that accept a save-path parameter (attachment_download, record_backup, OAuth token storage, etc.) now route through a single _safe_save_path resolver — strict normalization, allow-list root (MCP_DOWNLOAD_ROOT), and a hard reject of any .. traversal or absolute path that escapes the allow-list. Alpha.6 added _open_for_write_nofollow() on top, which opens the resolved path with O_NOFOLLOW — closing the symlink-replacement TOCTOU window between resolve and write.

6.8 Atomic provisioning + Stripe-pattern saga (alpha.4)

/provision grew its own micro-state machine. Each stage (DNS create → Portainer stack create → Odoo bootstrap → Anthropic key issue) emits a record into an append-only provisioning_ledger.jsonl. If any stage fails mid-flight, the response is HTTP 409 with a recovery_token and retry_endpoint hint — same pattern Stripe uses for partial-failure idempotency. We deliberately rejected auto-rollback (the AWS Step Functions saga argument): cleaning up a half-provisioned stack from inside the same crashed handler is the worst place to attempt it.

On the abuse side, the same release added: 5/min rate limit on /provision, 10/min on /destroy, failed-auth lockout at 20 fails/h (per IP), 4 KB body cap, regex validation of email/slug/VAT/Anthropic-key shape, and NIST 800-63B password policy (length-only ≥14 characters, reject sequences with fewer than 4 distinct characters). Audit log rotates at 50 MB into .log.1 through .log.5.

6.9 Cloudflare-aware client IP resolution (alpha.5 — critical fix)

This one is worth a callout because the bug was easy to miss and the impact was severe. Pre-alpha.5, req.client.host returned the proxy loopback (127.0.0.1) when traffic arrived through the Cloudflare tunnel. Result: every external attacker appeared as 127.0.0.1, which (a) bypassed the rate limit (the loopback bypass rule was meant to spare internal Docker networks), and (b) collapsed all attackers into a single bucket so the lockout counter never tripped.

Same release also moved provisioning_engine.provision() and destroy() off the event loop via asyncio.to_thread(). They were previously synchronous and could block the entire HTTP server for 5-60 seconds during a stack creation — itself a DoS vector if Mythos figured out the timing.

6.10 OAuth code-flow hardening + 121-case regression suite (alpha.6 + tests)

Alpha.6 closed the OAuth one-shot code surface: MCP_OAUTH_REDIRECT_URIS CSV allow-list (trailing slash = prefix match, otherwise exact), a startup warning if MCP_OAUTH_CLIENT_SECRET equals MCP_SECRET_TOKEN (a deceptively common deploy mistake), record_backup.include_related cardinality cap (MCP_RECORD_BACKUP_MAX_RELATED, default 5000), and a _truncate_key() helper that turns audit-log key references from mcpv3_xxxxxxxxxxxxxxxxxx… into mcpv3_xx…last4 — less leak surface for log analysts and incident-response tooling alike.

The pytest regression suite now runs 121 cases (tests/test_security_phase1.py) covering every change above: protected-model matrix, password policy, RFC 1918 IP trust (including the explicit 192.168 reject), OAuth lifecycle (replay, binding, expiry), _safe_save_path with 18 traversal payloads, urlparse internal-host (the qdrant:6333.evil.com substring confusion the QA review caught), _client_ip_for with synthetic XFF chains, regex validators, rate limiter, lockout, ledger roundtrip. CI runs them on every push to 3.0.

7. What we still cannot do — and why honesty matters

Just like the competitors, we are partial against the Mythos vector — not fully protected. The reason is architectural and worth understanding:

Every proxy-MCP server — including ours — sits in front of Odoo. If an attacker holds user credentials or an Odoo API key, and if the XML-RPC endpoint of Odoo is publicly reachable, they can simply skip the MCP layer and talk to Odoo directly. Our RBAC, our audit log, our rate limits — all blind to it.

There are only two ways to close this vector:

1. The vendor owns the backend. That's what Zapier does — its backend rejects traffic that didn't come through the MCP. For us, that's not possible: Odoo is a third-party application.
2. An in-Odoo last line of defense. A protective module that lives inside Odoo, monkey-patches the RPC dispatcher, and enforces RBAC + audit + anomaly detection before every execute_kw.

Option two is the next iteration on our roadmap — v3.1+. Concretely: a new l10n_bg_security_guard module (or an extension of the existing l10n_bg_claude_terminal) that adds:

• RPC audit log on every call (model, method, args size, IP, user) with pattern detection.
• Per-user rate limit + IP allowlist (CIDR lists at the res.users level).
• Lockdown of ir.actions.server with state='code' — gated behind a special mcp.elevated group, default off. (This single change closes the #1 admin-takeover vector by itself.)
• Pre-write gate for protected models (account.move, product.template, res.partner) — requires a human-approval token for RPC sessions.
• Telegram alert on every privileged write that did not originate in a browser session.

At our current velocity that is 2026-Q3 work. When it is ready, it will be open source under AGPL-3.0, because vertical defenses only work when everyone shares them. Just as Y2K wasn't solved by one company, the Mythos vector cannot be closed by one vendor.

8. What to do today

If you operate Odoo with any kind of MCP wrapper, or are simply planning one, here is an uncompromising checklist:

1. Audit where credentials are stored. Plaintext in .env = compromise-ready. Hash them with HMAC + pepper, or migrate to a vendor with proper key management.
2. Close public XML-RPC. If a client only uses the web UI and MCP, the XML-RPC port has no business being reachable from outside the private network. Cloudflare Access, Tailscale, or plain iptables. If you're on Odoo Online or Odoo.sh you don't control ingress — push your account manager for documented network controls; the rest of this checklist still applies to you.
3. Audit ir.actions.server with state=code. Anyone with admin login has arbitrary Python execution. If the MCP holds admin creds, Mythos has arbitrary Python execution.
4. Put a rate limit in front of the MCP. A Cloudflare WAF rule, fail2ban at the nginx layer, or a built-in token bucket. Anything is better than nothing.
5. Enable 2FA on admin accounts. TOTP, not SMS. Mythos isn't going to solve TOTP — don't carry that illusion either way.
6. Tee the api_keys.jsonl audit log offline. Disk-only audit can be erased by an attacker with write access. Tee it to remote syslog or a Loki instance.

If your MCP server is one of the vulnerable or completely vulnerable entries in the table above, the swap isn't urgent — it's necessary. By the end of 2026, publicly-available Mythos-class models will be a fact. Project Glasswing is the exception, not the rule.

9. Sources

• Anthropic — Mythos Preview (official technical report)
• UK AI Security Institute — Mythos evaluation
• The Hacker News — MCP Design Vulnerability Enables RCE
• The Hacker News — Mythos finds thousands of zero-days
• OX Security — The mother of all AI supply chains
• The Register — MCP design flaw, 200K servers at risk
• OWASP MCP Top-10 2025 — MCP01 Token Mismanagement
• Wiz — Claude Mythos analysis
• ERP.today — Mythos and financial systems
• Gravitee — State of AI Agent Security 2026