How to Check If Your WordPress Site Is Leaking API Keys

The fastest way to turn a healthy WordPress site into a $50,000 cloud bill is to leak an AI API key. The fastest way to find out you've leaked one is when the bill arrives. The five minutes between those two moments is the version of this audit you don't want to learn the hard way.

This guide walks through the four places WordPress sites most commonly leak API keys, the exact URLs and files to check, and the free tools that automate the audit. Everything in this post can be run against your own site right now without installing anything.

If you'd rather skip the manual work, our free WordPress security scanner reads the same endpoints and flags every common key-leak pattern in under 30 seconds.

Why This Audit Matters Now

The economics of API-key theft changed in 2026. Stolen credit cards have to be laundered through goods or cashout services. Stolen logins need a sale pipeline. Stolen API keys (especially AI keys from Anthropic, OpenAI, and Gemini) convert directly to compute time on the victim's bill. One anonymous developer ran up $82,314 in unauthorized Gemini charges in 48 hours on a key that was leaked, not phished.

WordPress sits in the crosshairs because the platform handles a huge fraction of the world's website traffic, runs a thriving plugin ecosystem with uneven security bars, and just shipped a native AI client in core with WordPress 7.0. Every plugin that asks for a key creates a potential leak surface.

Here are the four leak categories worth checking on every site you run.

1. The Public REST API Index (/wp-json/)

Every WordPress site exposes a JSON index of its REST API at https://yoursite.com/wp-json/. This endpoint has to be public so the block editor, mobile apps, and headless front ends can discover what routes exist. The problem: any plugin that registers a route with default arguments will have those arguments listed in the index, including any bearer tokens embedded in the URL path.

This is exactly how the AI Engine plugin leaked its MCP bearer token in CVE-2025-11749. The token was embedded in the URL pattern, the route was registered with show_in_index left at default, and Google had indexed the JSON before anyone noticed. We covered the full chain in the AI Engine MCP token writeup.

To audit your own site:

1. Open https://yoursite.com/wp-json/ in a private browser window (no admin auth)
2. Search the response (Ctrl+F or Cmd+F) for these strings: token, key, secret, bearer, api_key, mcp
3. Pay extra attention to any route patterns that look like /wp-json/{plugin}/{long-random-string}/. Long random strings in URL paths are almost always tokens.
4. For each suspicious route, check whether the random-looking segment is in the WordPress options table (wp_options where option_name LIKE '%token%'). If it matches, that's a public token leak.

If you find anything, treat the token as already burned. Rotate it at the provider, deactivate the plugin until the maintainer patches, and check your access logs for unauthorized calls.

2. The wp_options Table With autoload = yes

Plugins that store API keys often write them to the wp_options table. That's fine when the option is private and unautoloaded. It becomes a problem when the option is set to autoload = yes, which means WordPress loads it on every page request, and worse, exposes it via plugins that ship debug tools or status dashboards.

To audit, log in to WP Admin and run this query in a tool like phpMyAdmin or via WP-CLI:

SELECT option_name, autoload FROM wp_options
WHERE option_name LIKE '%api_key%'
   OR option_name LIKE '%token%'
   OR option_name LIKE '%secret%';

Any row with autoload = yes is loading on every request. That's a performance hit and an information-disclosure risk if your site runs a status plugin that dumps autoloaded options.

The quick fix is a one-liner via WP-CLI:

wp option set autoload your_plugin_api_key no

The better fix is to use a secrets manager (the AWS Secrets Manager, HashiCorp Vault, or even a custom mu-plugin that pulls from environment variables). For most sites that's overkill, but for any site handling AI keys worth more than a thousand dollars, it's the right call.

3. Exposed .env, wp-config.php, and Backup Files

The third leak category is files that should never be reachable from the web but are. These include:

• .env files in the document root
• wp-config.php.bak, wp-config.old, wp-config~, and other editor-generated backups
• .git/config if the site was deployed by cloning a repo into the document root
• Database dumps left in /backups/, /dump.sql, /db.sql, /site.sql

To audit, try these URLs against your site:

• https://yoursite.com/.env
• https://yoursite.com/wp-config.php.bak
• https://yoursite.com/wp-config.old
• https://yoursite.com/.git/config
• https://yoursite.com/backup.sql
• https://yoursite.com/dump.sql

