To report a suspected vulnerability in self-hosted WordPress Core, submit it privately through the WordPress HackerOne program. Show a clear security impact and provide reproducible steps; do not publish the details while a fix is pending. First identify the affected product, since WordPress.com, Automattic-maintained products, and plugins may use different reporting routes. A bounty is possible, not guaranteed.
What counts as a WordPress security vulnerability?
WordPress Core’s guidance centers on whether a bug could let an attacker access a site or data they should not be able to access. A report should explain how the attacker gets in and what unauthorized impact follows. A site being compromised is not, by itself, proof of a WordPress vulnerability; the report must connect the compromise to a code flaw. Likewise, losing a password or access is not a security issue unless a WordPress code bug caused it. The security channel is not a general support desk. See WordPress Core’s vulnerability-reporting guidance.
WordPress’s September 1, 2026 program update emphasizes clear, significant security impact. Findings exploitable without authentication or by a low-privilege account, such as a Subscriber, are especially relevant. Eligibility language differs by asset: for assets other than Core and Gutenberg, administrator-only prerequisites generally make a report ineligible unless there is high-severity escalation and security impact. An action merely being performed by one authenticated role instead of another is generally not enough on its own. Do not apply that non-Core/Gutenberg rule to those projects without checking their guidance. Read the September 2026 disclosure-program update.
Where should you report the issue?
Choose the channel according to the affected product and its owner. WordPress’s official guidance identifies these routes:
#1 Best Overall
- Self-hosted WordPress Core: Submit through the WordPress Core security policy’s HackerOne route. Do not post a suspected vulnerability publicly on support forums or Core Trac—even if it affects trunk, beta, or release-candidate code, which may be running on production sites.
- WordPress.com or an Automattic-maintained product: The Core handbook directs reports to Automattic’s HackerOne program.
- A WordPress plugin: Follow the separate plugin-security reporting instructions referenced by the Core handbook. Do not assume that a plugin issue belongs in the Core program.
- Another WordPress project or infrastructure: Check the project owner’s security instructions and the live WordPress HackerOne policy. The repository policy describes broad coverage of Core and related projects and infrastructure, but the covered-asset list is maintained on HackerOne.
The Core repository policy’s supported-branch table can change. Its current display lists branches through 7.1.x and marks versions before 4.7 unsupported, but that does not establish identical bounty eligibility for every listed branch. Verify both support status and program scope in the current repository policy and live program terms before relying on a version-specific assumption.
How to prepare a useful vulnerability report
A strong submission makes it possible for the security team to understand and reproduce the problem without exposing real users to harm. HackerOne’s general guidelines call for clear, concise reproduction steps or a working proof of concept, and caution against including third-party personally identifiable information. WordPress expects a security issue, not a general product complaint.
- Identify the affected asset. Name the product or component and the version or versions you tested. Be precise about whether it is Core, Gutenberg, WordPress.com, a plugin, or another project.
- State the attacker’s starting point. Describe whether the attacker needs no account, a particular role, or some other prerequisite, and identify any relevant conditions.
- Give reproducible steps. Explain the setup and actions needed to trigger the issue, or include a working proof of concept that avoids unnecessary risk.
- Explain the security impact. State what unauthorized access, disclosure, modification, or disruption the flaw enables, and connect that outcome to the steps.
- Protect other people’s data. Do not include third-party personal information in the report or proof of concept.
This outline follows the impact and reproducibility criteria in the WordPress reporting handbook and HackerOne’s disclosure guidelines; it is not a quoted checklist from WordPress.
Why disclosure stays private while a fix is pending
Private reporting gives the project a chance to coordinate a fix while limiting potential harm. WordPress instructs reporters not to share vulnerability details with anyone else until the fix has been officially released. HackerOne’s general guidelines likewise describe reports as initially non-public while the security team works on remediation. Follow the program-specific policy for disclosure terms rather than inferring a universal publication deadline from general platform guidance.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
“It is standard practice to responsibly and privately disclose security vulnerabilities directly to the vendor (the WordPress core development team, in this case) so a fix can be coordinated and prepared in private, and damage from the vulnerability minimized.”
— Reporting Security Vulnerabilities, Make WordPress Core
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How WordPress bug bounty rewards work
A vulnerability report does not guarantee a payment. HackerOne’s general guidelines say some security teams offer monetary rewards and some do not; the security team decides whether to award a bounty and how much. Eligibility also depends on the applicable program terms and restrictions.
Specific WordPress payout amounts are not established here. Check the live WordPress HackerOne policy for current rewards and eligibility rather than relying on an old announcement. WordPress has announced time-limited bonus rewards around particular beta and release-candidate periods in the past; those were tied to specific release cycles, not standing bounty terms. The September 2026 program update also stresses report quality and significant impact as part of the Security Team’s broader work.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →What to verify before submitting
Use these questions to assess a finding and route it correctly:
- Which product or project is affected, and who owns it?
- What authentication, role, or other prerequisites does exploitation require?
- What concrete confidentiality, integrity, or availability impact can you demonstrate?
- Which versions are affected, and are they within the current program’s scope?
- What do the live program policy and disclosure terms say about eligibility, confidentiality, and rewards?
The WordPress Security Team page is a place to find current program announcements; use the live HackerOne policy for program-specific scope and participation terms.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
