Vulnerability Disclosure Program: Complete 2026 Guide

A vulnerability disclosure program is a documented process that lets security researchers report bugs in your WordPress plugin or theme safely, with defined response timelines. Under the EU Cyber Resilience Act, every commercial WordPress plugin sold to European users must have one in place. Vulnerability reporting obligations take effect on September 11, 2026, with full compliance required by December 11, 2027, under Regulation (EU) 2024/2847.

What Is a Vulnerability Disclosure Program?

A vulnerability disclosure program (VDP) is a published, formal channel that tells security researchers exactly how to report a security flaw in your software, what response time to expect, and what legal protection they get for reporting in good faith. For a WordPress plugin, that usually means a security.txt file, a dedicated security email address, a written policy page, and a triage process behind it.

Without a VDP, researchers who find a flaw in your plugin have no clear way to tell you before they post it publicly, sell it, or exploit it themselves. A VDP replaces that guesswork with a repeatable process — which is exactly why regulators now treat it as a baseline security control rather than a nice-to-have.

The concept isn’t new. Large software vendors like Microsoft and Google have run formal vulnerability disclosure programs for over a decade, usually through a dedicated security page and a coordinated disclosure timeline that gives the vendor a fixed window to patch before details go public. What’s new in 2026 is that this same discipline is now a legal floor for WordPress plugin businesses, not just enterprise software vendors, because plugins sit deep inside millions of production websites and a single unpatched flaw can cascade across an entire hosting ecosystem.

Why Does the EU Cyber Resilience Act Require a Vulnerability Disclosure Program for WordPress Plugins?

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is a horizontal cybersecurity law covering almost any product with digital elements sold into the EU market, including commercial WordPress plugins, themes, and software built on top of WordPress. The regulation entered into force in December 2024, but its vulnerability-handling obligations only become enforceable on September 11, 2026.

Lawmakers added the requirement after years of WordPress plugin vulnerabilities being exploited at scale before vendors even knew they existed. A vulnerability disclosure program forces vendors to have a working intake process, rather than relying on luck or a researcher’s goodwill to hear about a flaw in time.

The CRA isn’t the EU’s only cybersecurity law touching WordPress businesses — GDPR already governs how you handle personal data. The two overlap but solve different problems: GDPR is about data protection and consent, while the CRA is about the security of the software product itself. A plugin can be fully GDPR-compliant on privacy grounds and still fail the CRA if it ships without a documented vulnerability handling process. Treat them as separate checklists, not one combined task.

Which WordPress Plugins and Themes Fall Under the Cyber Resilience Act?

The CRA applies to manufacturers, importers, and distributors of products with digital elements placed on the EU market. In practice, that covers any commercial WordPress plugin or theme — sold directly, bundled into a SaaS product, or distributed through a marketplace — as long as it reaches users inside the EU. It does not matter where the developer is based; a US-based plugin shop selling to European customers is still in scope.

Purely free, non-commercial plugins maintained by volunteers sit in a greyer area, but plugins that are free to install and monetized through upsells, add-ons, or a paid Pro version are treated as commercial products for CRA purposes. If you’re unsure whether your plugin qualifies, Patchstack’s Cyber Resilience Act checklist walks through the scoping questions in detail.

Distributors and resellers are covered too, not just the original developer. If you run a WordPress agency that bundles a set of premium plugins into a package you sell to clients, or a hosting company that pre-installs commercial plugins on every account, you can carry distributor obligations under the CRA even though you didn’t write the code. In practice, that means checking that every plugin in your stack has its own vulnerability disclosure program before you make it part of your offering — because a gap in someone else’s plugin can still become your compliance problem.

What Are the Key Compliance Deadlines for 2026 and 2027?

Two dates matter most for WordPress plugin vendors:

• September 11, 2026 — vulnerability handling and reporting obligations become enforceable. From this date, vendors must have a working process to detect vulnerabilities and report actively exploited ones to ENISA within 24 hours of becoming aware.
• December 11, 2027 — the full set of CRA obligations applies, including risk assessments, a Software Bill of Materials (SBOM), technical documentation, and an EU Declaration of Conformity for qualifying products.

