Responsible disclosure for DediStart services.
This policy explains how to report a vulnerability, what testing is out of scope, and what information helps the team review a report quickly.
The goal is safe and responsible disclosure. Any reward decision remains optional, depends on internal validation, and is reserved for qualifying reports.
Overview
No production system is perfect, and security review from experienced researchers can be valuable when it is carried out responsibly. If you believe you have identified a vulnerability affecting a DediStart product, service, or website, report it through the published channel below.
The program is centered on responsible disclosure, not public competition. Qualifying reports may be considered for a discretionary reward after internal validation, severity review, and duplicate checking.
Safe reporting expectations
- Report the issue as soon as reasonably possible after discovery and provide enough detail for the team to reproduce the finding.
- Allow a reasonable amount of time for investigation and remediation before disclosing the issue publicly or to a third party.
- Do not use impersonation, social engineering, phishing, or other deceptive contact methods during testing or reporting.
- Use only accounts you created yourself and do not access, modify, or destroy data belonging to other users.
- Avoid testing methods that disrupt availability, degrade service for others, or create unnecessary operational risk.
- Keep the report confidential while the issue is under review. Personal information provided with the report will not be shared without consent unless disclosure is required by law.
- If you follow these expectations and the other conditions in this policy, Redcluster LTD does not intend to pursue legal action in relation to the report itself.
Eligibility
A report may be considered for review under this program when all of the following are true:
- You are the first reporter of the issue.
- You follow the safe-reporting expectations described in this policy.
- You do not publicly disclose the issue before Redcluster LTD has had a reasonable opportunity to investigate and respond.
- You provide a clear explanation of impact together with reproducible steps or a working proof of concept.
- You use only your own accounts and do not attempt to access data that does not belong to you.
- You are not located in, or otherwise subject to, sanctions restrictions that would prevent Redcluster LTD from engaging in the program.
Out-of-scope findings
The categories below are generally out of scope and may not receive an individual response when they do not demonstrate a meaningful, exploitable security impact.
Social and physical attacks
- Social engineering, phishing, impersonation, or other attempts to manipulate staff or third parties.
- Any physical attempt against company property, infrastructure, or data-center facilities.
Availability and abusive testing
- Denial-of-service activity, brute forcing, stress testing, or any testing that could degrade service availability.
- Reports generated only by automated tools or broad scanning without a demonstrated, service-specific impact.
- Missing rate limits reported without a practical exploit path.
Low-signal web findings
- CSRF, self-XSS, clickjacking-only issues, content spoofing on error pages, homograph attacks, open redirects, weak CAPTCHA observations, and cache-related issues.
Headers, configuration, and exposure-only reports
- Missing cookie flags, missing security headers without demonstrated impact, missing
noreferrerornoopener, DKIM/SPF/DMARC observations, version exposure, directory listing, SSL observations, OPTIONS enabled, or server IP disclosure.
Account and local-device edge cases
- Authentication session timeouts, 2FA TOTP reuse, password-policy concerns, email-change verification details, 2FA activation flow observations, or issues that require access to the user's own device.
- User-enumeration claims that depend on brute-force behavior instead of a practical application weakness.
Third-party software and external systems
- Bugs in third-party software, WordPress vulnerabilities, browser vulnerabilities, or payment-processor parameter tampering outside the direct DediStart application surface.
What to include in a report
A useful report usually includes:
- The affected hostname, URL, service, or user flow.
- Clear reproduction steps, including required account state, timing, or environment details.
- The observed impact and the security consequence you believe follows from the issue.
- A proof of concept, screenshots, request samples, or logs that help the team validate the report without repeating excessive testing.
- Your preferred contact details in case follow-up clarification is needed.
Reporting channel
Send initial findings to the abuse and security channel below. If the issue is accepted for review, follow-up communication can continue through that thread.
Use the contact page for non-security operational questions.