WordPress Vulnerability Disclosure: A Responsible Process

Finding a security vulnerability in a WordPress plugin puts you at a crossroads. You can immediately publish the details (putting users at risk), quietly report it and hope the developer listens (leaving it unfixed), or follow responsible disclosure practices that give developers time to fix while eventually protecting the broader community. The third option is the only ethical choice.

WordPress vulnerability disclosure and responsible practices have evolved significantly as the WordPress ecosystem matured. What was once informal now involves coordinated timelines, CVE assignments, security researchers, and established processes. Understanding these practices protects both users and your reputation as a security researcher.

This guide covers the responsible disclosure process, coordinating with the WordPress Security Team, CVE reporting, bug bounty programs, and disclosure timelines. WP HealthKit helps security researchers verify whether a vulnerability truly exists and assists in documentation.

Table of Contents

1. Understanding Responsible Disclosure
2. Preparing Your Vulnerability Report
3. Contacting Plugin Developers
4. Working with the WordPress Security Team
5. CVE Assignment and Management
6. Bug Bounty Program Coordination
7. Disclosure Timelines and Embargoes
8. Frequently Asked Questions

Understanding Responsible Disclosure

Responsible disclosure (also called "coordinated disclosure") is the practice of reporting security vulnerabilities privately to affected vendors before public disclosure, giving them time to develop and release fixes before attackers can exploit the flaw.

This contrasts with:

• Full Disclosure: Publishing vulnerability details immediately without vendor coordination
• Opportunistic Disclosure: Finding a vulnerability and exploiting it yourself
• Vulnerability Hoarding: Keeping the vulnerability secret indefinitely

The responsible disclosure model balances three competing interests:

1. Vendor interests: Time to develop and test a fix
2. User interests: Getting patched quickly while vulnerabilities remain unknown to attackers
3. Security researcher interests: Getting credit and ensuring the vulnerability is fixed

WordPress vulnerability disclosure follows a well-established process because the platform has mature security infrastructure and experienced security researchers.

The timeline for responsible disclosure typically follows this pattern:

Day 0: Researcher discovers vulnerability
Day 1: Researcher reports to vendor/security team
Days 2-89: Private discussion, fix development and testing
Day 90: If not patched, public disclosure becomes appropriate

The key principle: vendors get a reasonable window (60-90 days is standard) to fix vulnerabilities before public disclosure. This window balances urgency (get fixes out quickly) with reality (complex fixes take time to develop and test).

The responsible disclosure timeline exists because vulnerability patching isn't instantaneous. A developer must receive the report, understand the vulnerability, develop a fix, test it thoroughly to ensure it actually fixes the problem without introducing new vulnerabilities, and release the patched version. For popular plugins with millions of installations, this process is complex. Vendors must also consider backwards compatibility—the fix might require abandoning support for older WordPress or PHP versions, forcing difficult decisions about who gets the security fix.

For researchers, the responsible disclosure process can feel frustratingly slow. You've discovered a serious vulnerability and you want the world to know immediately and be protected. However, this impatience creates real risk. Premature disclosure before fixes are available gives attackers a roadmap to exploit millions of sites before patches are deployed. The time investment in the disclosure process protects millions of users.

The emotional challenge of responsible disclosure shouldn't be underestimated. Researchers invest significant effort discovering vulnerabilities and want to be recognized for it. The disclosure process involves withholding credit until the fix is released, sometimes for months. Many vulnerability databases and CVE platforms handle this by issuing CVE numbers during the embargo period, giving researchers documentation of their discovery even though the details remain confidential.

Preparing Your Vulnerability Report

A well-prepared vulnerability report dramatically increases the likelihood that a developer will fix the issue quickly and accurately.

Essential information in a vulnerability report:

1. Clear title: "SQL Injection in Import CSV Parser" (not "Your plugin is broken")
2. Detailed description: Explain the vulnerability clearly
3. Steps to reproduce: Exact steps to demonstrate the flaw
4. Impact assessment: What can an attacker do with this vulnerability?
5. Proof of concept: Demonstration code (sometimes)
6. Affected versions: Which versions are vulnerable?
7. Your contact information: How can the developer reach you?

Here's a template for a professional vulnerability report:

