Responsible disclosure
Report it privately. We will answer.
A security boundary product has to be told when its boundary leaks. This page sets out what to send, where to send it, what we commit to in return, and what testing is and is not acceptable.
- Private reporting
- Acknowledged within 3 business days
- Credit where you want it
How to report
Email [email protected]. Use that address only — not the support queue, not the public plugin forum, and not a public issue tracker.
If you would rather not send technical detail by plain email, send a short message describing the class of issue and the affected component, and we will arrange an encrypted channel before you send anything further.
A public post about an unfixed issue in a governance plugin puts every site running it at risk, including sites whose operators have no way to respond quickly.
What to include
- Affected component
- Plugin version, and whether the issue is in the free or a paid edition.
- Environment
- WordPress version, PHP version, single site or multisite.
- Impact
- What an attacker gains — and specifically whether it crosses a stated boundary such as native authorization, default deny, approval binding, or the audit chain.
- Reproduction
- Minimal, ordered steps. A concise proof of concept is welcome; a weaponised exploit is not.
- Prerequisites
- What access the attacker needs to begin: unauthenticated, subscriber, an agent credential, or administrator.
- Contact
- How to reach you, and whether you want to be credited.
Prerequisites matter more than they may seem. An issue that requires an administrator account is a different severity from one that requires nothing, and telling us which it is speeds up triage considerably.
What we commit to
| Stage | Our commitment |
|---|---|
| Acknowledgement | Within 3 business days, from a person, not an autoresponder. |
| Triage | An initial severity assessment and a reproduction result within 10 business days. |
| Updates | At least every 14 days while the report is open. |
| Fix | Prioritised by severity. Anything that breaks a stated boundary is treated as the highest priority work in progress. |
| Disclosure | Coordinated with you, normally at release. We will say what was fixed and what an operator should do. |
We will not take legal action against a reporter who follows this policy in good faith, and we will not ask you to sign anything before we accept a report.
Scope
In scope
- The RuleFence plugin, current release, free and paid editions.
- Any bypass of native WordPress authorization through a governed request.
- Any way to execute a governed action without the corresponding decision or record.
- Replay or rebinding of a one-time approval, including to different inputs.
- Tampering with the audit chain that verification does not detect.
- Privilege escalation between agents, sites, or WordPress users.
- Defeating emergency modes, session termination, or credential invalidation.
- This website, where the issue affects the confidentiality or integrity of visitor or customer data.
Out of scope
- WordPress core, other plugins, themes, or hosting infrastructure — report those to their maintainers.
- Findings that require a compromised administrator account to begin.
- Automated scanner output with no demonstrated impact.
- Missing hardening headers or best-practice suggestions with no exploit path.
- Social engineering, physical attacks, or anything targeting our staff or customers.
Testing rules
- Test on a site you own or have written permission to test. Never on someone else’s production site.
- Use the smallest proof necessary. Stop as soon as impact is demonstrated.
- Do not access, modify, exfiltrate, or retain data that is not yours. If you encounter personal data, stop and tell us.
- No denial of service, resource exhaustion, or load testing against our systems.
- No spam, phishing, or attempts against accounts you do not control.
- Do not use the finding to gain access beyond what is needed to prove it exists.
There is no monetary reward at this time. We do offer credit, a direct line to the maintainers, and a fix — and we will say so plainly rather than implying a payout that does not exist.
Behaviour that is not a vulnerability
Some reports describe the product working as designed. These are worth documenting so nobody spends a week on them.
- A refused request. Default deny, a native denial, and a required approval are controls, not faults.
- An expired approval. Expiry is deliberate; an unused approval is not meant to become a standing permission.
- A refused replay. Approvals are single-use and input-bound by design.
- An administrator widening access. An administrator can grant permissions; that is the job. It is not escalation.
- Failing closed. Refusing to act when a control cannot be evaluated or recorded is the intended behaviour.
If you believe one of these is being applied incorrectly — a control that should have refused and did not — that is in scope. Send it.
Credit
Unless you ask otherwise, we credit reporters by name in the release notes for the version that carries the fix. Tell us how you would like to be named, or say that you would prefer not to be named at all.
A boundary you can check
Read what the model does and does not promise.
The security page sets out the guarantees this policy exists to protect.