Built for the agency reality where “just update everything” isn’t a plan, since abandoned plugins and client budgets get in the way. Swap in your own dashboard export and the prioritization logic still holds across a portfolio of any size.
Security
Audit plugin and theme update hygiene across a multi-site portfolio
A management-dashboard export showing which of 22 client sites are running abandoned plugins, EOL PHP, or versions years out of date, prioritized by real exposure rather than by how long the list is.
Works with Claude / GPT441 uses★ 4.4
The prompt
security-plugin-theme-update-hygiene-audit
Portfolio update-status export across 22 client sites managed from a central dashboard: [- 6 sites running at least one plugin that hasn't been updated by its developer in 2+ years and no longer appears in the plugin repository - 4 sites still on PHP 7.4, which reached end of life some time ago - 9 sites have plugins flagged 3 or more major versions behind current - 3 of the above sites take payments directly through a WooCommerce checkout, the rest are brochure or content sites - 1 site is running a plugin with a publicly disclosed unauthenticated RCE in the version currently installed] Prioritize and plan this the way an agency handling real client risk would, not by list length: 1. Rank the 22 sites by actual exposure, not by count of outdated items: the site with a known unauthenticated RCE goes first regardless of anything else, then payment-processing sites on EOL PHP or abandoned plugins, then everything else. 2. For abandoned plugins with no repository listing, treat "update it" as often not an option, and lay out the real choices: find an actively maintained replacement with equivalent functionality, fork and patch internally if the plugin is small enough, or remove the feature if it's low-value. 3. For the RCE site specifically, give the immediate step before any planned maintenance window: is there a WAF rule or the plugin's own emergency mitigation that closes the hole today, since waiting for a scheduled update cycle isn't acceptable with that severity. 4. Draft a short client-facing update for the sites that need action, explaining what's outdated, what the real risk is in plain language, and what happens next, without either alarming a low-risk brochure-site client or under-selling the urgency to a checkout-site client. 5. Propose an ongoing cadence so this doesn't pile up again: staging-tested update windows, and an alerting threshold (for example, anything unpatched for 30+ days on a payment-processing site) that triggers proactive outreach instead of waiting for the next quarterly audit.