CRA Readiness Report 2026
What our audit pipeline finds when it measures WordPress plugins against the four readiness signals behind the EU Cyber Resilience Act's 11 September 2026 vulnerability reporting deadline. Aggregate data only — no individual plugin is named.
Based on 1,545 completed plugin audits in our findings log.
No vulnerability disclosure file
No SECURITY.md anywhere in the plugin archive — the first thing the CRA's vulnerability handling requirements expect.
No published security contact
No security@ address, security.txt, or researcher contact route — meaning no way to receive the reports Article 14 creates a 24-hour duty around.
Changelogs don't tag security releases
Security fixes bundled silently into routine updates — the exact practice the CRA's update obligations target.
Ship known-vulnerable dependencies
At least one Composer or npm dependency with a published OSV advisory — unanswerable inside a 24-hour window without an SBOM.
What this means
From 11 September 2026, Article 14 of the CRA requires manufacturers of commercial software on the EU market — including monetised WordPress plugins — to report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware of them. That obligation presupposes something most plugins don't have: a channel through which researchers can tell you you're being exploited, and a process for acting on it.
The four signals above are the mechanical prerequisites. None of them is expensive or difficult — a SECURITY.md and a monitored inbox is an afternoon's work — but as the data shows, most of the ecosystem hasn't done it.
Read the plain-English guide to what 11 September actually requires — including drop-in SECURITY.md and security.txt templates.
Methodology
Figures are computed from WP HealthKit's findings log — the top 20 findings per completed audit — using deterministic static-analysis scanners. Every audit runs the same scanner roster; these four checks come from the CRA scanner and the Composer/npm dependency scanners (cross-referenced against OSV.dev).
Percentages are per-audit, not per-plugin: a plugin audited twice counts twice. Findings are static-analysis signals, not proof of exploitability, and a missing SECURITY.md in an uploaded ZIP can occasionally reflect packaging rather than intent. We publish aggregates only — we never name individual plugins or authors in this report.
This page is refreshed hourly. Historical snapshots are not retained; the numbers move as the ecosystem fixes things — which is the point.
Where does your plugin sit in this data?
Run a free audit — the CRA checks take about a minute, and the report doubles as your risk assessment artefact.
Get CRA countdown emails
Deadline reminders, VDP setup, and the final compliance checklist.