From September 2026, commercial WordPress plugins available in the EU are expected to have a documented Vulnerability Disclosure Programme: a published route for security researchers to report problems, with defined timelines for responding. It comes out of the Cyber Resilience Act, which starts applying its requirements this year.
If you sell a plugin this applies to you. If you give one away the obligations are lighter, but the reasoning holds either way, and the work involved is smaller than the regulation makes it sound.
What the policy actually is
At minimum, a page on your site answering four questions. Where does somebody send a security report, and is it a dedicated monitored address rather than your general support form? How quickly will you acknowledge it, where a working day or two is a reasonable commitment? How quickly will you aim to fix it and how will you keep the reporter informed? And what do you ask in return, which is normally time to patch before anything goes public?
That is most of it. The regulation wants a process to exist and be findable. It is not asking you to staff a security team.
The reason to do it even if the law did not exist
Researchers find things in plugins constantly. What determines how it goes is not whether they find something, it is what happens next.
With a clear route you get a private report and time to patch. Without one you get one of two worse outcomes. Either the researcher gives up, and the vulnerability sits there undiscovered by you and discovered by somebody less friendly. Or they escalate publicly, because they could not find anybody to tell.
Given the window between disclosure and automated exploitation is now measured in hours, the value of hearing about a problem before it is public is hard to overstate.
The supply chain half
The broader push behind the regulation is supply chain integrity: knowing what is in the software you ship and being able to say so. For a plugin author that is a few unglamorous habits. Know your dependencies and watch their advisories, particularly anything you bundle. Secure the release pipeline, because a compromised build step pushes malicious code to every user who updates and is the highest-leverage attack available against any plugin. Put 2FA on every account that can publish a release, without exceptions for the founder.
Then test it
Write the page. One address, four paragraphs, linked from your readme and your site footer. Half an afternoon.
Then send a test report to that address yourself in a month and see whether anybody answers. An unmonitored security address is worse than having none at all, because it converts a researcher who was trying to help into one who quite reasonably concludes you do not care.