VULNERABILITY REPORT
====================

Title: SQL Injection in Import Module

Severity: HIGH (CVSS 8.6)

Description:
The import module of My Plugin uses an unsafe SQL query 
construction in the file includes/import-processor.php, 
line 234. User-supplied data from CSV files is interpolated 
directly into SQL queries without proper parameterization.

Affected Versions:
- 1.8.0
- 1.8.1
- 1.9.0
- 1.9.1
- 1.9.2
- Versions 1.0.0 to 1.7.9 appear unaffected (different code path)

Steps to Reproduce:
1. Install My Plugin 1.9.2
2. Navigate to Import > CSV Upload
3. Upload the attached file: malicious-import.csv
4. Observe that custom SQL is executed from the CSV data

Impact:
An authenticated administrator could execute arbitrary SQL 
queries, leading to:
- Unauthorized data access
- Data modification or deletion  
- Potential code execution via SQL functions

Proof of Concept:
[Provided in attached file - request direct contact for code]

Timeline:
- 2026-03-18: Initial report sent
- [Developer response expected within 7 days]
- [Target patch date: 2026-05-15, 60-day window]

Reporter Information:
Name: Jane Security Researcher
Email: [email protected]
PGP Key: [fingerprint if available]

CVSS Scoring (Common Vulnerability Scoring System) helps developers understand severity:

• Critical (9.0-10.0): Immediate patch required
• High (7.0-8.9): Urgent fix needed
• Medium (4.0-6.9): Important but not immediately critical
• Low (0.1-3.9): Consider fixing in next release

For a WordPress vulnerability, assess CVSS based on:

• Attack Vector: Can it be exploited remotely? (Network = higher)
• Attack Complexity: How difficult is the exploit?
• Privileges Required: Does attacker need admin/editor access?
• Impact on Confidentiality: Can attackers read sensitive data?
• Impact on Integrity: Can attackers modify data?
• Impact on Availability: Can attackers disrupt the service?

// CVSS Calculation Example
// SQL Injection in authenticated admin form:
// - Attack Vector: Network (1.0)
// - Attack Complexity: Low (0.77)
// - Privileges Required: High (0.27) - requires admin capability
// - User Interaction: None (1.0)
// - Confidentiality Impact: High (0.56)
// - Integrity Impact: High (0.56)
// - Availability Impact: Low (0.22)
// Result: CVSS 6.5 Medium severity

// SQL Injection in public-facing form (not authenticated):
// - Attack Vector: Network (1.0)
// - Attack Complexity: Low (0.77)
// - Privileges Required: None (1.0)
// - User Interaction: None (1.0)
// - Confidentiality Impact: High (0.56)
// - Integrity Impact: High (0.56)
// - Availability Impact: Low (0.22)
// Result: CVSS 8.6 High severity

Contacting Plugin Developers

Finding the right contact for vulnerability reports is the first step.

For WordPress.org plugins:

Check the plugin's security.txt file:

https://plugin-domain.com/.well-known/security.txt

This file should specify:

Contact: [email protected]
Expires: 2026-12-31
Preferred-Languages: en

If no security.txt exists, use these approaches in order:

1. Plugin readme.txt: Look for "Support" or "Author" email
2. Plugin website: Check "Contact" or "Security" page
3. Author profile on WordPress.org: Listed contact information
4. GitHub repository: Issues or security policy (if public)
5. Company website: General security contact if a company maintains it

Email guidelines for vulnerability reports:

Subject: [SECURITY] Vulnerability in Your Plugin
(Includes the word SECURITY so reports are prioritized)

To: [email protected]
CC: security-researcher-at-your-domain (for record-keeping)

Body:
- Start with a clear, non-alarming intro
- Brief description (1 paragraph)
- Request: "I'm providing this report under responsible 
  disclosure practices. Please respond within 7 days with 
  your patch timeline."
- Offer to help: "I'm happy to help test the fix or provide 
  additional information."
- Include timeline: "If I don't hear back within 60 days, 
  I'll be disclosing this publicly."

Never:

• Threaten to publish the vulnerability if not fixed immediately
• Demand compensation or payment
• Disclose the vulnerability on social media before contacting the developer
• Give unreasonably short timelines (less than 30 days)
• Use unprofessional language or tone