Building your vulnerability disclosure program now, well ahead of the September 2026 deadline, gives you time to test the process before regulators or a real incident do it for you.

What Must a Compliant Vulnerability Disclosure Program Include?

A vulnerability disclosure program that satisfies the CRA’s intent needs more than a contact email buried in your README. At minimum, it should include:

• A public, written disclosure policy explaining how to report a bug and what happens next
• A dedicated reporting channel — a security@ email address or a security.txt file at your domain root
• Defined response timelines (acknowledgment, triage, and patch targets by severity)
• A safe-harbor clause protecting good-faith researchers from legal threats
• An internal process to report actively exploited flaws to ENISA within 24 hours
• A notification plan for telling affected users “without undue delay,” as the regulation requires

How Do You Set Up a Vulnerability Disclosure Program for Your WordPress Plugin?

You can build a working vulnerability disclosure program without hiring a compliance consultant. Follow these steps:

1. Write a short disclosure policy page: what’s in scope, how to report, and your target response time.
2. Publish a security.txt file at /.well-known/security.txt pointing to your policy and contact address.
3. Add the security contact to your plugin’s readme.txt so it’s visible from the WordPress.org plugin directory listing.
4. Set up an internal triage workflow — who reviews a report, how severity gets scored, and who signs off on a patch.
5. Use a vulnerability monitoring service such as Patchstack or WPScan so you learn about issues in your dependencies, not just your own code.
6. Document your 24-hour ENISA reporting process for actively exploited flaws before you need it, not after.

Each of these steps takes longer to explain than to actually do. A disclosure policy page can be a single screen: what counts as in scope, how to send a report, and a promise to acknowledge it within a set number of business days. The security.txt file is a plain-text standard — a handful of lines pointing to your contact and policy URL — that automated scanners and researchers already check for by default. The part teams underestimate is the triage workflow: deciding in advance who owns incoming reports so a message doesn’t sit unread in a shared inbox for two weeks.

What Is a Software Bill of Materials, and Do You Need One?

A Software Bill of Materials (SBOM) is a formal inventory of every component, library, and dependency your plugin ships with — similar to an ingredients list on packaged food. The CRA requires an SBOM as part of the technical documentation due by December 11, 2027, so that both regulators and your own team can quickly answer “are we affected?” when a vulnerability is disclosed in a widely used library.

For most WordPress plugins, an SBOM isn’t as intimidating as it sounds. If your plugin is built mostly on WordPress core APIs with a handful of Composer or npm dependencies, generating an SBOM is largely a matter of exporting your composer.lock and package-lock.json files into a standard format like CycloneDX or SPDX. The September 2026 deadline doesn’t require an SBOM yet — but building one now makes the December 2027 deadline far less stressful.

What Happens If You Don’t Comply?

Non-compliance with the CRA can mean fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, plus the possibility of your product being withdrawn from the EU market entirely. Beyond the legal risk, skipping a vulnerability disclosure program leaves you exposed the way several major WordPress plugins already have been — see our coverage of the Elementor Pro vulnerability and the WooCommerce Social Login vulnerability for what happens when a flaw reaches attackers before it reaches the vendor.

Vulnerability Disclosure Program vs Bug Bounty Program: What’s the Difference?

Both channels invite outside researchers to report flaws, but they differ in cost, obligation, and scale. Here’s how they compare for a typical WordPress plugin vendor:

Most solo WordPress developers and small plugin shops should start with a vulnerability disclosure program — it satisfies the CRA requirement at no direct cost — and add a bug bounty later if the plugin grows large enough to justify the budget.

What Tools Help WordPress Vendors Meet These Requirements?

You don’t have to build every piece of a vulnerability disclosure program from scratch. A handful of existing services cover the parts that are hardest to do manually:

• Patchstack runs a managed vulnerability disclosure and bug bounty layer specifically for WordPress plugins and themes, plus CRA-focused compliance guidance.
• WPScan maintains a public vulnerability database and a scanner that flags known issues in plugins and themes before attackers find them.
• Dependabot or Composer audit catches known vulnerabilities in your third-party PHP and JavaScript dependencies, feeding directly into your SBOM.
• A shared security inbox (even a simple Google Workspace alias) with two people on rotation prevents a report from going unanswered because one person was on vacation.

