WordPress AI Plugin Security Checklist: 8 Checks Before Install

Every WordPress site running AI features is one careless plugin away from a leaked API key, an LLMjacking incident, or an unauthenticated privilege escalation. The plugin author may have a great product idea and zero security background. The plugin you trust today may have a critical CVE next week. The vetting process matters more for AI plugins than for almost any other category, because the credentials they handle are directly billable.

This checklist is the 8-point vetting process we run before installing any AI plugin on a production site. It takes about 20 minutes per plugin the first time. After you've done it a dozen times, it takes 5 minutes. It catches the issues that have already burned thousands of WordPress site owners in 2026.

If you'd rather automate the parts that can be automated, WP Vanguard's surface scanner handles checks 3, 5, and 6 against any live site in under 30 seconds.

Why AI Plugins Need a Higher Bar

A typical WordPress plugin handles a fairly low-value asset. Form data, page content, an analytics ID. Even when those plugins have bugs, the upside for an attacker is moderate.

AI plugins handle API keys connected to billable accounts. The economics changed in 2026:

• The $82,000 Gemini bill showed what 48 hours of unmonitored key abuse looks like
• WordPress 7.0's WP AI Client put AI integration squarely into core, with more plugins building on top
• The AI Engine MCP token CVE showed that even the most popular AI plugin can ship a 9.8-CVSS bug
• A 2026 IEEE study found 8 of 17 tested chatbot plugins were vulnerable to prompt-injection key-disclosure attacks

The cost of installing the wrong AI plugin in 2026 is measured in thousands of dollars per incident. That's worth 20 minutes of vetting per plugin.

Check 1: Vendor Track Record on Wordfence and Patchstack

Before installing any AI plugin, look up the vendor's history in the two main WordPress vulnerability databases:

• Search wordfence.com/threat-intel for the plugin name
• Search patchstack.com/database for the plugin name

What you're looking for:

• How many CVEs has this vendor had in the last 24 months?
• What was the severity (CVSS score)?
• How quickly did they patch after disclosure?
• Did they handle disclosure responsibly, or did the researcher have to escalate?

A vendor with one or two medium-severity CVEs that were patched within a week is normal. A vendor with five critical CVEs in a year, or a pattern of disputing disclosures and shipping incomplete patches, is a red flag.

For AI plugins specifically, look at the type of CVE. SQL injection bugs are bad but well-understood. Authentication bypasses are catastrophic. Token-disclosure bugs (the AI Engine MCP pattern) are the canary in the coal mine because they signal that the vendor doesn't understand bearer-token security.

Check 2: Update Cadence

A plugin that's been updated within the last 60 days is actively maintained. A plugin that hasn't been updated in 6 months is a maintenance risk. A plugin that hasn't been updated in 12 months should be treated as abandoned regardless of what the vendor says.

For AI plugins this matters more than for static-feature plugins, because:

• AI providers regularly update their APIs, deprecate endpoints, and change authentication patterns
• New AI-specific attack patterns (prompt injection, model jailbreaks, key exfiltration techniques) appear constantly
• An abandoned AI plugin is a liability the moment its provider integration breaks or its dependencies hit a CVE

Check the "Last Updated" field on the plugin's WordPress.org page. Check the GitHub repo (if it has one) for the most recent commit. Compare the release frequency to your tolerance for stale code.

Check 3: How the Plugin Stores Your API Key

The single most important security characteristic of an AI plugin is how it stores the API key you give it. There are five tiers, from worst to best:

• Worst: Plain text in the URL path of a registered REST route. This is what the AI Engine plugin did. Anyone who reads /wp-json/ can read the key.
• Bad: Plain text in wp_options with autoload = yes. The key loads on every request and is visible to any plugin that dumps autoloaded options.
• OK: Plain text in wp_options with autoload = no. The key only loads when the plugin explicitly requests it.
• Good: Encrypted at rest using a key derived from wp-config.php constants. Even a database leak doesn't immediately expose the API key.
• Best: Pulled from environment variables or a dedicated secrets manager. The key never lives in the database at all.

How to check which tier your plugin is in:

1. Install the plugin in a staging environment
2. Configure it with a test API key
3. Open the database and search wp_options for the key value (or partial value)
4. If you find the key in plain text, it's in tier "OK" or "Bad" or "Worst"
5. Check the plugin's register_rest_route() calls in the source for any token-in-URL patterns

For AI plugins on production sites, tier "OK" is the minimum bar. Anything below that is unacceptable for a key worth more than a few dollars.

Check 4: REST Endpoint Authentication

Every AI plugin exposes REST endpoints. Some of them call out to the AI provider on the user's behalf, which means they need authentication to prevent unauthenticated visitors from running up the bill.

To audit:

1. Browse the plugin's REST endpoints in /wp-json/ (filter for the plugin's namespace)
2. For each endpoint that triggers an AI call, check its permission_callback
3. The permission callback should return false for unauthenticated requests unless the endpoint is explicitly meant to be public (a public chatbot, for example)
4. For public endpoints, check whether the plugin implements rate limiting per IP

A plugin that ships an AI-calling endpoint with permission_callback => '__return_true' and no rate limiting is a billable-resource leak waiting to happen. Skip it.

Check 5: Capability Checks on Settings Screens

