WordPress 7.0 Just Made Every Site an AI API Key Target

WordPress 7.0 shipped on May 20, 2026. Three days after release, Patchstack founder Oliver Sild published the first AI-related security report against it: the new AI integration setup form lets the browser autofill an Anthropic API key in plain text inside an autocomplete dropdown. The bug is tracked in WordPress GitHub ticket #65303. The fix is one HTML attribute. The bigger problem is the threat model behind it.

For the first time, WordPress core ships a standardized way for plugins and themes to talk to external generative AI providers. That's the WP AI Client (sometimes called the Web Client AI API in the dev notes). Anyone who installs WP 7.0 and connects an AI provider is now storing an API key on a WordPress site. And on the other side of the fence, attackers have spent 2026 perfecting the art of turning a stolen AI key into a five-figure bill in under a day.

This post covers what WordPress 7.0 actually changed, the first bug Patchstack found, the LLMjacking economy that makes stolen keys so lucrative, and what to do before you connect any AI provider to a WordPress site you care about.

What WordPress 7.0 Actually Changed

WP 7.0's release notes lead with three big-ticket items: real-time collaborative editing, the Web Client AI API, and responsive block visibility controls. The AI piece is what concerns us here.

Before 7.0, every plugin that wanted to call OpenAI, Anthropic, or Gemini rolled its own integration. AI Engine had its bearer token storage. Other chatbot plugins each had their own settings screen, their own API key field, their own request layer. From a security audit perspective that meant a different attack surface in every plugin. From a developer perspective it meant a lot of duplicate code.

WP 7.0 changes that. The WP AI Client is a programmatic interface in core. Any plugin can register an AI provider, the client handles authentication and request routing, and the model still lives external to WordPress. It's provider-agnostic, so Anthropic, OpenAI, Gemini, local Ollama instances, and anything that exposes a compatible API can all be wired in.

That centralization is good for code quality. It's also good for attackers, because it means there's now a single, predictable place in WordPress where AI keys get stored. Once a plugin or theme adopts the WP AI Client, the key lives in WordPress options, post meta, or a dedicated table that core defines. Any bug in that storage layer, or in any plugin that exposes it, hits every site running that plugin.

WordPress 7.0 also lifts the minimum PHP version. The core team recommends PHP 8.3 or later, which closes off a long tail of sites still running PHP 7.2 and 7.3 with known issues. That part is a security win. The AI surface is the part that needs new thinking.

The First Bug: GitHub Ticket #65303

Three days after release, Sild filed a report on the AI integration setup form. The exact issue: when an admin types an Anthropic API key into the field, the browser stores it in the autofill cache. The next admin to visit that screen, or the same admin on a different browser profile, sees the key appear as a plain-text suggestion in the autocomplete dropdown.

This isn't a server-side flaw. The key isn't being leaked over the wire. It's a client-side rendering problem. The form field is missing the right combination of autocomplete="off", autocomplete="new-password", or type="password" attributes. Without those, the browser treats the field like any other text input and caches it.

The exposure window is small but real. The key is visible to:

• Anyone who screen-shares while the form is open (support calls, recorded demos, Loom videos)
• The next user on a shared workstation
• Someone watching over the admin's shoulder
• A browser extension with read access to autofill values

The recommendation in the GitHub ticket is exactly what you'd expect: "The API key field should behave like a secure password field and should not display previously entered values as suggestions." That's a one-line patch.

A one-line patch on a form field doesn't sound dramatic. The reason it matters is the calculus on the other side. Sild's broader warning in the same disclosure: "There will be an absolute rush by hackers to steal API keys." Whatever the exposure mechanism, the prize is the same.

LLMjacking: When a Stolen API Key Costs $82,000

The clearest example of why stolen AI keys are so valuable is a story from February 2026. An anonymous developer running a Mexico-based startup posted on Reddit that their Gemini API key had been compromised between February 11 and February 12. The fallout: $82,314.44 in unauthorized charges in roughly 48 hours, against a typical monthly spend of $180. A 46,000% increase. Most of the charges were Gemini 3 Pro Image and Gemini 3 Pro Text usage.

The attackers weren't stealing data. They were running their own AI workloads on the developer's bill. The industry term for this attack pattern is LLMjacking: hijack a key, point it at the most expensive models you can find, run inference until either the key is rotated or the rate limit kicks in. For high-end image and code models, the per-minute spend is high enough that even short windows generate eye-watering bills.

Truffle Security followed up by scanning public sources and found 2,863 exposed live Google API keys with Gemini access. Google initially invoked its shared responsibility model: the platform is secure, securing the key is the customer's job. The developer was on the hook for the bill until press coverage forced a refund conversation.

What makes LLMjacking different from older API-abuse patterns is the speed and the math. Old credential-theft economies (credit card dumps, stolen logins, ad-fraud botnets) required infrastructure on the attacker's side: machines, time, ad campaigns, money-laundering pipelines. LLMjacking has none of that. The attacker runs curl against the victim's key. The victim's cloud provider does all the heavy lifting. The "product" is compute time, billable directly to the victim. There's no monetization step in between.

That economic shift is why AI keys are the new high-value target. As our earlier writeup on the AI Engine MCP bearer token leak put it: the whole security boundary is the token. Lose the token, lose the budget.

Why WordPress Sites Are Now a High-Value LLMjacking Target

Stolen-key economies follow the cheapest path. Attackers are not going to drop zero-days on Anthropic's infrastructure to extract keys. They're going to scan everywhere the keys are already accidentally exposed. Right now that means:

