# Reported issues for WPGuard MCP Pod holds 12 of 12 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects. Back to [WPGuard MCP](/mcp/wpguard-mcp). ## Most discussed ### Plugin/theme update verb with automatic rollback on fatal error ## Problem Plugin/theme updates are the single most common real-world WordPress "oh no" event — an update breaks the site, and the site owner finds out from a support ticket, not from monitoring. No current tool (this one included) has a dedicated, safe verb for this. ## Proposed approach - Add a Tier2 \`wp_update_plugin\` / \`wp_update_theme\` verb: snapshot the current version (already-installed zip or version pin) before updating, run the update via WP-CLI, then immediately check for PHP… [Read the thread](https://github.com/cgallic/wpguard-mcp/issues/23) · 2026-07-16 · closed · 1 comment ### Notification webhook on packet-open / needs-approval / Tier3 eval fired ## Problem The propose/approve model (#1) is silently broken without this. If a packet needs approval and nobody is told, nobody goes and approves it — the guard becomes "changes just don't happen" rather than "changes go through review." This blocks wpguard-cloud's approval UI (cgallic/wpguard-cloud#5) from actually being useful too: a dashboard nobody's prompted to check doesn't get checked. ## Proposed approach - Add an optional, pluggable notifier: config specifies one or more webhook… [Read the thread](https://github.com/cgallic/wpguard-mcp/issues/21) · 2026-07-16 · closed · 1 comment ### Scheduled/webhook-triggered runs need their own approval semantics ## Problem Everything in the current guard model assumes an interactive session: an agent proposes, a human (or policy) approves, the agent applies. Unattended/scheduled runs (cron-triggered content updates, webhook-triggered mutations — an emerging pattern, cf. \`jolks/mcp-cron\`) don't fit that shape: there's no human in the loop at trigger time to approve anything. ## Proposed approach - Don't build the trigger mechanism until issue #1 (propose/approve split) ships — this depends on it. -… [Read the thread](https://github.com/cgallic/wpguard-mcp/issues/14) · 2026-07-16 · closed · 1 comment ### Per-token rate/cost budgets on agent actions (tighter for Tier3) ## Problem There's no limit on how many calls a token can make in a given window. An agent stuck in a bad loop (or a misbehaving/compromised client) can currently hammer the server, including Tier3 raw eval, with no throttle. ## Proposed approach - Add configurable per-token rate limits (calls/minute) and optionally a call budget per packet. - Set a tighter default limit on Tier3 (\`wp_eval\`) than Tier1/2, given its higher blast radius. - Return a clear rate-limit error (not a silent drop)… [Read the thread](https://github.com/cgallic/wpguard-mcp/issues/10) · 2026-07-16 · closed · 1 comment ### Sanitize/constrain recon output against prompt injection before it re-enters agent context ## Problem Tier1 recon tools (\`wp_recon\`, \`wp_get_option\`, \`wp_get_post_meta\`) pull live post/comment/option content straight back to the calling LLM as tool output. Since WordPress content routinely includes user-submitted text (comments, form entries, even post content on multi-author sites), this is a real prompt-injection / MCP "tool poisoning" surface (cf. OWASP MCP Tool Poisoning writeups, CVE-2025-54136) — a malicious comment or field value could contain text crafted to manipulate… [Read the thread](https://github.com/cgallic/wpguard-mcp/issues/9) · 2026-07-16 · closed · 1 comment ### Vulnerability-scan gate (WPScan/Patchstack) before Tier2/3 writes ## Problem None of the current tools check whether the site being mutated is already running a known-vulnerable plugin/theme version. Making changes to a site with an open vuln is a common way an unrelated mutation ends up implicated in an incident, and it's an easy, free check to add. ## Proposed approach - Add a Tier1 \`wp_vuln_check\` tool that queries the WPScan API (free tier: 25 req/day) or Patchstack's free tier against the site's installed plugin/theme versions (pulled from… [Read the thread](https://github.com/cgallic/wpguard-mcp/issues/8) · 2026-07-16 · closed · 1 comment ### Scoped/RBAC tokens instead of one shared bearer token ## Problem Auth is currently a single shared \`WPGUARD_MCP_TOKEN\` — any client holding it gets every tool, including Tier3 raw eval. There's no way to hand a lower-trust client (or a less-trusted AI harness) read-only or Tier2-only access without giving it the keys to Tier3. ## Proposed approach - Support multiple tokens in config, each with a scope: \`recon\` (Tier1 only), \`mutate\` (Tier1+2), \`admin\` (Tier1+2+3). - Auth middleware checks the token's scope against the tool's tier before… [Read the thread](https://github.com/cgallic/wpguard-mcp/issues/7) · 2026-07-16 · closed · 1 comment ### Optimistic concurrency (ETag/If-Match) on Tier2 mutation tools ## Problem Tier2 verbs read-then-write with no check that the target hasn't changed between the dry-run preview and the apply call. GravityKit's Block MCP guards this with ETag/412-style optimistic concurrency. Without it, a lost-update race is possible: dry-run previews against state A, something else (a human editor, another agent, a cron job) changes the post to state B, apply overwrites state B without ever seeing it. ## Proposed approach - Have dry-run (\`apply=False\`) calls return a… [Read the thread](https://github.com/cgallic/wpguard-mcp/issues/6) · 2026-07-16 · closed · 1 comment ## Most recent ### Add block-aware wp_mutate_block verb for Gutenberg content (not just raw search/replace) ## Problem \`wp_mutate_post_content\` currently does search/replace against raw HTML/serialized content. GravityKit's Block MCP (github.com/GravityKit/block-mcp) benchmarked structured block-tree edits at 9/9 success vs. 0/5 for raw-HTML edits on the same tasks — raw string mutation against Gutenberg's block-comment format is fragile and easy for an agent to corrupt. ## Proposed approach - Add a Tier2 \`wp_mutate_block\` verb that parses the post into its Gutenberg block tree (via… [Read the thread](https://github.com/cgallic/wpguard-mcp/issues/4) · 2026-07-16 · closed · 1 comment ### Per-target lock + open-packet polling for multi-agent coordination ## Problem This server is explicitly meant to be reachable by any MCP client — multiple AI agents (different harnesses, different sessions) could plausibly point at the same site concurrently. Right now nothing stops two agents from opening separate packets against the same target and racing a mutation, since packets aren't mutually exclusive per target. ## Proposed approach - When \`packet_open\` succeeds for a target, take a lightweight lock on that target (site + resource, e.g.… [Read the thread](https://github.com/cgallic/wpguard-mcp/issues/3) · 2026-07-16 · closed · 1 comment ### Re-verify after delay before closing a packet as verified ## Problem \`packet_close(status="verified")\` only requires a passing check at the moment of closing. That's a one-shot proof — it doesn't catch cases where the write appears to succeed immediately but doesn't durably stick (cache layer serving stale content, async sync to a CDN/replica not yet complete, a plugin re-writing the field on its own next cron tick). "Verified" and "durable" are not the same claim, and treating them as equivalent is how a change gets marked closed while the live… [Read the thread](https://github.com/cgallic/wpguard-mcp/issues/2) · 2026-07-16 · closed · 1 comment ### Split packet_open (propose) from packet_approve (authorize) ## Problem Right now \`packet_open\` both proposes AND authorizes a change — any Tier2/3 tool checks only "is there an open, target-matching packet," not "has this packet been approved by someone other than the proposer." This is the exact bug class a real production incident surfaced: a promotion/deployment path was approval-gated, but ~4 sibling write paths on the same service were not, because each tool implemented its own ad-hoc check instead of funneling through one shared gate. If… [Read the thread](https://github.com/cgallic/wpguard-mcp/issues/1) · 2026-07-16 · closed · 1 comment The remaining reports are on [the project's issue tracker](https://github.com/cgallic/wpguard-mcp/issues).