None of these tools remove the legal obligation to publish a policy and report exploited flaws to ENISA yourself — they simply make the detection and triage half of the job faster.

How Does This Affect WordPress Site Owners, Not Just Plugin Developers?

If you run a WordPress site rather than build plugins, the CRA still affects you indirectly. A vendor with a published vulnerability disclosure program is more likely to patch fast and tell you when something’s wrong — exactly what happened when WordPress core itself needed a fast-turnaround fix in the WordPress 7.0.4 security update. When you’re choosing between two plugins with similar features, a published VDP is a legitimate signal of how seriously the vendor takes security — and a plugin’s track record on disclosures, like the one behind the XSS2Shell vulnerability, is worth checking before you install it.

A practical habit for any site owner: before installing a new commercial plugin, search for “[plugin name] security policy” or check its readme.txt for a security contact. If you can’t find one, that’s a signal to ask the vendor directly or look for an alternative. It costs a few minutes and can save you from being the site that gets compromised because nobody had a way to report the flaw before attackers found it themselves.

Quick Compliance Checklist Before September 2026

If you build or distribute a commercial WordPress plugin or theme sold into the EU, use this as a pre-deadline sanity check rather than a full legal audit:

• Published disclosure policy page — live and linked from your site footer or plugin readme
• security.txt file deployed at your domain root
• Named owner for incoming security reports, with a backup in case that person is unavailable
• Written internal process for reporting actively exploited flaws to ENISA within 24 hours
• Draft user-notification template ready to send “without undue delay” if a patch is needed
• Dependency list started, even informally, as the seed of your eventual SBOM

None of these items require new engineering work — they require someone on your team to own the process end to end. Treat that ownership question as the actual deliverable, not the paperwork.

Frequently Asked Questions

Does the EU Cyber Resilience Act apply to free WordPress plugins?

Generally, the CRA targets commercial products. A plugin that’s entirely free with no paid tier, upsell, or commercial backing typically falls outside its scope, but a “freemium” plugin monetized through a Pro upgrade is treated as commercial and is covered.

What is ENISA and why does it matter for a vulnerability disclosure program?

ENISA is the EU Agency for Cybersecurity, the body designated to receive mandatory notifications of actively exploited vulnerabilities. Under the CRA, vendors must report an actively exploited flaw to ENISA within 24 hours of becoming aware of it.

Does WordPress.org already require a vulnerability disclosure program for plugins?

WordPress.org’s plugin guidelines expect a working security contact, but that’s not the same as a documented, CRA-grade vulnerability disclosure program with a published policy, defined response times, and a safe-harbor clause. Building the full program is still the plugin author’s responsibility.

What happens if a researcher reports a vulnerability and I don’t fix it?

Beyond the reputational damage of an unpatched, publicly known flaw, failing to act can trigger CRA enforcement — fines of up to €15 million or 2.5% of global turnover, and potential removal of the product from the EU market. Market surveillance authorities in EU member states are responsible for enforcement, and a pattern of ignored reports is exactly the kind of evidence that turns a single complaint into a formal investigation.

Do WordPress site owners need their own vulnerability disclosure program?

The CRA’s VDP requirement targets vendors — the developers and companies distributing plugins and themes — rather than individual site owners. Site owners benefit indirectly by favoring plugins from vendors who already publish one.

How much does it cost to set up a vulnerability disclosure program?

The core requirements — a policy page, a security.txt file, and a dedicated contact address — cost nothing but time to set up. Optional tools like Patchstack or WPScan add ongoing monitoring for a subscription fee, but they’re not required to meet the baseline CRA obligation. The real cost isn’t the setup; it’s the ongoing discipline of actually triaging every report that comes in, which is why assigning clear ownership matters more than any single tool you buy.

The September 11, 2026 deadline is close enough that WordPress plugin vendors should treat a vulnerability disclosure program as a build-it-now task, not a someday project. Publishing a clear policy, opening a real reporting channel, and documenting your response process protects your users, your business, and — under the Cyber Resilience Act — keeps your plugin legally sellable in the EU.