• Public GitHub repos with .env files committed
• MCP configuration files (GitGuardian found 24,008 unique secrets in public MCP configs in 2026, including 2,117 valid credentials)
• Browser extensions with overbroad permissions
• WordPress sites with leaky plugins

WordPress sits in a specific sweet spot. There are roughly 500 million WordPress sites. Many of them have admins who follow tutorials that say "paste your API key here." A growing share of those tutorials are for AI plugins. The plugin ecosystem is huge, the security bar for individual plugins is uneven, and the bearer-token storage patterns are still being figured out.

We've seen the pattern already. The AI Engine plugin had its MCP bearer token printed into the public REST API index for any visitor to read (CVE-2025-11749, 9.8 CVSS, 100,000 sites affected). The IEEE study on WordPress AI chatbot plugins found 8 of 17 vulnerable to prompt injection that could be turned into key disclosure. These weren't edge cases. They were the first wave.

WP 7.0 doesn't make any of those existing vulnerabilities worse. What it does is invite more plugins into the AI space by lowering the integration cost, and create a predictable storage path for the keys those plugins handle. Both of those are reasonable design choices for a CMS. They also mean the next year of WordPress vulnerability disclosures will include a lot more "key disclosed via X" reports.

The other accelerant: the LiteLLM supply chain compromise. On March 24, 2026, two malicious versions of LiteLLM (1.82.7 and 1.82.8) were published to PyPI by the threat actor TeamPCP. The payload was a three-stage credential stealer targeting 50+ categories of secrets, plus a Kubernetes lateral movement toolkit, plus a persistent backdoor. The compromise was enabled by a stolen Trivy CI token. PyPI quarantined the package within three hours, but for a library used in AI proxy stacks across enterprise environments, three hours was enough.

That story isn't about WordPress directly. It matters because it shows that even tooling built specifically to manage AI credentials is being targeted. A WordPress site is a softer target than a Python proxy library, and there are vastly more of them.

Six Things to Do Before You Connect an AI Key to WordPress 7.0

If you're planning to use the WP AI Client, or you've already installed a plugin that adopts it, these are the steps worth doing before the key goes in.

1. Use a per-site, scope-limited key. Don't reuse your developer key. Generate a fresh key in the provider dashboard, restrict it to the model and rate limit your site actually needs, and label it with the site domain so you can revoke it cleanly.

2. Set a hard spending cap at the provider level. Anthropic, OpenAI, and Gemini all support per-key spend limits. Set them. The $82,314 Gemini bill happened to a developer with no cap. With a $50 cap, the worst case is $50.

3. Set a billing alert at $5 above your usual monthly spend. Most LLMjacking attacks ramp fast. If you usually spend $20/month and an alert fires at $25 within an hour, you have time to rotate. Without an alert, you find out at month-end.

4. Audit your plugin list for AI integrations. Run through wp-admin/plugins.php and check whether any plugin asks for an AI provider key. For each one, check Wordfence and Patchstack disclosures in the last 90 days. If the plugin has a recent CVE on its REST or settings endpoints, treat the key as already compromised and rotate.

5. Lock down access to the WP admin where keys live. AI keys generally live behind admin auth. If admin auth is weak (no 2FA, shared passwords, an old leaked session), the keys are weak. The WordPress security checklist covers the basics. The relevant additions for 2026: 2FA on every admin account, application passwords on a need-only basis, and an audit of admin-capable roles after every plugin install.

6. Watch the /wp-json/ index after any AI-related plugin install. The AI Engine CVE worked by printing the bearer token into the public REST index. That class of bug will reappear. A simple curl https://yoursite.com/wp-json/ | grep -i token after any AI plugin activation is cheap insurance.

If you'd rather not check by hand, WP Vanguard's surface scanner reads the same REST index and flags any plugin route that's leaking auth material. Deep scans (SSH-enabled) go further and audit option storage for plaintext keys.

What's Next

WP 7.0 is going to land on a lot of sites over the next ninety days. The auto-update window for major versions is opt-in, so the curve will be slow at first, but plugins will start advertising "WP AI Client compatible" through the summer. Each of those plugins is a new key-storage surface.

We're going to track the disclosures as they come. The April Week 4 roundup and the May 2026 roundup both already included AI-adjacent bugs. The June roundup will almost certainly include the first WP 7.0-specific ones.

If you run sites for clients, the conversation worth having now (before any plugin asks them to paste a key) is the one about scope-limited keys, spend caps, and billing alerts. The $82,314 bill from February was an unprepared developer learning the rules in production. The next one is going to happen on a WordPress site, and the bill is going to land in someone's lap who didn't know to put guardrails on a setting they had never heard of three months ago.

References

• WordPress 7.0 release page: make.wordpress.org/core/7-0/
• Patchstack disclosure of WP 7.0 AI form bug: searchenginejournal.com/wordpress-7-0-faces-security-concerns-over-ai-api-keys
• AI Engine MCP bearer token CVE-2025-11749: esecurityplanet.com/threats/news-wordpress-vulnerability-100k-impact
• $82,314 Gemini API key story: theregister.com/2026/03/03/gemini_api_key_82314_dollar_charge
• LiteLLM PyPI supply chain compromise: securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign
• GitGuardian State of Secrets Sprawl 2026 (MCP configs): blog.gitguardian.com/the-state-of-secrets-sprawl-2026

Scan your WordPress site for leaked auth material. WP Vanguard's surface scan inspects the REST API index and exposed configuration endpoints for tokens, keys, and other secrets that shouldn't be public. Run a free scan or see pricing.

Need a human-led audit? The team behind WP Vanguard runs WordPress Security Hardening and independent WordPress Code Audit engagements at wbcomdesigns.com for agencies and enterprise sites that need a full review before connecting AI keys to production.