diff --git a/contributions.md b/contributions.md
index d69ecb6d..a3160000 100644
--- a/contributions.md
+++ b/contributions.md
@@ -11,6 +11,7 @@
 * **[Pull requests](https://make.wordpress.org/cli/handbook/contributions/pull-requests/)** - Submit your first bug fix or new feature.
 * **[Release checklist](https://make.wordpress.org/cli/handbook/contributions/release-checklist/)** - Tasks performed during the process of tagging a release.
 * **[Roadmap](https://make.wordpress.org/cli/handbook/contributions/roadmap/)** - Where WP-CLI is going in the future.
+* **[Security Vulnerability Reporting](https://make.wordpress.org/cli/handbook/contributions/security-vulnerability-reporting/)** - How we accept and evaluate vulnerability reports.
 * **[Code Review](https://make.wordpress.org/cli/handbook/contributions/code-review/)** - Quality Assurance on WP-CLI
 * **[Committers credo](https://make.wordpress.org/cli/handbook/contributions/committers-credo/)** - Product quality, Stellar judgement, Consistent participation
 * **[Repository Management](https://make.wordpress.org/cli/handbook/contributions/repository-management/)** - Naming, Versions, Milestones, Labels
diff --git a/contributions/security-vulnerability-reporting.md b/contributions/security-vulnerability-reporting.md
new file mode 100644
index 00000000..1b350711
--- /dev/null
+++ b/contributions/security-vulnerability-reporting.md
@@ -0,0 +1,82 @@
+# Security Vulnerability Reporting for WP-CLI
+
+The WP-CLI team appreciates security vulnerability reports and takes them seriously. If you believe you have discovered a security vulnerability in WP-CLI, please read this page in full before following [our responsible disclosure process](https://github.com/wp-cli/wp-cli/security/policy). A valid report can be granted a CVE and may be rewarded with a bounty payment via the HackerOne program.
+
+## Report validity
+
+A growing number of the vulnerability reports we receive are not genuine vulnerabilities. They describe behavior that may be technically accurate in isolation but requires an attacker to already possess more power than the reported vulnerability would grant, or that depends on a victim being socially engineered into compromising themselves. Triaging these reports takes up maintainer time that would be better spent elsewhere.
+
+What follows is a set of triage maxims borrowed in spirit from [Brocards for vulnerability triage](https://blog.yossarian.net/2026/04/11/Brocards-for-vulnerability-triage) by the maintainer of [Zizmor](https://github.com/zizmorcore/zizmor), adapted to WP-CLI's threat model. A *brocard* is a concise legal maxim that captures the essence of a principle. None of these are universally true, and any given report may rebut any of them, but each lets us evaluate a report quickly when it covers a category we routinely decline.
+
+## Understand WP-CLI's threat model first
+
+Most invalid reports we receive share a single root cause: a misunderstanding of who WP-CLI trusts.
+
+WP-CLI is a tool that an operator runs from a shell on a server in order to administer a WordPress installation. To run `wp` at all, you must already be able to execute arbitrary code on that server. It is a tool for people who are already inside the trust boundary.
+
+This means the operator running WP-CLI is **not** a party we must defend against because WP-CLI's job is not to protect the server from the people who administer it.
+
+A report only describes a vulnerability if it shows how someone **outside** that boundary gains something they could not otherwise have.
+
+## No vulnerability without a threat model
+
+A report must explain who the attacker is and what they gain. "This function could behave unexpectedly" or "this input is not sanitized" is not a vulnerability report, it is an observation. Without a plausible attacker who ends up with more access than they began with, there is nothing to fix from a security standpoint (though it may still be [a good bug report](https://make.wordpress.org/cli/handbook/contributions/bug-reports/)).
+
+The team will decline reports that demonstrate no actual exploit. This may include:
+
+- An exposed stack trace or error message with no attack vector
+- A "dangerous" code path that no realistic input can reach
+- A theoretical weakness being presented as a concrete one
+
+## No exploit from the heavens
+
+If exploiting the reported behavior requires the attacker to already hold a capability equal to or greater than the one they gain, there is no vulnerability.
+
+A common form of this report requires that the attacker can already write files to the target server, and then demonstrates that WP-CLI will trust a malicious file they placed there. An attacker who can write a malicious file to the server has already won, and the WP-CLI team considers this to be true regardless of the form that the malicious file takes.
+
+The same applies to a report that requires the attacker to already have access to the database, the filesystem, a server control panel, or a shell, and then frames WP-CLI's normal trust of that environment as the flaw.
+
+## The user is not their own attacker
+
+A vulnerability in the form of "a remote attacker can convince a WP-CLI user to run a malicious command" is not a vulnerability in WP-CLI, it is social engineering.
+
+Any command-line tool will do what the person at the terminal tells it to do. WP-CLI cannot, and does not attempt to, defend the operator against their own keystrokes, including input that's obviously malicious or cleverly obfuscated.
+
+## A broken neighbour is not our vulnerability
+
+Some reports are only exploitable on shared hosting where multiple accounts are not properly isolated from one another. This is a failure of isolation in a multi-tenant environment. The classic problem is account A being able to read account B's files or write into a location account B's WP-CLI will read.
+
+When the operating system or hosting platform fails to isolate tenants, the vulnerability lives in that misconfiguration, not in WP-CLI. It is expected that WP-CLI can assume that the server enforces safe user and file permissions.
+
+## Denial of self is not denial of service
+
+Reports of denial of service, memory exhaustion, runaway CPU usage, infinite loops, or processes that consume too many resources are, for WP-CLI, generally not security vulnerabilities.
+
+If a command consumes too much memory or runs too long, the operator can press `Ctrl-C` or set a memory or time limit. No privilege boundary is crossed if a weakness results in runaway resource usage.
+
+## No vulnerability from an unsupported configuration
+
+If the behavior can only be triggered under an unusual, unsupported, or deliberately insecure configuration of WordPress, the server, or WP-CLI, the problem lies in that configuration.
+
+Examples include reports that depend on:
+
+- World-writable directories
+- Disabling PHP safeguards
+- Running WP-CLI as `root`
+- Unusual or malformed settings that no default installation would ever produce
+
+## No cure worse than the disease
+
+When a report identifies real but marginal behavior, the team will weigh the cost of the fix against the risk it removes.
+
+This includes weaknesses where the fix would:
+
+- Break common workflows
+- Remove or restrict a documented feature
+- Impose significant complexity in order to fix a vulnerability that requires implausible preconditions
+
+Such fixes may do more harm than the issue it addresses. Where the downside of fixing such an issue exceeds the vulnerability's impact, the team may instead choose to clearly document the behavior.
+
+## If your report still stands
+
+The above are filters, not walls. If you have read this far and your report still demonstrates that an attacker outside of WP-CLI's trust boundary can gain access they should not have, then please [disclose it responsibly](https://github.com/wp-cli/wp-cli/security/policy) and the team will endeavour to handle it accordingly.
diff --git a/index.md b/index.md
index c419e0ff..b067fe5d 100644
--- a/index.md
+++ b/index.md
@@ -48,6 +48,7 @@ Can’t find what you’re looking for? [Open an issue](https://github.com/wp-cl
 * **[Pull requests](https://make.wordpress.org/cli/handbook/contributions/pull-requests/)** - Submit your first bug fix or new feature.
 * **[Release checklist](https://make.wordpress.org/cli/handbook/contributions/release-checklist/)** - Tasks performed during the process of tagging a release.
 * **[Roadmap](https://make.wordpress.org/cli/handbook/contributions/roadmap/)** - Where WP-CLI is going in the future.
+* **[Security Vulnerability Reporting](https://make.wordpress.org/cli/handbook/contributions/security-vulnerability-reporting/)** - How we accept and evaluate vulnerability reports.
 * **[Code Review](https://make.wordpress.org/cli/handbook/contributions/code-review/)** - Quality Assurance on WP-CLI
 * **[Committers credo](https://make.wordpress.org/cli/handbook/contributions/committers-credo/)** - Product quality, Stellar judgement, Consistent participation
 * **[Repository Management](https://make.wordpress.org/cli/handbook/contributions/repository-management/)** - Naming, Versions, Milestones, Labels