How to create a vulnerability disclosure policy for your WordPress plugin

What is a vulnerability disclosure policy

A vulnerability disclosure policy (VDP) is a public document that tells security researchers how to report security issues in your software. It answers three questions:

1. How do I contact you about a security issue?
2. What can I expect after I report it?
3. Will I get in legal trouble for looking at your code?

Without a VDP, researchers have no idea if you want to hear about bugs or if you will threaten them with lawyers. Many researchers will not report vulnerabilities to projects without a published policy. They will just walk away, and the bug stays unfixed until someone with worse intentions finds it.

The WordPress ecosystem has a mixed record on this. Patchstack runs a managed VDP programme for WordPress plugins, which helps. But Patchstack only covers plugins that register with them. If you are not in their programme and you do not have your own policy, researchers have nowhere to go.

What the CRA requires

Annex I, Part II of the CRA lists vulnerability handling as one of the core requirements. Manufacturers must:

• Document a coordinated vulnerability disclosure policy and make it publicly accessible
• Provide a contact address for reporting vulnerabilities
• Address and remediate vulnerabilities without delay, including by providing security updates
• Apply effective and regular testing and review of the product
• Once a security update is available, share information about fixed vulnerabilities, including a description and the CVE identifier where available

The regulation also links to the security.txt standard (RFC 9116) as the mechanism for making your contact information machine-readable. More on that below.

What to include in your VDP

A good VDP does not need to be long. One page is enough. Here are the sections, with example text for a WordPress plugin context.

Scope

Define what is covered. Name your plugin(s) and any associated services. Example: “This policy covers security vulnerabilities in MyPlugin version 2.0 and later, including the free and premium editions distributed through WordPress.org and our website.”

How to report

Provide a clear contact method. Email is standard. Include a PGP key if you have one. Example: “Report vulnerabilities by email to security@yourplugin.com. If possible, encrypt your report using our PGP key (available at [link]).”

Do not use a public GitHub issue for security reports. Vulnerability reports should go through a private channel. A dedicated email address is the simplest approach.

What to include in a report

Help researchers give you useful reports:

• Description of the vulnerability and its potential impact
• Steps to reproduce the issue
• Affected versions
• Any relevant screenshots, logs, or proof-of-concept code
• Their contact details for follow-up

Response commitments

Tell researchers what to expect and when. More on setting realistic timelines below.

Safe harbour statement

Promise you will not sue researchers who follow the policy. This is a big section. See below.

Disclosure timeline

State when you will publicly disclose the vulnerability after it is fixed. The standard in the WordPress community is 90 days. Patchstack uses a 90-day window. Google Project Zero uses 90 days. Match the community norm.

Connecting your VDP to security.txt

RFC 9116 defines a standard file format called security.txt that lives at /.well-known/security.txt on your website. It is a machine-readable way to publish your security contact information. The CRA references this standard.

Your security.txt should include:

• Contact: Your security email address
• Policy: URL to your full VDP document
• Expires: When this file should be considered stale (refresh annually)
• Preferred-Languages: Languages you can handle reports in (e.g. en)
• Encryption: URL to your PGP key, if available

For WordPress plugins, you have two places to publish security.txt: your product website (where the VDP lives) and the WordPress site where the plugin is installed. CRA Guard generates a security.txt and installs it to the WordPress site’s /.well-known/ directory with a single click.

Setting a response timeline

Be honest about what you can deliver. Here is a realistic timeline for a solo or small-team WordPress developer:

• Acknowledgement: within 72 hours. Confirm you received the report and are looking at it. This is not a fix. It is a reply.
• Triage and severity assessment: within 7 days. Classify the severity. Tell the researcher whether you consider it valid.
• Fix timeline: within 30 days for high/critical, 90 days for medium/low. Ship the patch. Let the researcher know.
• Public disclosure: within 90 days. Publish a security advisory after the fix is available.

Do not promise 24-hour acknowledgement if you check email once a day. Overpromising and underdelivering is worse than setting realistic expectations.

Note: the 24-hour ENISA reporting deadline is separate from your VDP timeline. The ENISA obligation applies to actively exploited vulnerabilities, not all vulnerability reports. Your VDP covers the researcher-facing process. The ENISA obligation covers the regulator-facing process.

The safe harbour clause

This is the most important part of your VDP from a researcher’s perspective. Security researchers need to know they will not face legal action for testing your plugin and reporting what they find.

A good safe harbour clause says:

• You consider security research conducted under this policy to be authorised
• You will not pursue legal action against researchers who follow the policy
• Researchers must act in good faith: no data destruction, no privacy violations, no disrupting services
• Researchers should not disclose the vulnerability publicly before you have had reasonable time to fix it

Without a safe harbour clause, many experienced researchers will not touch your plugin. The CISA (US Cybersecurity and Infrastructure Security Agency) VDP template includes a safe harbour clause. The Disclose.io framework provides standardised language. Either is a good starting point.

Where to publish your policy

Your VDP needs to be findable. Publish it in all of these locations:

1. Your product website. A dedicated page at something like yourplugin.com/security. This is the canonical location.
2. Your WordPress.org plugin page. Reference it in the FAQ section or description of your readme.txt.
3. Your GitHub/GitLab repository. Add a SECURITY.md file in the root of your repo. GitHub renders this specially.
4. Your security.txt file. The Policy: field links to the VDP.

How this works with Patchstack

Patchstack runs a managed VDP programme (mVDP) for WordPress plugins. If you register with Patchstack, they handle the researcher-facing process: receiving reports, triaging, coordinating fixes, and managing disclosure timelines.

Having your own VDP and being in the Patchstack programme are complementary, not mutually exclusive. Here is how they fit together:

• Patchstack handles coordinated disclosure. They are a well-known entry point for researchers in the WordPress ecosystem. Many researchers report through Patchstack by default.
• Your VDP covers direct reports. Not all researchers use Patchstack. Some will email you directly. Your VDP tells them how.
• The CRA requires your own policy. Being in the Patchstack programme does not replace the CRA obligation to document your own vulnerability handling process. Patchstack covers one reporting channel. The CRA requires a documented process that you own.

Read more about how CRA Guard handles the other four CRA obligations beyond vulnerability disclosure.

Mistakes that get you into trouble

• No policy at all. This is the most common situation in the WordPress ecosystem. If a researcher cannot find your security contact information, they either give up or disclose publicly. Neither is good for you.
• Threatening researchers. Some developers respond to vulnerability reports with legal threats or angry emails. This guarantees that the researcher (and their network) will never help you again.
• Ignoring reports. Receiving a report and not responding is almost as bad as not having a policy. If you commit to a 72-hour acknowledgement, do it.
• Fixing silently. Patching a vulnerability without disclosing it deprives other users and the security community of information they need. The CRA requires you to share information about fixed vulnerabilities.
• Using a public issue tracker for security reports. GitHub issues are public by default. Security reports should go through a private channel.

Generate your vulnerability disclosure policy

CRA Guard includes a VDP template in the free document generator. Fill in your contact details, response commitments, and scope, and it produces a formatted policy document ready to publish. It also generates a matching security.txt file and installs it to your WordPress site.

Get Early AccessView Pricing Plans

Sources

• Cyber Resilience Act full text (Annex I, Part II)
• CISA: Vulnerability Disclosure Policy template
• Patchstack: CRA checklist for open source vendors
• RFC 9116: security.txt standard

Disclaimer: This article is for informational purposes and does not constitute legal advice. Vulnerability disclosure obligations described here are based on Regulation (EU) 2024/2847 Annex I, Part II. Consult qualified legal counsel for advice specific to your situation.