The security of our websites and software products is essential to us and our customers. In spite of our care, procedures and best efforts it is possible that there are vulnerabilities in our websites or software products. If you find any, please tell us as soon as possible so we can fix it.
- Last updated: 6 Aug 2026
Recent update: We’ve further clarified our AI-assisted reporting rules, added minimum requirements for a valid report, and published an explicit out-of-scope list to reduce unverified and low-impact submissions.
Scope:
You may check the following domains (including subdomains) for vulnerabilities:
- really-simple-ssl.com
- scan.really-simple-ssl.com
- translate.really-simple-plugins.com
- api.really-simple-security.com
You may test the following WordPress plugins for vulnerabilities:
- Really Simple Security (free)
- Really Simple Security Pro
- Really Simple Security Pro Multisite
If you want to test the Pro versions of the aforementioned plugins, you will have to buy a license through the respective websites.
We ask you to:
Report your findings by sending an e-mail to: [email protected]
- Inform us of the vulnerability as soon as possible after you discover it.
- Give us enough information to reproduce the problem, so we can fix it ASAP. A valid report must meet the minimum requirements below.
- Disclose whether you used AI to find, analyze, or write the report, including which tool(s) were used and for what. We do not discourage the use of AI, but unverified AI output will be rejected.
- Give us your contact information so we can contact you when we have questions.
- Do not share any information regarding the vulnerability with third parties until it is fixed. This includes third party vulnerability and bug bounty programs, as this would cause us additional work coordinating communications that could be spent on fixing the vulnerability.
- Be responsible by not taking any actions other than the minimum required to verify the vulnerability.
Minimum requirements for a valid report
A report is only considered valid if it includes all of the following:
- Affected product and exact version tested
- Required attacker privilege (unauthenticated / subscriber / contributor / etc.)
- Numbered reproduction steps on a default or clearly described WordPress setup
- A proof of concept you personally executed, showing real security impact
- A clear exploit chain: attacker-controlled input → vulnerable code path → security impact
Theoretical findings, static analysis notes, and “this looks unsafe” reports without a working proof of concept are not vulnerabilities under this policy. Bulk or spray submissions may be held or closed without individual replies.
AI-assisted reports
We do not ban AI assistance, but we wish to know when it is being used. Do not submit unverified AI output.
- If you use AI to find, analyze, or write a report, you must disclose which tool(s) were used and for what.
- You must personally reproduce the issue on a real/stock WordPress installation.
- You must include a working proof of concept that you have executed yourself.
Reports that appear to be unverified AI output (fabricated code paths, non-existent functions, generic vulnerability templates, or scanner dumps without human verification) will be closed without further triage. Repeated low-quality submissions may result in permanent exclusion from our bounty program.
Out of scope
The following are explicitly out of scope and will be closed without bounty consideration:
WordPress / plugin-specific
- Issues that require Administrator,
manage_options,manage_security, orunfiltered_html, unless you demonstrate privilege escalation from a lower role - Missing capability checks already enforced by WordPress core on the same request path, unless you show a bypass
- Unescaped output / “XSS” without a proven path for an attacker at the stated privilege to inject unsanitized content
- CSRF on low-impact actions without demonstrated security impact
- Stored XSS that only affects the same user who stored the payload (self-XSS)
- Issues that only affect sites where an administrator has intentionally enabled a dangerous setting or pasted attacker-controlled content into a trusted field
- Findings that require WP-CLI, direct database access, filesystem access, or server misconfiguration outside the plugin
- Reports against intentionally admin-controlled security features (for example .htaccess edits, firewall rules, or custom login URL), unless the feature exposes a secret or is exploitable without that admin action
- Admin self-lockout by enabling a security feature, unless a lower-privileged attacker can trigger the lockout or bypass the control
No / low security impact
- Missing or “weak” security headers, CSP recommendations, or cookie flags without a demonstrated exploit
- SSL/TLS configuration, cipher suites, or HSTS preload suggestions
- Version, path, or software disclosure without a follow-on exploit
- Open redirects without demonstrated impact (such as session/token theft or authentication bypass)
- Rate limiting or brute force on non-authentication endpoints
- Clickjacking on pages without sensitive actions
- Verbose error messages or 404 pages without sensitive data exposure
- Hardening suggestions without proof of exploitability
Process / environment
- Vulnerabilities only present in outdated, unsupported, or modified plugin versions
- Issues in third-party plugins, themes, hosting, or WordPress Core
- Denial of service, resource exhaustion, or spam flooding
- Social engineering, phishing, or physical attacks
- Automated scanner output or AI-generated reports without personal verification and a working proof of concept
- Duplicate reports (first valid reporter only)
- Hypothetical attacks that assume leaked secrets the plugin never exposes to the attacker
The following is explicitly NOT allowed:
Doing any of these things without explicit prior written consent from us may result in a report to law enforcement and or legal action against you!
- Uploading malware, viruses, trojans etc.
- Changing or removing information
- Changing the system configuration
- Sharing access with others
- Using denial-of-service attacks
- Anything that damages or has a negative impact on the availability of our websites, or the systems of the users of our software
If you think you have found a vulnerability but feel you cannot produce proof of compromise without complying with the above restrictions, please contact us.
What you can expect from us:
- If you play by the rules set above when finding security vulnerabilities, we will not pursue any legal action against you regarding the discovery of the vulnerabilities you reported to us.
- We treat every report with the highest confidentiality and will never share your personal information without your express consent, unless we are forced to do so by a legally binding court order.
- If you give us permission, we will credit you for reporting a confirmed vulnerability by putting your name in a thank you section on our website and release notes.
- We will send you a confirmation of the receipt of your report within one business day
- We will respond to a report within 3 business days with an assessment of the vulnerability and the expected time needed to fix the issue
- We will keep you informed of the progress we make in fixing the issue
- We aim to fix the issue reported by you a.s.a.p. The maximum time we may take to fix any issue is 60 days after getting the report.
What we do with vulnerabilities we find ourselves:
When we find vulnerabilities in software or websites we use, we will inform the responsible parties according to their responsible/coordinated vulnerability disclosure policy.
Bounties
Only reports of real vulnerabilities with proof that you personally can exploit them are eligible for rewards. We may reward those vulnerabilities with proof of compromise with monetary compensation, depending on the possible impact of the vulnerability. Eligibility and size of bounties are solely at our discretion. Out-of-scope reports are not eligible for rewards.
Please do not submit output from automated scanning tools or AI-generated reports unless you have personally verified the finding and included a working proof of concept.
Any time spent by us on invalid reports you make will limit any bounties you may receive for real vulnerabilities in the future!
- Compliance with this policy is a prerequisite for being eligible for a reward; violation of this policy may lead to permanent exclusion from our bounty program.
- Reports of Denial Of Service vulnerabilities do NOT qualify for rewards.
- Reports of old software versions, or missing best practices without proof of exploitability do NOT qualify for rewards.
- In case of duplicate reports (multiple reports about the same vulnerability), only the first submitter will be eligible for a reward.
Reporting data breaches
Your privacy and the confidentiality of you and your data is very important to us. In spite of the care we take protecting your data it is possible for information to leak. This is how we would handle such an event:
What we consider a data breach
A situation where we know or can reasonably suspect that unauthorized access to personal or business information entrusted to us has occurred
How we respond to a data breach
After finding out about the data breach, our highest priority is fixing the leak and preventing damage to those concerned. We will investigate the breach to determine how and what data was leaked, what the cause of the breach was and who had access to the leaked data. We will take actions to prevent this from happening again. When we find illegal acts have been a factor in the data breach we will report this to the police.
Who do we inform about a data breach
We will inform all persons and organisations affected by the data breach. We will inform the Dutch Data Protection Authority (Autoriteit Persoonsgegevens) whenever Personally Identifiable Information is involved.