Always:

• Be respectful and professional
• Assume good faith (developers usually want to fix issues)
• Offer to help verify the fix
• Give realistic timelines
• Document all communication

Working with the WordPress Security Team

The WordPress Security Team actively works with security researchers to coordinate disclosure of WordPress core vulnerabilities. Similar structures exist for plugin ecosystems.

When to contact the WordPress Security Team:

For vulnerabilities affecting:

• WordPress core files
• WordPress-wide issues affecting many plugins
• Critical vulnerabilities in popular plugins
• Supply chain risks

Contact: [email protected]

The WordPress Security Team will:

1. Acknowledge receipt of your report
2. Investigate the vulnerability
3. Coordinate with affected parties (plugin developers, hosting providers)
4. Develop fixes
5. Coordinate a security release
6. Embargo the fix until released

Your responsibilities as a researcher:

• Don't disclose details until the team gives permission
• Respect embargo dates strictly
• Provide clear, reproducible reports
• Update the team if you learn of active exploitation
• Support the team's disclosure timeline

The WordPress core security process includes:

Day 1: Report received and acknowledged
Days 2-7: Initial investigation
Day 8: Developer contacted if external fix needed
Days 9-60: Fix development and testing
Day 61+: Coordinated release (usually a Wednesday)
Day 61+: Public disclosure in security advisory

CVE Assignment and Management

A CVE (Common Vulnerabilities and Exposures) identifier is a unique reference for a specific vulnerability. CVE numbers look like: CVE-2026-1234

Who assigns CVEs?

CVEs are assigned by "CVE Numbering Authorities" (CNAs). For WordPress:

• WordPress security team
• Plugins team
• Third-party security researchers
• Security vendors like NVD

When do you need a CVE?

If your vulnerability affects:

• Multiple versions of widely-used software
• Is of high severity
• Will be publicly discussed
• Affects production systems

For WordPress vulnerability disclosure, you usually don't assign your own CVE—the WordPress Security Team does it as part of their process.

How to reference CVEs in reports:

Vulnerability: SQL Injection in Import Module
CVE: CVE-2026-1234
CVSS Score: 8.6 High
Details: https://nvd.nist.gov/vuln/detail/CVE-2026-1234

If a plugin affects many WordPress installations, request a CVE by:

1. Going to https://cveform.mitre.org/
2. Providing vulnerability details
3. Requesting a CVE number
4. Waiting 1-2 weeks for assignment

Include the CVE in all future communications about the vulnerability.

Bug Bounty Program Coordination

Many major WordPress projects and plugin developers have bug bounty programs offering rewards for security researchers.

Popular WordPress bug bounty platforms:

• HackerOne: Hosts bounties for WordPress projects
• Bugcrowd: Enterprise bug bounty platform
• Plugin-specific programs: Individual plugins offer rewards

Benefits of using a bug bounty program:

• Clear disclosure guidelines
• Compensation for your research time
• Professional vulnerability management
• Mediation if disputes arise
• Legal protection (safe harbor)

When participating in a bug bounty:

1. Read the program's scope carefully
2. Report through the program (not directly to developers)
3. Follow the program's disclosure timeline
4. Document all communications
5. Never exceed the program's scope
6. Report only security issues (not support requests or feature requests)

Example HackerOne report process:

1. Create HackerOne account and join WordPress program
2. Submit vulnerability report through HackerOne platform
3. HackerOne confirms receipt, assigns reporter
4. WordPress team investigates
5. Report may be marked as "informative" or "duplicate"
6. If vulnerability confirmed, triage determines severity
7. Bounty is awarded (typically $30-$1000 depending on severity)
8. Fix is developed and tested
9. Fix is released
10. Vulnerability is disclosed in security advisory

Check if a bug bounty exists before reporting:

// Common bug bounty program locations
https://example.com/security    // Plugin security page
https://example.com/.well-known/security.txt
https://hackerone.com/wordpress  // HackerOne programs
https://bugcrowd.com/programs    // Bugcrowd programs

Use WP HealthKit to identify security vulnerabilities for responsible disclosure.

Disclosure Timelines and Embargoes

