Responsible disclosure policy.
If you've found a security vulnerability in Guardian Gaze or guardiangaze.com, we want to hear from you. Please read this policy before reporting.
Last updated: 1 January 2026
We welcome security disclosures
RedSecLabs is a security research firm. We take vulnerability reports seriously, respond promptly, and credit researchers who help us improve Guardian Gaze.
Scope
In scope:
- The Guardian Gaze WordPress plugin (current and prior major releases)
- guardiangaze.com (web application and API)
- Authentication and account management systems
Out of scope:
- Vulnerabilities in WordPress core, third-party plugins, or themes
- Social engineering attacks against our staff
- Physical security
- Denial-of-service attacks
- Automated scanning results without manual verification
How to report
Email your findings to [email protected]. Please include:
- A clear description of the vulnerability and its potential impact
- Steps to reproduce the issue
- Any proof-of-concept code or screenshots
- Your name or handle (if you want credit)
Please encrypt sensitive reports using our PGP key, available on request.
What we ask
- Act in good faith and do not access data beyond what is necessary to demonstrate the vulnerability
- Do not disclose the issue publicly until we've had a reasonable time to fix it
- Do not use the vulnerability to attack real users or live systems
- Comply with applicable laws throughout your research
What we promise
- 48-hour acknowledgement of your report during UK working hours
- Regular communication on progress toward a fix
- Public credit in our release notes and this page (if you want it)
- A 90-day disclosure window before we publish details publicly
- Safe harbour: we will not pursue legal action against good-faith researchers
Safe harbour
We consider security research conducted under this policy to constitute authorised activity. If legal action is initiated by a third party against you for research conducted under this policy, we will make our authorisation known. We ask that you contact us before engaging in research that might be otherwise illegal in your jurisdiction.
Hall of fame
We publicly recognise researchers who responsibly disclose qualifying vulnerabilities. If you'd like to be listed, include your preferred name or handle in your report.
Contact
[email protected], for vulnerability reports and security questions.
For WordPress.org security issues, see wordpress.org/about/security/.
A disclosure process is a security control, not a formality
A security product without a clear disclosure route pushes researchers toward whatever channel is available: a support ticket queue, a public forum, or a social media post. All three are worse for everyone, and the last one means the vulnerability is public while it is still unpatched.
So the process exists to make the right thing the easy thing: a direct route to the people who can fix it, an acknowledgement so the reporter knows it landed, and a commitment that reporting in good faith will not be treated as an attack.
That last point matters more than it sounds. Researchers weigh legal risk before they report, and organisations that have been hostile once stop receiving reports permanently, which does not make them more secure, only less informed.
Making a report actionable
The most useful reports contain a clear description of the issue, the affected component and version, reproduction steps precise enough to follow, and an assessment of impact. A proof of concept helps considerably; a video without accompanying detail generally does not.
Impact assessment is worth including even when it is uncertain. A researcher's read on what an attacker could actually achieve is valuable context, and disagreement about severity is a productive conversation rather than a problem.
What we ask in return is restraint on scope: test against your own installation rather than someone else's site, do not access or modify data that is not yours, and do not run denial-of-service testing against production infrastructure.
Acknowledgement, assessment, fix, disclosure
Reports are acknowledged so the reporter is not left wondering whether it arrived. Assessment establishes reproducibility and severity, which occasionally means going back with questions: that is normal and not a sign the report is being dismissed.
Fixes for genuine security issues take precedence over feature work. Where a fix requires a plugin release, users are notified through the normal update channel, and the changelog records that a security issue was addressed without publishing exploitation detail before people have had a chance to update.
We credit reporters who want credit and respect the preference of those who do not. Coordinated disclosure timing is a conversation rather than a unilateral decision: a researcher who has waited reasonably and received nothing has every right to publish, and we would rather not be the organisation that makes that necessary.
Common questions
Where do I report a vulnerability?
Through this process rather than a support channel, so it reaches the research team directly rather than sitting in a public queue while unpatched.
Will you take legal action against a good-faith researcher?
No. Testing in good faith against your own installation, without accessing data that is not yours and without denial-of-service testing against production, will not be treated as an attack.
What makes a report actionable?
A clear description, affected component and version, reproduction steps precise enough to follow, and your read on impact. A proof of concept helps; a video with no accompanying detail generally does not.
Will I be credited?
If you want to be. We credit reporters who want credit and respect the preference of those who do not.
How quickly do you fix security issues?
Security fixes take precedence over feature work. Where a fix needs a plugin release it goes through the normal update channel, and the changelog records that a security issue was addressed without publishing exploitation detail before people can update.
Do you run a bug bounty?
The process here is coordinated disclosure rather than a paid bounty programme. Disclosure timing is a conversation rather than a unilateral decision.