ColoredCow / ColoredCow/performance-adapter-wp
[Wishlist] Vulnerable plugin detection alert
- Dominant language
- PHP
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
## Status
Wishlist — not scoped for the current alerting milestone, not yet approved by Kuldeep. Raised here so the idea isn't lost, not because it's on the near-term roadmap.
## Context
#35 already lists "Plugin vulnerability detected" as a proposed alert type. This issue splits it out on its own because it needs a new data source and collector, not just a threshold on data we already gather — different shape of work than the other alerts in #34/#35.
## What this would need
- A source of known plugin vulnerabilities — e.g. the WordPress.org vulnerability API (public, no auth required), or a third-party feed like WPScan/Patchstack if more coverage is needed.
- A new collector step that checks each active plugin + version against that source on the daily cron run.
- No BigQuery push — this is alert-only. There's no historical value in tracking "had vulnerable plugin: true" over time; the alert fires, the plugin gets updated, the alert clears.
## Proposed alert payload
- Site URL
- Plugin name(s) affected
- CVE ID(s) and severity, if available
- Affected version and fixed version, if known
## Open questions
- Which vulnerability source to use — WordPress.org's API alone, or supplement with a paid feed for better coverage?
- Severity floor — alert on every CVE, or only medium/high+?
- Does this need Kuldeep's sign-off before any implementation work starts, given it introduces a new external dependency?
## Related
- #35 — alert type definitions (this was originally listed there)
- #34 — external notification delivery
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.