An embargo is a confidentiality agreement that specifies when you can publicly discuss a vulnerability. Embargoes are critical to responsible disclosure.

Standard embargo timeline:

Day 0: Vulnerability discovered and reported
Day 0-60: Embargo period (no public discussion)
Day 60: If no fix released, researcher can disclose publicly
Day N (usually before day 60): Developer releases fix
Day N+1 to N+7: Embargo lifted, public disclosure can occur

The typical 60-day window gives:

• Week 1: Developer to acknowledge and understand the issue
• Weeks 2-6: Fix development and testing
• Weeks 7-8: Buffer for delays or complications
• Week 9: Public disclosure

When embargo timelines differ:

• Critical vulnerabilities: May reduce to 30 days (high impact, high risk of discovery)
• Already-public vulnerabilities: Embargo period is zero
• Publicly-announced issues: Embargo begins when vulnerability is publicly known
• Active exploitation: May warrant immediate disclosure

Your responsibilities during embargo:

• ✅ Can: Communicate with developer about the fix
• ✅ Can: Help verify the fix works
• ✅ Can: Coordinate with other security researchers on the same issue
• ❌ Cannot: Discuss on social media or public forums
• ❌ Cannot: Include details in bug tracker issues (unless private)
• ❌ Cannot: Tell anyone not involved in fixing it

Breaking embargo:

Only break embargo if:

1. Active exploitation is confirmed: Attackers are already using it
2. Developer is unresponsive: After 60+ days, no fix in sight
3. Developer requests it: Sometimes developers want early disclosure
4. Someone else discloses it: Once public, embargo ends

If you break embargo, document your reasoning clearly.

Additional Resources

• Patchstack WordPress Security
• Wordfence Threat Intelligence

Frequently Asked Questions

What if the developer ignores my report?

Follow up after 7 days if you haven't heard back. If still no response after 14 days, escalate:

1. Try contacting through different channels (support form, social media)
2. Report to the WordPress security team
3. Contact the platform where the plugin is hosted
4. After 60-90 days with no response, you may disclose publicly

Should I disclose vulnerability details when the fix is released?

Yes, but in a structured way. Include:

• What was vulnerable
• Who is affected
• How severe it is
• Link to the fix
• Don't include exploit code until several days after release

What if I discover a vulnerability in WordPress core?

Report to [email protected] immediately. Follow their formal process. Never attempt to exploit WordPress core vulnerabilities for any reason.

Can I sell vulnerability information instead of disclosing responsibly?

Legally, yes. Ethically, no. Selling vulnerabilities on dark markets means users never get protected. Responsible disclosure protects the broader WordPress community.

What's the difference between a vulnerability researcher and a security threat actor?

The difference is disclosure ethics. Both can find vulnerabilities, but researchers disclose responsibly while threat actors exploit them for profit or damage.

Should I use a pseudonym when reporting vulnerabilities?

You can, though providing real contact information helps developers verify your identity and follow up with questions. Many researchers use professional pseudonyms that are associated with their reputation over time.

What if the developer releases a fix but doesn't credit me?

Politely request credit in the changelog or security advisory. Most developers are happy to acknowledge security researchers who report vulnerabilities. If they refuse, consider whether to participate in future reports.

Can I look for vulnerabilities in plugins I don't use?

Yes. Security research on public code is ethical and legal. Just follow responsible disclosure practices when reporting what you find.

Conclusion

WordPress vulnerability disclosure is a critical part of the security ecosystem. By following responsible disclosure practices—reporting privately, providing clear information, respecting embargo timelines, and coordinating with developers and security teams—you protect users while maintaining professional relationships with developers.

The responsible disclosure model has proven effective because it aligns incentives: researchers get recognition, developers get time to fix issues without panic, and users get protected before attackers exploit vulnerabilities.

Every security researcher participating in responsible disclosure strengthens WordPress security for everyone. Your ethical approach to vulnerability management sets the standard for the ecosystem.

Want to participate in WordPress security research? Start by using WP HealthKit to identify potential vulnerabilities, then follow these responsible disclosure practices to report them.

Begin your security research with WP HealthKit audits today.

For more on WordPress security, check out our guides on WordPress supply chain attack defenses and explore the WP HealthKit security leaderboard to see which plugins are leading security standards.