The plugin's settings screen is where the admin enters the API key. If that screen is accessible to lower-privileged users, the key is accessible too.

To test:

1. Create a test Editor-role user
2. Log in as that user
3. Try to access the plugin's settings page directly via URL
4. Check whether the page loads, redirects, or shows an error
5. If the page loads, check whether the API key is rendered in the form (even masked as ••••••••, the value is often present in the HTML source)

Plugins that pass this test correctly gate every settings page behind manage_options. Plugins that fail are either using a weaker capability or skipping the capability check entirely. Either is a key-exposure risk.

This check is also covered in our step-by-step guide to checking for leaked API keys, which walks through the specific URL patterns to test.

Check 6: Does the Plugin Need a Reason to Exist?

A lot of AI plugins in 2026 are thin wrappers around an API call. They add a chat widget that calls OpenAI, or they add an admin button that calls Claude. The functionality is real, but the implementation could often fit in a 50-line custom mu-plugin written specifically for your site.

Before installing a third-party AI plugin, ask:

• Does it do anything I couldn't do with WordPress 7.0's WP AI Client directly?
• Does it integrate features specific to my stack (BuddyPress, WooCommerce, LearnDash) that justify the dependency?
• Is the plugin author handling the AI provider integration in a way I couldn't trivially replicate?

For complex integrations (a chatbot that drives BuddyPress profile completion, an AI-powered WooCommerce product recommender, an AI grader for LearnDash quizzes) a well-built plugin saves real time. For simple integrations (a single AI button in the post editor) you may be better off with a custom solution. Building it yourself, or hiring someone to build it, limits your attack surface to code you understand.

For sites where the AI integration is a significant feature, Wbcom Designs' AI WordPress Integration service covers exactly this gap. AI features built into WordPress admin and the block editor, with server-side key handling, proper capability enforcement, and WPCS-compliant code.

Check 7: Multisite and Role-Editor Compatibility

If your site is part of a multisite network, AI plugins create cross-site risk. The same API key may be visible to subsite administrators who shouldn't have provider-level access. Some plugins try to handle this with per-subsite configuration. Many don't.

To audit multisite:

1. Install the plugin on a network with at least two subsites
2. Configure the API key at the network admin level
3. Log in as a subsite admin and check whether the key is visible in any settings page
4. If yes, the plugin doesn't isolate keys correctly. Skip it for multisite use.

For role editor plugins (Members, User Role Editor) the risk is that an admin grants a custom role with manage_options, which then gets access to every plugin settings page including the AI plugin's. Audit any custom roles against your plugin's settings screens explicitly.

Check 8: Disclosure and Support Channels

A plugin author who responds to security disclosures in 24 hours and ships fixes within a week is dramatically lower risk than one who ignores reports or argues with researchers.

To gauge this without filing a disclosure yourself:

• Read recent reviews on the plugin's WordPress.org page filtered for "security" or "vulnerability"
• Check whether the plugin has a SECURITY.md file in its GitHub repo
• Check whether the vendor participates in disclosure programs (Patchstack, Wordfence, HackerOne)
• Look for the vendor's response in past CVE writeups. Did they engage constructively?

For AI plugins specifically, the disclosure muscle matters because the threat landscape changes weekly. A vendor who can't ship a fix in a week is going to leave you exposed for the next round of bugs that's already coming.

The Vetting Process in Practice

The 8 checks above sound like a lot. In practice, they're a 20-minute initial vet plus a 5-minute re-vet every 90 days. For a site running 3 AI plugins, that's one hour per quarter. Compared to the cost of an incident, it's the cheapest insurance available.

A pragmatic approach:

• Run all 8 checks before installing any new AI plugin
• Re-run checks 1, 2, 6, and 8 quarterly for every installed AI plugin
• Re-run checks 3, 4, 5, and 7 after any major plugin version bump
• Run a free surface scan on the site monthly to catch any new disclosure patterns

For agencies managing multiple client sites, automate what you can and budget for the rest. WP Vanguard's deep scan with SSH covers the parts of this checklist that need server access. For the parts that need human judgment, Wbcom Designs' WordPress Code Audit bundles the full plugin-vetting exercise across an entire site.

What "Good Enough" Looks Like

You don't need every AI plugin to be perfect. You need every AI plugin to be good enough that a single incident doesn't sink the site. Concretely, "good enough" means:

• The vendor has a clean recent vulnerability history (no critical CVEs in 12 months)
• The plugin is actively maintained (updates within 60 days)
• API keys are not exposed via REST, settings pages, or unauthenticated routes
• The site has independent guardrails (per-key spend caps, billing alerts) that limit the damage of any one plugin's failure

If a plugin fails the first three but you've set up the fourth correctly, the worst-case is a controlled loss. If a plugin passes all four, you've materially reduced your LLMjacking risk.

The combination is the point. No single check stops a determined attacker. The stack of small barriers is what makes the math unfavorable for them.

Scan your AI plugin install base. WP Vanguard's surface scan checks for REST endpoint exposure, plugin CVE history, and known leak patterns across every plugin on your site. Free for the first scan, no signup required.

Need help vetting plugins or building a custom integration? Wbcom Designs' WordPress Code Audit and AI WordPress Integration services handle the parts of this checklist that need a human review or a from-scratch build.