Updates to the WordPress Vulnerability Disclosure Program  🔗 **Source:** [Updates to the WordPress Vulnerability Disclosure Program](https://make.wordpress.org/security/2026/09/01/updates-to-the-wordpress-vulnerability-disclosure-program/) > [!note]+ Document Notes > tags: [wordpress-security, vulnerability-disclosure, bug-bounty, hackerone, core-security-initiative, plugin-security, privilege-escalation, security-research, wordpress-core, gutenberg, wordpress-security-team, ehtisham-siddiqui] > author: Ehtisham Siddiqui > source: make.wordpress.org > reference: https://make.wordpress.org/security/2026/09/01/updates-to-the-wordpress-vulnerability-disclosure-program/ > date created: 2026-09-02 07:20 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > > [!warning] Thin source — 273 words, five paragraphs > > A policy announcement on the Make/Security blog, dated 2026-09-01. Byline (Ehtisham Siddiqui) taken from the live page; Reader metadata recorded only "make.wordpress.org." Five links: the Core Security Initiative post (2026-08-28) and four to the HackerOne program page (hackerone.com/wordpress). The post says what changes but not the numbers behind it — no report volumes, no triage-time figures, no count of low-privilege reports rejected. The 18-section template is applied per the standing decision; several sections are one or two lines and say so. > > # 🏷️ Title: Updates to the WordPress Vulnerability Disclosure Program > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Source: https://make.wordpress.org/security/2026/09/01/updates-to-the-wordpress-vulnerability-disclosure-program/ - Linked: The Core Security Initiative — https://make.wordpress.org/security/2026/08/28/the-core-security-initiative/ - Linked (×4): WordPress program on HackerOne — https://hackerone.com/wordpress?type=team ## 📝 Summary **What this is.** The WordPress Security Team narrows the eligibility rules of its HackerOne vulnerability disclosure program. The change is framed as one half of a two-part strategy announced in the Core Security Initiative four days earlier: find and fix vulnerabilities proactively, and make sure inbound reports are "focused on issues with meaningful security impact." **The rule change, in three parts.** 1. For any in-scope asset *except* WordPress Core and Gutenberg, issues that require a role only an administrator can grant "will generally no longer be eligible unless they demonstrate a high-severity escalation and security impact." Contributor is named explicitly as such a role. 2. One authenticated role performing an action normally available to another authenticated role "will also generally not be sufficient on its own, unless it leads to a high impact escalation." 3. Core and Gutenberg "will, for now, continue to follow our existing eligibility guidelines." **What they want instead.** Reports of "high-severity issues that can be exploited without authentication or by low-privileged users such as Subscribers." **Bottom line.** The program is trading breadth for triage time. Contributor-and-above findings on non-Core assets — a large share of the low-and-medium CVEs the WordPress ecosystem publishes each year — are no longer bounty-eligible unless they escalate to high severity. Core and Gutenberg are carved out with an explicit "for now," which reads as a signal that the same rule may follow there once the Core Security Initiative's backlog work is further along. ## 📖 Main Content **The framing sentence.** "Improving the security of WordPress means both finding and fixing vulnerabilities proactively, and making sure the reports we receive through responsible disclosure are focused on issues with meaningful security impact." Both halves are about where the team's hours go. The post is a resource-allocation announcement written in security-policy language. **The tie to the Core Security Initiative.** The post says the team is "investing more in the security release process, working through existing findings, and expanding proactive vulnerability research and tooling." That list is the reason for the change: a team clearing a backlog and building tooling has less time for reports whose precondition is an admin-granted account. The VDP update is described as "alongside that work" — the two posts should be read together. **What "in-scope asset excluding WordPress Core and Gutenberg" covers.** The post doesn't enumerate. The HackerOne program's scope has historically included the WordPress.org sites and infrastructure and a set of canonical plugins and related projects; the exact list lives on the program policy page, which the post links four times but doesn't summarize. A reader can't tell from this post alone which plugins the new rule applies to. **The Contributor example.** Contributor is the lowest role that can create content (drafts) but can't publish or upload media. Stored-XSS-via-Contributor is one of the most common WordPress CVE shapes. Naming Contributor is the team saying, in effect, that class of finding no longer pays out on non-Core assets unless it escalates. **The cross-role clause.** "The ability for one authenticated role to perform an action normally available to another authenticated role" — e.g., an Author doing something an Editor can — is out unless it "leads to a high impact escalation." This closes the horizontal-privilege-shuffle category, which produces many valid-but-low-impact reports. **The carve-out.** Core and Gutenberg keep the old rules "for now." Two readings: (a) Core's attack surface justifies paying for lower-privilege findings because Core runs on every site; (b) the team intends to extend the rule to Core later and is staging it. The phrase "for now" supports (b) as at least a possibility; the post doesn't say. **What they're asking for.** Unauthenticated or Subscriber-level high-severity issues. Subscriber is the default registration role on sites with open registration, so "Subscriber-level" is close to "anyone who can create an account." That's the practical threat model for most WordPress sites and the one the team wants reports to match. **The closing line.** "focusing reports on higher-impact issues will help us spend more time on the findings that make WordPress and its ecosystem meaningfully safer." The word "ecosystem" is doing work — the team is claiming that reallocating its own hours improves security beyond Core, presumably through the proactive research and tooling the Initiative post describes. ## 🗒️ Notes - **Scope of the change is on HackerOne, not in this post.** Four of five links go to the program policy page. Anyone evaluating the impact needs to read the policy page's asset list and the "more examples" it now carries. This post is the announcement; the policy page is the rule. - **The Core carve-out is the interesting sentence.** "For now" is a deliberate hedge in a 273-word post that's otherwise plain. Watch for a follow-up. - **Where the excluded findings go.** Contributor-level XSS and cross-role issues in non-Core assets don't stop existing; they stop being bounty-eligible on this program. Researchers will still find them and will report them elsewhere — to plugin authors directly, to third-party CNAs (Wordfence, Patchstack), or publish. The post doesn't address what the team wants researchers to do with a valid-but-ineligible finding on a WordPress.org asset. Presumably "report it anyway, expect no bounty," but it isn't stated. - **The `wp-release-audit-method` angle.** Courtney's release-audit method is a *proactive* read of shipped code, which is the half of the strategy the Initiative post prioritizes. This VDP change doesn't touch it directly, but it changes what the team will pay attention to in inbound reports: Subscriber-level or unauthenticated, high severity. An audit method that scores findings by required role now has an external reference point for what "matters" to the security team. - **Plugins team relevance.** The rule applies to WordPress.org's own in-scope assets, not to the 60,000 directory plugins — those have their own disclosure paths. But the *rationale* (Contributor-level findings aren't worth triage time) is one plugin authors will cite when deprioritizing reports. Expect that argument to show up in plugin-review disputes. - **No numbers.** How many reports per month were Contributor-and-above? What share were duplicates or informational? The post doesn't say and the Initiative post might. The change is defensible on its face but its magnitude is unknowable from the text. - **Author.** Ehtisham Siddiqui — byline from the live page. Reader recorded the site as author, which is the pattern for Make blog posts with no `author` meta tag. ## 📚 References - Siddiqui, E. *Updates to the WordPress Vulnerability Disclosure Program*, Make WordPress Security, 2026-09-01. - WordPress Security Team, *The Core Security Initiative*, Make WordPress Security, 2026-08-28 (linked; not read for this note). - WordPress program policy on HackerOne — https://hackerone.com/wordpress?type=team (linked; not read for this note; holds the asset list and the new examples). - Cross-reference: Courtney's `wp-release-audit-method` (public origin/main) — proactive audit as the complementary half of the strategy this post describes. ## 🗣️ Paraphrase We're tightening what the bounty program pays for. If your finding on anything other than Core or Gutenberg needs an account an admin had to hand out — Contributor included — we generally won't take it unless it escalates to something high-severity. Same for "role A can do what role B can do." Core and Gutenberg keep the old rules for now. What we want: high-severity bugs reachable without logging in or with a Subscriber account. We're doing this because the security team is spending its hours on the release process, the existing backlog, and proactive research, and we want inbound reports to compete for that time only when they matter. ## 📰 Newsletter **WordPress narrows its bug bounty.** Four days after announcing the Core Security Initiative, the Security Team has updated the HackerOne program's eligibility rules. For every in-scope asset except Core and Gutenberg, findings that require an admin-granted role — Contributor is named — are out unless they show high-severity escalation; so is one role doing another role's job, absent high impact. The team wants unauthenticated or Subscriber-level high-severity reports instead. Core and Gutenberg keep the existing rules "for now," a hedge worth watching. The post is 273 words and gives no report volumes, so the size of the shift is unknowable from the announcement; the asset list and new examples live on the HackerOne policy page. Practical effect: the Contributor-XSS class of finding, one of the most common WordPress CVE shapes, no longer pays out on WordPress.org's own non-Core assets. Researchers who find them will route elsewhere; the post doesn't say where the team would prefer. ## ✅ Action Items **DevRel** - Not applicable to this source. **OSPO** - A worked example of an open-source project narrowing a disclosure program to protect maintainer time; useful for any OSPO writing VDP policy. The "for now" staging on the highest-value asset is the reusable move. `#action/h3` **Community** - Not applicable to this source. **WordPress teams** (Core, Core Performance, Core AI, Core Program Team, Mobile, Playground, Community, Training, Marketing, Support, Design, Documentation, Photos, TV, Polyglots, Accessibility, Meta, CLI, Hosting, Tide, Openverse, Themes, Plugins) - **Core / Gutenberg:** the carve-out is explicit and temporary-sounding. Anyone on the Core security side should know a follow-up may extend the rule. `#action/h2` - **Plugins:** the rationale will be cited by plugin authors deprioritizing Contributor-level reports. The plugin review team may want a line in the guidelines clarifying that directory plugins' disclosure expectations haven't changed. `#action/h2` - **Hosting:** Subscriber-level and unauthenticated are now the named priority classes. Hosts with WAF rules or virtual patching should weight those classes accordingly. `#action/h3` - **Meta:** WordPress.org sites are the largest in-scope non-Core asset; this rule changes what gets reported against them. `#action/h3` - All other teams: not applicable to this source. **The WPOCC** - Not applicable to this source. **FAIR** - Not applicable to this source. **Personal (Courtney)** - **Read the Core Security Initiative post** (2026-08-28) — this VDP change is described as a consequence of it, and the Initiative post likely carries the numbers this one lacks. Deep-read candidate. `#action/h1` - **Add a "required role" axis to `wp-release-audit-method` scoring** if it isn't there, with this post as the external reference for the security team's priority ordering (unauthenticated > Subscriber > Contributor-and-above). `#action/h2` - **Check the HackerOne policy page's asset list** before citing this post's scope in anything public — the post says "in-scope asset" without enumerating. `#action/h3` ## 🧪 Hypotheses - **H-A:** The Core/Gutenberg carve-out is staged, not permanent; a follow-up within six months will extend the admin-granted-role exclusion to Core with a high-severity exception. *Falsifiable by watching the Security blog.* - **H-B:** Contributor-level XSS reports against WordPress.org assets will not decline; they'll shift to direct disclosure or third-party CNAs, and some will be published without coordination. *Testable via CVE feeds tagged to WordPress.org properties over the next year.* - **H-C:** The Initiative post carries the report-volume numbers this post omits. *Testable by reading it.* - **H-D:** Plugin authors will cite this rule when declining Contributor-level reports on directory plugins, even though the rule doesn't apply to them. *Testable in plugin-review and support-forum threads.* ### 📊 Methodology A policy announcement, not an argument. It states a rule change and a rationale (triage time toward higher-impact work) and links to the policy page for detail. No data is offered for the rationale. The right way to evaluate it is to read the linked Initiative post for numbers and the HackerOne page for the asset list, then compare the excluded classes against the published CVE record for WordPress.org assets to estimate what share of past reports the rule would have excluded. ### ❓ Questions - What share of the program's inbound reports over the past year required Contributor-or-above on non-Core assets? What share of those were paid? - Which assets are "in scope excluding Core and Gutenberg"? (Answer is on HackerOne, not in the post.) - What should a researcher do with a valid, ineligible finding on a WordPress.org asset — report without bounty, or is it out of scope entirely? - Is "for now" a staging signal or a hedge against having to revisit? Who decides, and when? - Does "high-severity escalation" have a CVSS threshold, or is it triaged case by case? - How does this interact with third-party CNAs that already assign CVEs for WordPress ecosystem findings? ### 🔮 Future Research - Deep-read the Core Security Initiative post and pair the two notes. - Pull the HackerOne policy page and record the in-scope asset list at the date of this change, so a later comparison is possible. - Track Security blog posts for a Core/Gutenberg follow-up. - Compare the excluded classes against `wp-release-audit-method`'s finding taxonomy to see whether the audit method's severity ordering matches the team's stated priorities. ### 💡 Implications **For researchers.** The economics of WordPress bounty hunting on WordPress.org assets just shifted toward unauthenticated and Subscriber-level work. Contributor-level findings are now volunteer work on non-Core assets. **For the project.** A public statement of priority ordering — unauthenticated, then Subscriber, then everything else only if it escalates. That ordering is citable in triage disputes, in audit scoring, and in hosting WAF prioritization. **For plugin authors.** The rule doesn't apply to directory plugins, but the rationale will be borrowed. Expect "the security team doesn't pay for Contributor-level either" in disputes, accurate or not. **For governance.** The change follows the Initiative post by four days and is described as a consequence of it. That's a legible cause-and-effect chain from strategy announcement to policy change — rare enough on Make blogs to note. ## 🧠 Learning Styles Assessment **Read/write** — the only mode served. Five paragraphs, plain prose, four repeated links. **Visual** — not served; no diagram of the old vs. new eligibility, which a two-column table would have made clearer. **Kinesthetic** — indirectly: the policy page is where a researcher would go to act. **Auditory** — not served. **Global vs. sequential** — the post is short enough that the distinction doesn't apply; the rule is in paragraph three, the rationale in paragraphs one, two, and five. **Overall:** an announcement, not instruction. A reader who needs the rule needs the HackerOne page. ## 📊 Accessibility Assessment Assessment of the captured HTML only. Not a WCAG audit of make.wordpress.org. #### Alternative text and non-text content No images in the captured content. An Open Graph image exists in Reader metadata. #### Keyboard navigation Not testable from the capture. Standard Make blog theme; no interactive elements in the post body. #### Contrast and readability Not assessable from HTML. Prose is short and plain; reading level is appropriate for the audience. #### Text resizing and reflow No fixed-width content in the post body. #### Media and captions No media. #### Forms and interactions None in the post body. #### Standards reference WCAG 2.2 AA is the standard the assessment above is loosely mapped to (1.1.1, 2.4.1, 1.4.3, 1.4.10, 1.2). Nothing can be marked pass or fail from this capture. One link-text note: the same URL is linked four times with different anchor text ("the Vulnerability Disclosure Program," "guidelines," "program policy page," "here") — the last is a WCAG 2.4.4 Link Purpose weakness in isolation, though the surrounding sentence supplies context. ## 🌍 DEIB Assessment #### Cultural breadth Written for a global security-researcher audience in plain English. No region-specific assumptions. #### Inclusive language Neutral. "Researchers," "the security team," "we." #### Neurodiversity support Short, five paragraphs, one rule per sentence. The repeated links with varying anchor text are the one friction point. #### Representation A single team voice. No researcher perspective is quoted; the people most affected by the change (bounty hunters whose Contributor-level work is now ineligible) aren't represented in the text. #### Psychological safety The post explains its reasoning rather than just stating the rule, which lowers the cost of a researcher asking about a borderline case. It doesn't say where to ask. ## ✅ Logical Validity **Argument structure.** Premise: the team's time should go to findings with meaningful security impact. Premise: findings requiring admin-granted roles on non-Core assets generally lack that impact. Conclusion: exclude them unless they escalate. Valid form. The second premise is asserted without data; it's plausible (admin-granted preconditions shrink the attacker population) but its magnitude — how much triage time was going to such reports — is unstated. **Hedges.** "Generally," "unless," "for now" appear throughout. The post is honest about being a default rule with exceptions, not a bright line. That makes it harder to game and harder to dispute. **Gaps.** Doesn't say what to do with valid-but-ineligible findings. Doesn't enumerate in-scope assets. Doesn't define "high-severity." All three are delegated to the HackerOne page, which is reasonable but makes the post incomplete as a standalone rule. **Fallacies.** None. The closest is an implied appeal to scarcity ("so that our time… is focused") without showing the scarcity, but that's an omission, not a fallacy. **Verdict.** Valid, under-evidenced, appropriately hedged. Read with the Initiative post and the policy page. ## 🛡️ DARVO Analysis Not applicable to this source. No accusation, no reversal, no victim/offender framing. The post narrows a program and says why. It doesn't blame researchers for low-quality reports; it says the team wants to spend its time differently. A more defensive version of this post would have existed — "we've been flooded with low-value reports" — and the team didn't write it. ## 🎯 Conclusion A 273-word policy change with one memorable sentence: for everything except Core and Gutenberg, admin-granted roles — Contributor included — no longer qualify unless the finding escalates to high severity. The stated reason is triage time, redirected toward the Core Security Initiative's release-process, backlog, and proactive-research work. The post is honest and hedged, gives no numbers, and delegates the asset list and definitions to HackerOne. The sentence to watch is the carve-out: Core and Gutenberg keep the old rules "for now." For Courtney the practical value is a published priority ordering — unauthenticated, then Subscriber-level, then everything else only if it escalates — that `wp-release-audit-method` can cite as an external reference for how the WordPress Security Team ranks required role. Read the Initiative post next; it's where the reasoning this post summarizes probably lives in full. ## 🔄 Refactor Appendix — Updates to the WordPress Vulnerability Disclosure Program ### 📚 Literature Atoms (H3) #### [H1] Admin-granted roles no longer qualify on non-Core assets unless the finding escalates > [!quote] ID:rw_01m1gzqevrg56c5zw5pd0cghgf > "For any in-scope asset excluding WordPress Core and Gutenberg, issues requiring a role that can only be granted by an administrator will generally no longer be eligible unless they demonstrate a high-severity escalation and security impact. This includes roles like Contributor." The rule. Contributor named explicitly; "generally" and "unless" make it a default with exceptions. Tags: `#atom/literature/h1` #### [H2] Core and Gutenberg are carved out "for now" > [!quote] ID:rw_01m1gzqevrg56c5zw5pd0cghgf > "WordPress Core and Gutenberg will, for now, continue to follow our existing eligibility guidelines." The hedge in an otherwise plain post. Staging signal or caution — either way, watch for a follow-up. Tags: `#atom/literature/h2` #### [H3] The priority ordering: unauthenticated, then Subscriber-level, high severity > [!quote] ID:rw_01m1gzqevrg56c5zw5pd0cghgf > "We encourage researchers to focus on vulnerabilities with a clear security impact, particularly high-severity issues that can be exploited without authentication or by low-privileged users such as Subscribers." A published ranking of required role that audit methods and WAF prioritization can cite. Tags: `#atom/literature/h3` #### [H4] The change is a consequence of the Core Security Initiative's time reallocation > [!quote] ID:rw_01m1gzqevrg56c5zw5pd0cghgf > "As part of the broader work underway through the Core Security Initiative, the security team is investing more in the security release process, working through existing findings, and expanding proactive vulnerability research and tooling." The rationale: hours moving from inbound triage to proactive work. The numbers, if any, are in the linked post. Tags: `#atom/literature/h4` ### 🧠 Permanent Candidates (H4) #### [P1] A disclosure program's eligibility rules are a published statement of where maintainer hours go Narrowing bounty eligibility by required role isn't primarily a security judgment about the excluded class; it's a statement that triage time on those reports is worth less than the proactive work it displaces. The rules therefore double as a priority ordering that outside parties — auditors, hosts, plugin authors — can cite. *Candidate; one source, but the mechanism is general to any project running a VDP with finite triage capacity.* Links: [[Maintainer Time Is the Scarce Security Resource]] · [[WordPress Release Audit Method]] · [[WordPress Security MOC]] Tags: `#atom/zettel/z1` ### ✏️ Fleeting Queue - "For now" on Core/Gutenberg — set a reminder to check the Security blog in six months. `#atom/fleeting/f1` - The post doesn't say where valid-but-ineligible findings should go. Worth asking in #core-security or on the post. `#atom/fleeting/f1` - Contributor-XSS is the canonical low/medium WordPress CVE; this is the first time the project has said in policy that it's not worth paying for on its own assets. `#atom/fleeting/f1` ### → Things 3 (max 2 actions) 1. **Deep-read the Core Security Initiative post** (make.wordpress.org/security/2026/08/28/the-core-security-initiative/) and pair it with this note. `#action/h1` 2. **Add the team's role-priority ordering to `wp-release-audit-method`'s severity notes**, citing this post. `#action/h2` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Updates to the WordPress Vulnerability Disclosure Program.md|Updates to the WordPress Vulnerability Disclosure Program by Ehtisham Siddiqui]] ## Highlights - As part of the broader work underway through the [Core Security Initiative](https://make.wordpress.org/security/2026/08/28/the-core-security-initiative/), the security team is investing more in the security release process, working through existing findings, and expanding proactive vulnerability research and tooling. Alongside that work, we’re updating [the Vulnerability Disclosure Program](https://hackerone.com/wordpress?type=team) [guidelines](https://hackerone.com/wordpress?type=team) so that our time, and the time of security researchers, is focused on valid vulnerabilities with clear and significant impact. ([View Highlight](https://read.readwise.io/read/01m1h0e25tne34qtqhgp5c0ntd)) - Note: H4 — the rationale: hours moving from inbound triage to release process, backlog, and proactive research. The numbers, if any, are in the linked Initiative post (2026-08-28) — deep-read candidate. #atom/literature/h4 - Tags: atom/literature/h4 - For any in-scope asset excluding WordPress Core and Gutenberg, issues requiring a role that can only be granted by an administrator will generally no longer be eligible unless they demonstrate a high-severity escalation and security impact. This includes roles like Contributor. The ability for one authenticated role to perform an action normally available to another authenticated role will also generally not be sufficient on its own, unless it leads to a high impact escalation. WordPress Core and Gutenberg will, for now, continue to follow our existing eligibility guidelines. More examples can be found on our [program policy page](https://hackerone.com/wordpress?type=team). ([View Highlight](https://read.readwise.io/read/01m1h0dbt0s545ee878jz7cp3q)) - Note: H1+H2 — the rule and the carve-out. Contributor named explicitly; "generally"/"unless" make it a default with exceptions. "For now" on Core/Gutenberg is the sentence to watch — staging signal or hedge. Asset list and definitions live on HackerOne, not here. #atom/literature/h1 - Tags: atom/literature/h1 - We encourage researchers to focus on vulnerabilities with a clear security impact, particularly high-severity issues that can be exploited without authentication or by low-privileged users such as Subscribers. ([View Highlight](https://read.readwise.io/read/01m1h0dpbwj7a6xf0g2032r1p4)) - Note: H3 — the published priority ordering: unauthenticated, then Subscriber-level, high severity. Citable in wp-release-audit-method severity notes and hosting WAF prioritization. #atom/literature/h3 - Tags: atom/literature/h3