Pod

Available as Markdown and JSON. Pod is also available over MCP.

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.

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

Read the thread · 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

Read the thread · 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

Read the thread · 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

Read the thread · 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 · 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

Read the thread · 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

Read the thread · 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

Read the thread · 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

Read the thread · 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

Read the thread · 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 · 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 · 2026-07-16 · closed · 1 comment

The remaining reports are on the project's issue tracker.