AI Code Security Review for WordPress: What Actually Works

Running an AI code security review on a plugin or theme before client handoff has become part of my standard workflow. Not because AI catches everything, but because it catches the mechanical vulnerabilities faster than tired eyes do after a long development sprint. In practice, three tools earn a place in that process. Here is what each one catches, what all of them miss, and a three-pass checklist that fits a realistic solo workload.

Vibe coding is creating a specific kind of security debt in WordPress

The number worth pausing on: security researchers paired AI static analysis with automated verification and surfaced more than 300 critical zero-days across the WordPress plugin ecosystem in approximately 72 hours. Not obscure fringe plugins. Plugins with significant install counts.

What is driving this? The short answer is vibe coding: developers shipping LLM-generated plugin code they have not fully read. The model produces functional logic quickly. The developer commits it without auditing the input sanitization, the nonce checks, the capability verification. The outcome is a double trust problem. The developer trusts the AI output. Then that AI output trusts user input without sufficient validation.

On a brochure site, the consequence is limited. On a WooCommerce installation handling real transactions, or a multisite network with client sub-sites, a missed esc_html() call or an absent current_user_can() check is a meaningful exposure. One agency audit of a vibe-coded plugin uncovered more than 100 distinct security issues in a single codebase.

This is not a case against AI-assisted development. It is an argument for treating the security review step as non-optional rather than a nice-to-have tacked on when time allows.

What AI reviewers actually catch in WordPress PHP

AI security review tools scan code structure, not runtime behavior. That distinction is the first thing to internalize before building it into a delivery workflow.

Where they perform reliably on WordPress PHP:

• Unsanitized output: missing esc_html(), esc_url(), and wp_kses() calls before echoing user-controlled content into the page

• Unprotected AJAX handlers: missing nonce verification via check_ajax_referer(), or no capability check before executing a privileged action

• Raw database queries: $wpdb->query() or $wpdb->get_results() calls with interpolated variables instead of $wpdb->prepare()

• Insecure file operations: include, require, or file_get_contents() accepting user-supplied paths without validation

• Unguarded option updates: update_option() calls reachable without checking user permissions

At the usage level, here is what one observes: Claude Code and Cursor are both effective at these patterns because they have seen enough WordPress code to recognize the standard idioms. They understand that sanitize_text_field() exists and that nonce checks belong at the start of AJAX handlers, not buried three functions down the call stack.

Where they are consistently unreliable:

• Business logic errors in WooCommerce order processing and coupon flows

• Race conditions in inventory and stock management

• Auth flow vulnerabilities that depend on execution sequence across multiple functions

• Context-specific issues that require knowing whether a site runs in multisite mode, under a specific hosting constraint, or behind a reverse proxy that strips headers

A useful working model: AI security review is a first-pass filter. It raises the floor. It does not guarantee the ceiling.

Three tools that earn a place in a WordPress security pass

The market for AI code review has expanded considerably in 2026. For WordPress freelances and small agencies, three tools stand out for different reasons, and none of them replaces the others entirely.

SonarQube Community Edition is the most methodical option for PHP codebases. The free self-hosted tier runs static analysis on a plugin or theme directory, flags cyclomatic complexity hotspots, and identifies known vulnerability patterns in PHP with a rule engine that covers the WordPress security landscape well. Quality gates can be configured to fail a build when specific thresholds are crossed, which is useful if you have any CI pipeline running against your client work.

The practical limitation is setup overhead. Running SonarQube as a one-off on a new client project requires either an existing shared instance or a meaningful block of configuration time before you get results. Worth having configured if you review code regularly; harder to justify for occasional project work.

Cursor earns its place because security review happens inside the development tool rather than as a separate workflow. Agent mode accepts direct prompts against a plugin directory: ask it to review for WordPress security vulnerabilities with a focus on input handling, capability checks, and database query preparation, and the responses are contextually aware in a way that a generic static analyzer is not. In practice, it catches more than a surface pattern pass, particularly on less common vulnerability types where the pattern recognition is subtler.

The free tier is functional for occasional reviews. The Pro tier at $20 per month makes sense if you are running security passes on multiple client projects each month.

Tabnine is the choice when client code confidentiality is a hard requirement. Its on-premises and air-gapped deployment options mean code never leaves your infrastructure. For agencies working under NDAs or with clients who have sensitive business logic embedded in their plugin code, this matters more than marginal quality differences between Tabnine and a cloud-hosted model. The security review capability is secondary to its core code assistance function, but for confidentiality-constrained work it is the appropriate tool in this category.

