SecuPress is committed to working with security experts to stay up to date with the latest security techniques. If you have discovered a security issue that you believe we should know about, we’d welcome working with you.
Rewards Scope
- Security bugs in SecuPress Pro and Free plugin (last update version) are qualified.
- Security bugs on secupress.me are NOT qualified but welcomed.
Qualifying vulnerabilities
Note that the scope of the program is limited to technical vulnerabilities found using your browsers, mobile, and web applications; please do not attempt phishing attacks against us.
Any design or implementation issue that affects the confidentiality or integrity of user data is likely to be in scope for the program. Common examples include:
- Cross-Site Scripting (XSS),
- Cross-Site Request Forgery (CSRF or XSRF),
- SQL Injections (SQLi),
- File Inclusions (LFI or RFI),
- Authentication or Authorization flaws,
- Remote Code Execution (RCE),
- Open Redirections,
- Privilege Escalation,
- Web Cache Poisoning.
Out of concern for the availability of our services to all users, please do not attempt to carry out DoS attacks, it’s totally out of the scope and not constructive at all. We also discourage the use of any vulnerability testing tools that automatically generate very significant volumes of traffic, using automated tests will automatically disqualify you from all bug bounties.
Non-qualifying vulnerabilities
- Do-it-yourself XSS: If an attacker can convince someone to manually paste JavaScript code into firebug, there is nothing that a web application could do to prevent the attack.
- Full Path Disclosure: This is not enough to hack something but thank you anyway.
- XSRF bugs with no practical use to attackers: If a particular request does not change the state of anything in any way, or if the change is very inconsequential, the report may not qualify for a reward.
- XSRF that requires the knowledge of a secret: If you know the secret, you know the token, so it’s now a flaw anymore. This behavior is a common cause of false-positive reports by some automated vulnerability scanners, please don’t use them.
- Bugs requiring exceedingly unlikely user interaction: For example, a cross-site scripting flaw that requires the victim to manually type in an XSS payload into the page and then double-click an error message may realistically not being qualifying.
- Vulnerabilities requiring physical access to the victim’s unlocked device: Of course not.
- Denial of Service Vulnerabilities (DoS): Please don’t.
- Brute force attacks (e.g. on passwords or tokens): Just don’t
- Spam or Social Engineering techniques: We only focus on technical issues.
- Missing security headers that do not lead directly to a vulnerability: Obviously
- WordPress Core and WordPress plugins: If your bug is related to the WordPress Core, please send an email to security@wordpress.org, if it’s related to a plugin present in the repository, please send an email to plugins@wordpress.org. The only case that we should consider a bug is in our own made plugins, this is qualifying.
- Bugs in recent acquisitions: To allow time for internal review and remediation, newly acquired companies are subject to a 3 months blackout period. Bugs reported sooner than that will typically not qualify for a reward.
- Presence of version information/footprint: Version information or footprint doesn’t, by itself, expose the plugin or site to attacks – so we do not consider this to be a bug. That said, if you find outdated software and have good reasons to suspect that it poses a well-defined security risk, please let us know.
- Non-updated website element or 3rd party library: Even if it’s dangerous, it’s not about our devs. Thank you for the alert but this not deserve a bounty.
We believe in recognizing the work of others. Monetary rewards aside, if your work helps us improve the security of our service, we’d be happy to acknowledge your contribution at the bottom of this page.
Reward amounts
Any rewards that are unclaimed after 2 months will be canceled.
The final amount is always chosen at the discretion of the following reward scale. In particular, we may decide to pay higher rewards for unusually clever or severe vulnerabilities; decide to pay lower rewards for vulnerabilities that require unusual user interaction; decide that a single report actually constitutes multiple bugs; or that multiple reports are so closely related that they only warrant a single reward.
Rewards for qualifying bugs range from USD$50 to USD$200. We relate on a DREAD score model to select a proper reward.
DREAD Score › Reward
- Very Low (≤ 1) › $0
- Low (≤ 2) › $50
- Serious (≤ 3) › $75
- High (≤ 4) › $100
- Very High (≤ 5) › $150
Investigating and reporting bugs
We are only able to answer to technical vulnerability reports. Non-security bugs and queries about problems with your account should be instead directed to our support.
When investigating a vulnerability, please, only ever target your own accounts and websites. Never attempt to access anyone else’s data and do not engage in any activity that would be disruptive or damaging our fellow users or server. Also it’s against the law to access to anyone else data without permission, we do not permit that even for testing purposes.
Please be succinct: A short proof-of-concept link or a short a video to explain the consequences of a bug.
Disclosure Process
The contents of the Bug Report will be made available to the Security Team immediately, and will initially remain non-public to allow the Team sufficient time to publish a remediation. Public disclosure of the Bug Report may be requested by either the Researcher or the Security Team.
- Mutual agreement: We encourage both of us to remain in open communication regarding disclosure timelines. If we are in agreement, the contents of the Bug Report can be made public on a mutually agreed timeline.
- Protective disclosure: If we has evidence of active exploitation or imminent public harm, we may immediately provide remediation details to the public so that users can take protective action.
- Extension: Due to complexity and other factors, some vulnerabilities may require longer than the default 30 days to remediate. In these unusual cases, the Bug Report may remain non-public to ensure the Security Team has an adequate amount of time to address a security issue.
- Last resort: If 180 days have elapsed with us, being unable or unwilling to provide a disclosure timeline, the contents of the Bug Report may be publicly disclosed by you. We believe transparency is in the public’s best interest in these extreme cases.
Reports must include the following
- A Proof of Concept
- Detailed steps on how to reproduce the vulnerability
- Explanation of how the attack could be executed in a real world scenario to compromise user accounts or data
- Eligibility and Responsible Disclosure
Not giving us a reasonable time to respond to your report before making any information public and make a good faith effort to avoid privacy violations, destruction of data and interruption or degradation of our service during your research will automatically disqualify you from all bug bounties.
Also you have to adhere to these Disclosure Guidelines and our Responsible Disclosure Policy (above)
- Respect privacy. Make a good faith effort not to access or destroy another user’s data.
- Be patient. Make a good faith effort to clarify and support their research upon request.
- Do no harm. Act for the common good through the prompt reporting of all discovered vulnerabilities. Never willfully exploit others without their permission.
- All researchers agree to wait a minimum of 48 hours after fix release before doing any disclosure of any type of vulnerability.
- All researchers agree to wait 96 hours after fix release before doing any disclosure for High and Very High vulnerabilities.
- You must be the first person to report the issue to us. If a duplicate reproduction is submitted while the vulnerability is still in the wild, we will only award a bounty if the duplicate submissions provide more information or show the hole to be more extensive.
- Communicate with our security team exclusively in private using support@secupress.me, we will be way more impressed by your exploits in private than on social media.
- Be in a country where we can legally pay you using paypal, and edit an invoice for us.
Bounty Payments
Bounty payments are subject to the following eligibility requirements:
- Minors are welcome to participate in the program. However, the Children’s Online Privacy Protection Act restricts our ability to collect personal information from children under 13, so you will need to claim your bounties through your parent or legal guardian if you are 12 or younger.
- All payments will be made in U.S. dollars (USD) and will comply with local laws, regulations and ethics rules. You are responsible for the tax consequences of any bounty you receive, as determined by the laws of your country.
- It is your sole responsibility to comply with any policies your employer may have that would affect your eligibility to participate in this bounty program.
I already thank you in advance for your researches, keep in mind that the website won’t reward.