raidboxes.io
External Program
Submit bugs directly to this organization
External Program
Submit bugs directly to this organization
At Raidboxes, security is not only a buzzword, we take it seriously. We are highly committed to upholding a very high security standard. This includes the securing of our corporate systems and the protection of data entrusted to us by our clients and partners.
[#vuln-reporting](Report A Vulnerability)
At Raidboxes, security is not only a buzzword, we take it seriously. We are highly committed to upholding a very high security standard. This includes the securing of our corporate systems and the protection of data entrusted to us by our clients and partners.
We genuinely believe that:
A) Despite our best efforts to code securely, our software and applications will have bugs.
B) Security researchers are increasingly important when hunting down vulnerabilities.
We encourage everyone to contact us to report potential vulnerabilities in our systems.
This policy provides guidelines for security researchers and members of the public on how to report vulnerabilities within our systems. It also outlines [#vuln-scope](what systems and types of research) are covered under this policy, [#vuln-reporting](how to send us) vulnerability reports, and **[#vuln-lifeflow](how the work- and lifeflow) **of a submission to us looks like.
[#vuln-reporting](Report A Vulnerability)
When conducting vulnerability research according to this policy, we consider this research to be:
**Authorized in accordance with the Computer Fraud and Abuse Act (CFAA) **(and/or similar state laws), and we will not initiate or support legal action against you for accidental, good faith violations of this policy.
Exempt from the Digital Millennium Copyright Act (DMCA), and we will not bring a claim against you for circumvention of technology controls.
Exempt from restrictions in our [https://raidboxes.io/en/legal/terms/](Terms & Conditions) that would interfere with conducting security research, and we waive those restrictions on a limited basis for work done under this policy.
Lawful, helpful to the overall security of the Internet, and conducted in good faith.
You are expected, as always, to comply with all applicable laws.
In addition, when conducting vulnerability research under this policy, and specifically for Germany and the European Union, we consider this research to be:
Exemption from §202a, §202b, §202c StGB (German Criminal Code) We will not initiate or support criminal complaints under §202a, §202b, §202c of the German Criminal Code („StGB“) for good faith security research conducted in line with this policy.
Exemption from EU Directive 2013/40/EU Research conducted in accordance with this policy is considered authorized and will not be treated as an offense under the EU Directive 2013/40/EU on attacks against information systems, as long as it is carried out in good faith and within the scope of this policy.
Coordinated Vulnerability Disclosure (CVD) This policy aligns with the principles of Coordinated Vulnerability Disclosure (CVD) as recommended by the German Federal Office for Information Security (BSI) and ENISA (European Union Agency for Cybersecurity).
Aligned with GDPR requirements for personal data handling If, during your security research, you encounter personal data (as defined under the General Data Protection Regulation – GDPR), you must cease testing immediately and report this to us without delay via [email protected]). You are not authorized to access, store, process, or share any personal data, and we reserve the right to handle such incidents in accordance with Articles 33 and 34 GDPR.
If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please inquire via mailto:[email protected] before going any further.
Target | Description | https://dashboard.raidboxes.de | Our main customer facing control panel for managing WordPress instances. | https://.raidboxes.io | Our marketing websites like [https://raidboxes.io](this one) or our https://blog.raidboxes.io. | https://.raidboxes.net | We run many services for our infrastructure on the .net TLD. | http://.raidboxes. | All top level domains that redirect to https://raidboxes.io/. Some we may not own, so unless they redirect to our .io TLD, consider it not ours. |
We use third-party providers and services – including a number hosted on subdomains across our brand that will be considered Out of Scope for this program. We cannot authorize security testing against systems that do not belong to us, however we would encourage you to report any issues identified within these services to the third-party directly.
However, if you believe an issue with one of our third-party service providers is the result of Raidboxes' misconfiguration or insecure usage of that service, we would appreciate it greatly if you could share your finding.
Boxes (WordPress instances) that are **not **your own or have not been **created **by you.
WordPress Plugins and Themes that are not maintained by Raidboxes. For example if a Plugin „XYZ“ has a vulnerability but is neither developed nor maintained by us, report it to the developer of „XYZ“ directly, **not **to us. We run many instances for our customers and can not be held responsible for them having unsafe tools installed.
Accessible non-sensitive files and directories (for example: README.TXT, CHANGES.TXT, robots.txt, gitignore, etc.).
Issues only available in self-exploitation scenarios (e.g. self XSS or pasting JavaScript into the browser console).
Email spoofing (including lack of SPF, DMARC, DKIM, From: spoofing, and visually similar and related issues).
Descriptive error messages (for example: stack traces, application or server errors, path disclosure).
Clickjacking and issues only exploitable through clickjacking. Also CSRF issues that don’t impact the integrity of an account (for example: login or out, contact forms and other publicly accessible forms).
Lack of Secure and HTTPOnly cookie flags.
Missing HTTP security headers.
CORS misconfiguration on non-sensitive endpoints.
TLS/SSL Issues, including BEAST, BREACH, insecure renegotiation, bad cipher suite, expired certificates.
Out-of-date software / Software version disclosure.
Previously reported vulnerabilities are not eligible for an Hall Of Fame entry.
For our customer’s protection, we need to make sure that any reporting is done responsibly. We believe that your intentions are of good intent and that you want to make the web and our services are more secure place for you and our customers. We thank for for that. We accept reports in all languages, but English is preferred. We do need to ensure some general guidelines for compliance and legal reasons, so please be sure to follow the following guidelines.
Do not compromise the privacy or safety of our customers.
Do not interrupt or degrade our services. Volumetric attacks of any kind (D/DoS, Brute-forcing etc. are not permitted) However** **we are interested in denial of service issues **at the application layer **(logic bombs, ReDoS, etc.).
Do not initiate fraudulent transactions.
Do not modify or access data that doesn’t belong to you.
We are looking for technical vulnerabilities, not human errors, so anything remotely related to phishing or any form social engineering is not in scope.
Reports from automated tools or scans that haven’t been manually validated aka: Don’t just send us scans and say stuff is vulnerable because the version we use is vulnerable. We need a proof of concept that you are able to exploit it. We patch a lot
Once you’ve established that a vulnerability exists or encounter any sensitive data (including personally identifiable information, financial information, or proprietary information or trade secrets of any party), you must stop your test, notify us immediately, and not disclose this data to anyone else.
Provide enough detail to reproduce and validate the vulnerability, including targets, steps, tools, and artifacts.
Allow a reasonable amount of time for us to address the vulnerability before requesting an update or taking further action.
In order to help us triage and prioritize submissions, we recommend that your reports:
Describe the location the vulnerability was discovered and the potential impact of exploitation.
Offer a detailed description of the steps needed to reproduce the vulnerability (proof of concept scripts, videos or screenshots are very helpful).
Patience. We are all humans with many tasks and responsibilities across multiple areas of our work. We will do the very best we can to keep you updated on the progress of your report, please be reasonable when asking about an update.
When you choose to share your contact information with us, we commit to coordinating with you as openly and as quickly as possible.
Within 5 business days (Mo-Fr), we will acknowledge that your report has been received.
To the best of our ability, we will confirm the existence of the vulnerability to you and be as transparent as possible about what steps we are taking during the remediation process, including on issues or challenges that may delay resolution.
Work to remediate discovered vulnerabilities in an efficient and timely manner, within 90 days if possible.
We will maintain an open dialogue to discuss issues.
You can report a vulnerability via our partner platform. Please follow the steps outlined below. Please keep in mind that we do not accept reports which are directly reported to us, do not email us reports directly. Only use our partner for this.
Click the button below.
Create an account with our partner platform (You can use fake data if you like to keep your privacy).
Once registered, you will have access to a reporting form.
Submit the report through that form or use the button below to access it.
[https://app.intigriti.com/programs/raidboxes/raidboxesresponsibledisclosure/detail](Report A Vulnerability)
We cannot pay you **any **monetary reward for finding potential or confirmed vulnerabilities. However, we will credit you as the person who discovered the vulnerability, if you wish for it.
Those who have discovered the vulnerability will have their name or alias listed below in the Hall Of Fame section below.
Please see the infographic below to get an idea about how a vulnerability report is handled on our end.
Find here the legendary folks who reported vulnerabilities to us:
Name/Handle | Daniel Hoffmann/doCrp0x | | Vulnerability & Date | Insecure Direct Object Reference On Box Settings | 21.12.2022 | Public report (Disclosure) | None | | Website | None provided | | Social Media | None provided | |
Name/Handle | sws_jk | | Vulnerability & Date | Stored XSS in Dashboard | 02.02.2023 | Public report (Disclosure) | None | | Website | None provided | | Social Media | None provided | |
Name/Handle | Chapuka | | Vulnerability & Date | Privilege Escalation to root | 08.02.2023 | Public report (Disclosure) | None | | Website | None provided | | Social Media | None provided | |
Name/Handle | Chapuka | | Vulnerability & Date | Insecure Direct Object References via JSON-RPC | 08.02.2023 | Public report (Disclosure) | None | | Website | None provided | | Social Media | None provided | |
Name/Handle | arthbajpai277 | | Vulnerability & Date | Broken Access Control on User Dashboard | 08.08.2023 | Public report (Disclosure) | None | | Website | None provided | | Social Media | None provided | |
Name/Handle | mert | | Vulnerability & Date | Improper Authorization Dashboard | 30.01.2023 | Public report (Disclosure) | None | | Website | None provided | | Social Media | None provided | |