/wordpress-security-review

name: wordpress-security-review
description: "Use when the user asks 'is my site secure', 'run a security audit', 'check for vulnerabilities', 'was my site hacked', or 'fix the vulnerable plugins'. Runs the Respira security audit, reads its indicators, coverage and known vulnerabilities honestly, never calls a partial scan clean, and fixes what it finds one approved step at a time."
license: MIT
metadata:
  author: Respira for WordPress
  author_url: https://respira.press
  version: 1.0.0
  mcp-server: respira-wordpress
  category: audit
  respira_min_version: 9.0.0

WordPress Security Review

Runs the security audit built into Respira, explains what it found in plain words, and fixes what can be fixed, one approved step at a time.

What this skill does

A security check an agent improvises usually grades a site on whether a security plugin is installed. That says nothing about whether the site is patched, whether an administrator appeared last week, or whether the uploads folder runs PHP. The Respira audit answers those questions from evidence WordPress itself can verify, and it says which questions it could not answer.

This skill runs it, reads every part of the result, and keeps the report honest: a check that did not run is reported as not run, a scan that hit its limit is reported as partial, and a vulnerability database that could not be reached means "not checked", never "clean".

**Handles:**

• The audit: core checksums, administrators and their application passwords, plugins, themes, must-use plugins, cron hooks, indicators and coverage
• Known vulnerabilities: installed core, plugin and theme versions matched against the Wordfence vulnerability database (plugin 9.0 and later)
• The uploads execution probe, only with the owner's consent
• Fixes: plugin, theme and core security updates behind approval, and credential clean-up with explicit consent
• A second audit after the fixes, saying what cleared and what remains

What this skill does NOT do

• **Call a site clean when it could not look.** Partial coverage, a check that did not run, or an unavailable vulnerability database are reported as exactly that.
• **Delete, deactivate or replace anything without asking.** Not plugins, not users, not files. The audit never runs clean-up queries, and neither does this skill.
• **Revoke a credential on its own judgement.** An application password is revoked only when the owner names it and says yes.
• **See the host.** Server cron, access logs, wp-config secrets and backups are outside what WordPress can verify. The audit says so in `coverage`, and so does the report.
• **Replace a forensic investigation.** Indicators are questions. A confirmed break-in needs the host and a professional.

Requirements

• Respira for WordPress 9.0 or later for the known-vulnerability match, `respira_update_theme` and `respira_revoke_application_password`. On 8.x the audit still runs: say that the vulnerability match needs plugin 9.0, and list themes to update by hand.
• Plugin management switched on in Respira settings, for plugin and theme updates.
• A recent backup the owner can restore, confirmed before any update. Respira's page snapshots do not cover plugin, theme or core files.
• A connection made with an administrator's key. From 9.0 the audit answers administrators only, because its result names every administrator and credential.

Trigger Phrase

• "is my site secure"

Alternative Triggers

• "run a security audit"
• "check for vulnerabilities"
• "was my site hacked"
• "fix the vulnerable plugins"
• "security review"

Execution Workflow

Phase 1: Run the audit

1. `respira_get_site_context` to confirm the site and its Respira plugin version. 2. `respira_run_security_audit` with `deep_scan: true`. The deep scan inspects uploads, wp-content/cache and must-use plugin paths for executable files, within strict time, file and result limits. On plugin 9.0 and later it only reads. On older plugins it also writes and deletes one inert probe file in uploads, so ask the owner first there, because file-change monitors may report it. 3. Leave `probe_uploads_execution` off for now. Phase 3 asks for it.

Phase 2: Read the whole result

Read every block and report each one in plain words:

• **`indicators`**: each has an `id`, a `severity` and a `summary`, and its `evidence` often carries a `note`. Report every indicator with its summary and note. An indicator is a question, not a verdict: `recent-administrator` looks the same for an account the owner added last week, which is why it asks.
• **`coverage`**: what was and was not checked.
• `executable_file_scan` is `complete`, `partial` (the bounded scan reached a limit) or `not_run`. Partial or not run means the uploads were not fully checked; never describe them as clean.
• `host_cron`, `host_access_logs`, `wp_config_secrets` and `external_backup_state` are false: Respira cannot see these. Say so once.
• `application_passwords`, `database_file_privilege` and `wp2shell_database_artifacts` say whether each check completed or was unavailable.
• `recent_administrators` gives the window in days and how many accounts it flagged, so a 0 is read against how far back it looked.
• **`known_vulnerabilities`** (plugin 9.0 and later): installed software matched against the vulnerability database. Its `status` is `ok` when the match ran, and then every match carries the version that fixes it: report them most severe first. `unavailable` means the database could not be consulted, and `reason` says why (for example, no Respira licence is connected); `not_run` means the call switched it off. In both cases, and when the block is missing because the plugin is older, say the vulnerability check did not run. Only `ok` with no matches means no known vulnerabilities were found. `coverage.known_vulnerabilities` repeats the status.
• **`checks`**: the evidence behind the indicators (core checksums, administrators and their application passwor