A correct configuration returns a 403 or 404 for all of them. A misconfiguration returns the file contents, and the file contents include database credentials, salts, and any keys that have been hard-coded into wp-config.php.

This is the highest-impact, lowest-effort check on this list. Run it every time you onboard a new site.

4. Plugin Settings Pages Visible to Editor or Author Roles

The fourth pattern is more subtle. A plugin stores its API key in an option, then renders an admin settings page that shows the key in a form field. The page is registered with manage_options, so it's gated to administrators. Fine.

Then a different plugin registers the same settings page with edit_posts or publish_posts instead, or the plugin author forgets to check capabilities at all, or a multisite role-mapping configuration exposes the screen to lower-privileged users. Now an Editor can read the admin's API key.

To audit this:

1. Create a test user with the Editor role
2. Log in as that user
3. Try to access every plugin settings page directly via /wp-admin/options-general.php?page=plugin-slug
4. Note any page that loads (instead of redirecting to the dashboard or showing a permissions error)
5. On every page that loads, search the HTML source for API keys, tokens, and secrets

Pay extra attention to any AI plugin, payment-gateway plugin, or third-party integration plugin. These are the categories that handle the highest-value credentials and historically have the spottiest capability checks.

This is also the leak category that's hardest to fix at the site-owner level. The right fix lives in the plugin's code. If you find a plugin failing this check, file an issue with the maintainer and consider replacing the plugin if a patch doesn't land within a few weeks.

The Automated Version of This Audit

Doing this manually on a single site takes 15 to 20 minutes. Doing it across 50 sites is a week of work. That's the gap our scanner closes.

WP Vanguard's free surface scan checks all four categories on any public WordPress site in under 30 seconds:

• It reads /wp-json/ and flags any route argument that looks like a credential
• It probes the common exposed-file paths (.env, wp-config.php.bak, .git/config, common backup paths)
• It checks the version-disclosure and information-disclosure patterns most plugins fail
• It cross-references the plugin fingerprints against known recent CVEs

The surface scan is free and doesn't require SSH or admin access. For sites where you want the deeper check, including the autoloaded options and capability-mapping audits, the deep scan (with SSH) covers the SQL-level checks too. Both are documented in our security scanner comparison post.

For agencies and enterprise sites that need a human review on top of the automated scan, Wbcom Designs' WordPress Code Audit covers the SQL, capability, and architecture checks that an automated scanner can't catch. It's run by the same team that built WP Vanguard.

What to Do If You Find a Leaked Key

If any of the four checks above turn up a credential, the response order is:

1. Rotate the key at the provider, immediately. Don't wait to investigate. The 48-hour window in the Gemini case wiped out a year's worth of budget. Get the old key into a "revoked" state first.
2. Check your provider's usage dashboard for the last 30 days. Look for unusual volume, unusual model selection (attackers often jump to the most expensive model), and unusual times of day. If you see anomalous usage, that's evidence the key was already being abused.
3. Patch the leak source. Deactivate the plugin, update WordPress, restrict the exposed file, or whatever specific fix the leak category demands.
4. Check for indicators of broader compromise. A leaked API key is often part of a larger breach. Read our guide on signs your WordPress site has been hacked and run the deeper checks.
5. Document the incident. What plugin? What version? What was leaked? When did you rotate? This documentation matters if you need to dispute provider charges or report to a security disclosure program.

Make This a Weekly Habit

The four checks in this post take 20 minutes the first time and three minutes once you know what you're looking at. Running them weekly catches new leaks before they become bills. Running them after every plugin install catches the worst-offender plugins before they can do real damage.

For sites where the cost of getting this wrong is meaningful (any site connected to AI billing, any site processing payments, any site with customer data), automate the check. WP Vanguard's deep scan can run weekly via cron and email a report. For more comprehensive coverage including server-level configuration and the kind of cross-cutting checks that need a human, Wbcom Designs' WordPress Security Hardening bundles the scanning, the remediation, and an ongoing retainer.

The new threat economy rewards attackers who automate. The defense has to automate too.

Scan your site now. WP Vanguard's free surface scan checks for leaked API keys, exposed configuration files, and known plugin vulnerabilities in under 30 seconds. No signup required for the first scan.

For agencies and high-value sites: the team behind WP Vanguard offers full WordPress Security Hardening and independent Code Audit engagements at wbcomdesigns.com.