The Cyber Resilience Act for WordPress plugin and theme authors
You publish a WordPress plugin or theme. Since 11 September 2026 the EU Cyber Resilience Act asks some of you to report actively exploited vulnerabilities within 24 hours. Here is how to know whether that is you, what the platforms already expect, and what to put in place this week.
Are you a "manufacturer"?
The regulation applies to any product with digital elements made available on the EU market in the course of a commercial activity (Regulation (EU) 2024/2847, Article 2(1) and Article 3(1)). A plugin is software. The only real question is the commercial activity.
The recitals give the test. Free and open-source software that is not monetised by its manufacturer is outside the regulation (recital 18). Monetised means, in practice: you charge a price, you sell a pro version or add-ons, you sell paid support, you accept donations that go beyond covering your costs, or you process personal data beyond what security requires (recitals 18 and 19).
- Premium plugin, sold on your site, on CodeCanyon, or through Freemius: you are a manufacturer. Envato tells its authors exactly that in its help centre.
- Freemium, free on WordPress.org with a pro upgrade: the free version is part of a commercial activity. Manufacturer.
- Free plugin, no pro version, no paid support, no company behind it: outside the regulation. Keep it that way if you want to stay outside.
- Free plugin maintained by a company (an agency's utility plugin, a hosting company's helper): the company's activity is commercial. Manufacturer, or open-source steward if the company only supports the project (Article 24).
Agencies that install third-party plugins for clients are users, not distributors. An agency that rebrands a plugin and sells it under its own name becomes its manufacturer (Article 22).
What applies now, what applies in 2027
| From | Obligation | Article |
|---|---|---|
| 11 September 2026 | Report an actively exploited vulnerability in your plugin: early warning within 24 hours, notification within 72 hours, final report within 14 days, through the ENISA single reporting platform. Same clock for a severe incident affecting the plugin's security. | Article 14 |
| 11 December 2027 | Everything else: secure-by-design requirements, vulnerability handling (SBOM, coordinated disclosure policy, security updates for the support period), technical documentation, EU declaration of conformity, CE marking, and the fines. | Articles 13, 64, 71; Annexes I, V, VII |
"Actively exploited" means someone is using the flaw against real sites, not that a scanner found it. When a WordPress security vendor publishes "exploitation in the wild" for your plugin, your 24 hours have started, or started earlier if you knew before they did.
Three recent cases show the shape of it. Everest Forms Pro (CVE-2026-3300, premium): patch on 18 March 2026, exploitation from 13 April. Elementor Pro (CVE-2026-32475): patch and confirmed exploitation on the same day, 19 August 2026. All-in-One WP Migration (CVE-2026-19949): reported 14 August, patched 20 August, disclosed 3 September, with 35 % of sites up to date at disclosure. Under Article 14, each of those manufacturers had an early warning to file within 24 hours of learning about exploitation.
What the platforms already ask
- WordPress.org holds you responsible for your plugin's content and actions (Plugin Directory guideline 2) and closes a plugin until a reported vulnerability is fixed. It does not publish a fixing deadline. Reports go to [email protected].
- CodeCanyon requires input validation, nonces, capability checks and prepared statements, and its support policy requires security fixes for major vulnerabilities during the support period.
- Neither platform files your Article 14 report for you. Patchstack offers a managed disclosure and reporting service for maintainers; Envato says it will link to the ENISA platform. The legal obligation stays yours.
Which class is your plugin?
Most plugins are "default" products: self-assessment, no notified body. Annex III lists "important" products where a third-party assessment can be required unless you apply a harmonised standard. Two families matter for WordPress: password managers, and "software that searches for, removes or quarantines malicious software". A security plugin with a malware scanner, or a plugin that stores and fills credentials, should read Annex III, Class I, before assuming self-assessment.
This week, in order
- Decide your status with the free scope test. Eight questions, a written result with the article references. Free version with no commercial activity: stop here, and write that decision down.
- Publish a security contact: a
security.txton your site and a one-paragraph coordinated vulnerability disclosure policy. Researchers look for it before they publish. Annex I, Part II, point 5 will require it in 2027; today it is what makes a researcher write to you instead of to a blog. - Write the 24 h / 72 h procedure on one page: who watches the security vendors' feeds, who decides "exploited or not", who files on the ENISA platform, where the log is. At 2 a.m. nobody reads a policy manual.
- Generate your SBOM. For a PHP plugin that means
composer.lock; for the build tooling,package-lock.json. The free scanner reads both and flags anything on the CISA KEV list. - Fix the support period question. Article 13(8) asks for at least five years unless the product is expected to be used for less. Write the date in your plugin's readme and in your pricing page.
The kit generates the thirteen documents behind these steps from one form, in English or French: CVD policy, security.txt, the reporting procedure with the ENISA-style templates, the support statement, the Annex I risk assessment and the Annex VII skeleton. Preview three of them in full before paying.
Where to ask
The WordPress.org forums forbid promotion, so ask questions there, do not answer with a product. The Making WordPress Slack has no CRA channel yet. The WordCamp talks by Oliver Sild (WordCamp Europe 2025) and Simon Kraft (WordCamp Portugal 2026) are the two community references. The Eclipse ORC working group maintains a public CRA FAQ that covers the open-source questions.
Sources: Regulation (EU) 2024/2847 as published in the Official Journal; WordPress.org Plugin Directory guidelines (11 March 2026); Envato Author Help Center on CRA reporting (2026); Patchstack, State of WordPress Security 2026 (25 February 2026); BleepingComputer on CVE-2026-3300 (6 June 2026) and CVE-2026-32475 (3 September 2026); TechTimes on CVE-2026-19949 (3 September 2026). Not legal advice.