Table of Contents
TL;DR
- The plugin readme is marketing copy. The PHP source is what runs. Reading both at once is the only honest way to know whether a plugin’s documented behavior matches what executes when an HTTP request reaches it.
- An AI plugin code review reads the PHP source and emits a categorized risk report with line references. Input sanitization gaps. Direct $wpdb queries that bypass prepare(). Calls to eval() or obfuscated base64 payloads. Missing wp_verify_nonce() on form-handling endpoints. Missing current_user_can() capability checks. Deprecated WordPress API use.
- Five-step setup. Run wp plugin check first if the plugin is already installed — Plugin Check from WordPress.org enforces the same PHPCS rules plugin reviewers use on every new submission. Paste the PHP source files into the chat, file by file. State your live WordPress version, PHP version, and the plugin’s claimed Tested-up-to header value. Ask for line-numbered red flags. Open every flagged file in the editor and read each line in context.
- The AI pass is not the auditor. Plugin Check’s own FAQ states the tool is "not a replacement for the manual review process" because static line-level checks miss context-dependent flaws across files. A privilege check on the wrong role. A permission flow that compares a user-supplied ID to itself. A CSRF token protecting the wrong endpoint. None of these are detectable from a single-file scan.
- Open the bootstrap file first, then any file with handle or process in the name. The bootstrap file is the index of the plugin’s hook list. The handler files are where user input most often reaches the database. About fifteen minutes per plugin if the file count is modest, an hour for a complex stack like a page builder or a forms plugin.
The plugin readme is marketing copy. The PHP source is what runs. They are not the same document.
Most agency plugin trust decisions resolve before anyone reads the source. The plugin search returns three candidates for a feature. The lead developer reads the description, the install count, the last-updated date, and the support thread. The plugin gets approved.
That is acceptable for plugins from names you recognize. WordPress.org’s editor team, Yoast, WP Engine, the small set of vendors close to Automattic. The reputation is the audit.
The decision gets harder for the third row of plugin search results. The plugin you found because it was the only one matching a specific feature. The plugin from a developer name you have not seen before. The plugin whose review thread is mostly five-star and three messages long.
The reputation is thin.
This piece is about the AI code review pass that fills the gap. The chat reads the PHP source. The chat returns a categorized risk report with line references. The output is a shortlist of files a human should open first.
Why does the plugin readme not match the plugin source?
The readme is the document the plugin developer chose to write. The source is what their compiler ran.
The gap shows up in three concrete places.
The readme claims secure-by-default while a $_POST value reaches $wpdb->query() without a prepare() call. The readme advertises thousands of installs while a hardcoded debug constant from version 1.0 remains in production. The readme calls the plugin lightweight while the source loads a third-party library that registers six unscheduled cron events.
Reading both at once is the only honest answer. The readme is what the developer wants the buyer to believe. The source is what your server actually runs on every page load.
What does an AI plugin code review actually flag?
A categorized risk report with line references.
The chat reads the plugin’s PHP source and emits a list. Input sanitization gaps where $_POST or $_GET values reach the database without sanitize_text_field() or an equivalent WordPress helper. Direct $wpdb queries that bypass prepare(). Calls to eval(), base64_decode() of obfuscated payloads, or other code-execution patterns banned by the WordPress plugin directory.
Missing wp_verify_nonce() on form-handling endpoints. Missing current_user_can() capability checks on admin actions. Deprecated WordPress API use that signals a plugin nobody maintains.
The WordPress detailed plugin guidelines define the official list. Guideline 4 prohibits obfuscation. Guideline 8 forbids dynamically loaded executable code. Guideline 9 names the prohibited patterns including server-resource abuse without consent.
The same guidelines name security as "the ultimate responsibility of the plugin developer". WordPress.org reserves the right to close any plugin with security issues until the situation is resolved.
The output is a shortlist of files a human should open first. The chat is a first-pass scanner, not a verdict-by-itself.
How do you set up the prompt for a clean code review pass?
Five steps. None of them needs more than fifteen minutes.
Step 1 — run wp plugin check first. A built-in tool. Plugin Check from WordPress.org runs the same PHPCS rules plugin reviewers apply to every new submission. The CLI command is wp plugin check <slug>.
Plugin Check flags sanitization gaps, code obfuscation, direct database queries, and banned PHP functions like move_uploaded_file, passthru, and proc_open. Save the output for cross-reference against the chat’s report.
Step 2 — paste the PHP source files. File by file. Start with the plugin’s main bootstrap file. Then the file with the longest handler functions. Then the rest in order of size, largest first.
Step 3 — state the live versions. Three numbers. Your WordPress version, your PHP version, and the plugin’s claimed Tested-up-to header value. The chat’s training corpus may pre-date a recent deprecation in core.
Step 4 — ask for line-numbered red flags. Categorized output. Sanitization, capability checks, nonces, prepared statements, obfuscation, deprecated APIs. Each flagged line should be named with file path and line number.
Step 5 — open the flagged files in your editor. Read in context. Plugin Check and the chat agree on most of the obvious finds. The disagreement set is the interesting signal — either Plugin Check missed it or the chat hallucinated it.
wp plugin check the-plugin-slug
wp plugin check the-plugin-slug --format=json > pcp-report.json
About fifteen minutes per plugin if the file count is modest. An hour for a complex stack like a page builder or a forms plugin.
When does AI review not replace human review?
When the bug is context-dependent.
Plugin Check’s own FAQ frames the limit plainly. The tool is "not a replacement for the manual review process". WordPress.org’s plugin team hand-reviews every submission — the automated checker augments human review rather than replacing it.
The same caveat applies to LLM code review. Static checks catch fixed patterns.
A missing nonce. A raw $wpdb query without preparation. A call to eval(). A call to a banned PHP function.
Static checks miss what only a human reading two functions across two files can see. A privilege check that fires on the wrong role. A permission flow that compares a user-supplied ID to itself instead of to the authenticated user. A CSRF token that protects the wrong endpoint.
The WordPress Common APIs security handbook names the principles plainly. Trust nothing. Validate and sanitize input.
Escape on output. Use WordPress APIs. Maintain code currency.
Each principle is enforceable at line-level. None is enforceable across a multi-file business-logic flow. The chat is a competent first-pass. The chat is not the auditor.
What can go wrong with this approach?
Three traps catch developers who already know plugin code well enough to skip steps.
Trap 1 — trusting the report’s clean verdict. The LLM reads files in isolation. Vulnerabilities that span two functions across two files report as clean. A single-file pass means clean at line-level, not clean overall.
Trap 2 — skipping wp plugin check. Run both. Plugin Check enforces version-current rules on register_setting callbacks, wp_verify_nonce placement, and disallowed PHP functions. The chat’s training corpus is frozen at its cutoff date.
Trap 3 — treating the report as a binary install or avoid. Three-way verdict. The honest output is install, avoid, or trial in staging. The trial-in-staging cases are where most real plugin decisions sit. The AI plugin conflict diagnosis walkthrough covers what happens when a trial-in-staging plugin reveals a conflict the code review missed.
Why are the plugin readme and the plugin source different artifacts?
The plugin readme and the plugin source are different artifacts.
The readme is the document the plugin developer chose to write. The source is what the developer’s compiler ran. The reputation is what other developers chose to say. The code is what executes when a request reaches your server.
A defensible WordPress agency reads two of those three before approving an unknown plugin into production. The readme says what the plugin claims. The reputation says what other developers found. The source says what runs.
The third artifact is the only one your AI chat can actually read for you in fifteen minutes.
Other questions worth answering
How often should an agency rerun the security audit across dozens of client sites?
Twice a year per active third-party add-on, plus after every major version bump from the vendor. The WordPress.org Plugin Check tool ships updates several times a year against the latest core. A static rule list from 2024 misses sniffs added in 2026. Calendar the recheck against the vendor’s release tag, never against your own anniversary date.
What changes when a paid add-on lives on a commercial marketplace instead of WordPress.org?
Two changes. Premium marketplaces like CodeCanyon or vendor-direct portals skip the WordPress.org directory entirely. No Plugin Check on submission, no Detailed Plugin Guidelines enforcement, no public PCP report.
The vendor’s secure-by-default claim becomes the only filter before you install. The audit pass matters more for paid add-ons outside the directory.
Should you contact the add-on developer after discovering a security weakness?
Yes, after coordinated disclosure. Email the vendor with the file path, line number, and a reproduction. Wait roughly 30 days before publishing technical details publicly.
The WordPress Common APIs security handbook names trust-nothing as one of its guiding principles. A responsible vendor patches and credits you in the changelog.
How do you spot a hallucinated finding in the chat’s report?
Two tests in sequence. Cross-reference the chat’s output against wp plugin check, then open the file in the editor and read the flagged line yourself. The Plugin Check tool’s deterministic rules and your own reading of the source both have to agree. A real finding survives both.
Where should the categorized risk report live after a security audit closes?
Three artifacts in one folder. The chat output, the wp plugin check output, and your reviewer notes, all tagged by add-on slug and version. The vendor’s next major release invalidates the previous categorized risk report. A six-month-old approval on an older release says nothing about what the latest release does to your wp-admin.
Which file should you open first?
The plugin’s main bootstrap file. Then any file with _handle_ or _process_ in the name.
The bootstrap file is the index. It shows the hook list. Every action and filter the plugin registers, every admin page it adds, every REST API route it exposes, every cron event it schedules.
The hook list is the plugin’s actual surface area. Most security failures live somewhere in that list.
The handler files are where user input most often reaches the database. A function named _handle_form_submission or _process_user_action is the place the plugin developer most likely forgot a nonce check or a capability gate. Open them first.
About fifteen minutes per plugin if the file count is modest. An hour for a complex stack like a page builder or a forms plugin.
This piece pairs with the AI plugin pre-install reference check. The reference check covers the trust-by-reputation question. This code review covers the trust-by-source question. Together they replace the install-and-hope reflex that has produced most of the WordPress plugin breaches your support inbox already remembers.
If you want a calm second opinion on your first AI plugin code review report, you can contact me here. Send me the plugin slug, your wp plugin check output, and the chat’s report. I will read all three and tell you which file to open first. There is no pitch, no upsell, and the conversation is free.