ColoredCow / ColoredCow/performance-adapter-wp

[Wishlist] Vulnerable plugin detection alert

Open
#41 0 comments 0 reactions 1 assignee Claimed by @Ajay-Singh-Adhikari View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.