Claude Code sits in a distinct category: agentic review rather than inline suggestion. Pointing it at a full plugin directory and requesting a structured security audit produces detailed output organized by severity and issue type, clean enough to share with a client as a delivery artifact. The practical caveat is that the false positive rate on WordPress PHP is non-trivial, particularly around custom sanitization implementations that differ from the standard WordPress idioms. Every finding needs manual verification before it goes into a client document.

What AI consistently misses, and the liability this creates

False positives attract the loudest complaints about AI code review tools. The more consequential problem is the category of vulnerabilities that AI tools consistently cannot surface.

Business logic errors do not look like security issues to a static analyzer. A WooCommerce coupon stacking vulnerability that allows applying the same discount code multiple times passes every automated check because no individual function is malformed. Understanding the vulnerability requires understanding the business intent and tracing execution across multiple functions and request cycles.

Authentication flow vulnerabilities are similarly opaque. A custom login implementation with a sequence dependency between two functions may pass AI review of each function in isolation. The vulnerability only becomes visible when you understand the order in which the functions execute and what state each one assumes has already been set by the previous call.

The practical consequence for freelances: AI review is not a replacement for reading your own code. What it replaces is the most mechanical part of that process, the pattern-matching pass for known vulnerability types. That frees attention for the harder conceptual work that requires human judgment about intent and context.

Marginalia: the median time from public vulnerability disclosure to widespread exploitation across the WordPress ecosystem is approximately five hours. A vulnerability in a shipped plugin is not a slow-burn problem that allows a comfortable remediation window. The argument for running security review before delivery is a practical one, not a theoretical one.

A pre-delivery checklist that works in practice

Ce folio couvre trois passes concretes: three passes that together take under an hour on a typical custom plugin or block theme, and produce a defensible review record.

Pass 1: Automated static analysis (15 minutes)

Run the plugin or theme through PHP_CodeSniffer with the WordPress-VIP-Go ruleset, or through SonarQube if you have a shared instance already configured. Address every critical finding before moving forward. Do not skip this step on the grounds that the plugin is small or that the code looks clean. The mechanical errors this catches are precisely what AI-generated code introduces at speed, and PHP_CodeSniffer catches them reliably without requiring you to read the code yourself first.

Pass 2: AI semantic review (20 minutes)

Open Cursor or Claude Code, load the full plugin directory, and run a focused prompt. The prompt matters: ask specifically about input handling at user-controlled data entry points, database query preparation, AJAX handler protection (nonce and capability), file system operations, and option management. Log every finding, including ones you assess as false positives. A log of dismissed findings is useful documentation if a client later asks how you reviewed the code before delivery.

Pass 3: Manual boundary review (25 minutes)

For every AJAX endpoint, REST API endpoint, and admin action hook in the plugin: verify the nonce check is present and positioned correctly, verify the capability check uses the appropriate capability for the action being performed, verify that user-controlled input is sanitized before processing and escaped before output. This pass cannot be automated. Do it by hand, working systematically through every public-facing entry point in the plugin.

The output of this three-pass process is what you include in a delivery document. The AI passes inform it. The manual pass is what you sign your name to.

The EU compliance deadline that most freelances have not planned for

By September 2026, plugin and theme developers distributing to EU users are required by law to operate a vulnerability disclosure program. The requirement covers a documented process for receiving security reports, a defined response window, and a security contact that is not a public GitHub issue tracker.

For freelances and small agencies shipping custom plugins to EU clients, including private or single-client plugins, the obligation applies. The practical implication is that an informal approach to post-delivery security patching is no longer a legally defensible position for EU-facing work.

Building a security review step into the pre-delivery workflow is not a compliance program on its own. But a logged and documented three-pass review is part of a defensible process that demonstrates due diligence when a vulnerability report eventually arrives. And one will arrive, on a long enough timeline.

When a targeted pass is proportionate and when it is not

A l'usage, voici ce que l'on constate: the right scope depends on the project's risk surface, and the two cases are quite different in practice.

For a block theme with no custom AJAX handlers, no server-side data processing beyond standard WordPress hooks, and no user-contributed data paths, the three-pass process described above covers the realistic exposure. A full formal security audit would be disproportionate to the actual risk.

For a custom plugin handling user authentication, order processing, file uploads, or privileged data operations, a formal review with documented findings is the appropriate scope. The three-pass process is a starting point for that work, not the conclusion of it.

The colophon of this article: run the automated pass on everything you ship to clients. Reserve the full audit scope for projects where the exposure warrants it. And do not treat the output of an AI reviewer as equivalent to the conclusion of a security audit. They are related processes. They are not interchangeable ones.