Vulnerability Disclosure Policy

Effective Date: 16 April 2026 Last Updated: 16 April 2026

1. Introduction

RedSwitches Pte Ltd. (“RedSwitches,” “we,” “us,” or “our”) takes the security of our infrastructure, platforms, and client-facing services seriously. We recognise that security researchers and the broader security community play an important role in identifying vulnerabilities, and we welcome good-faith reports of security issues.

This Vulnerability Disclosure Policy (“Policy”) sets out how to report a vulnerability you have discovered, what to expect from us after you do, and the protections available to researchers who engage with us responsibly.

2. Scope

2.1 In Scope

The following systems and services are within scope for vulnerability research and disclosure under this Policy:

• RedSwitches core network infrastructure, including routing, switching, and network management systems operated by RedSwitches
• redswitches.com, our public-facing website and all subdomains (e.g., my.redswitches.com, api.redswitches.com)
• Client portal, the web-based management interface used by clients to access and manage their services
• RedSwitches APIs, public and authenticated API endpoints used to provision and manage services
• Management interfaces, any RedSwitches-operated management plane systems (e.g., IPMI/iDRAC management network as operated by RedSwitches)

2.2 Not In Scope

The following are outside the scope of this Policy and should not be tested:

• Client servers and client-managed applications, RedSwitches provides bare-metal hardware and network connectivity; the operating system, applications, and data on client servers are under the exclusive control of the client. We are not responsible for and cannot remediate vulnerabilities in client-managed software or configurations.
• Third-party services and platforms that RedSwitches does not own or operate (even if accessible from our network)
• Vulnerabilities in third-party software used by RedSwitches that have already been publicly disclosed and are pending upstream patches

If you believe you have found a vulnerability in a client’s server or application, please contact that client directly. We cannot process or act on reports about client-managed systems.

3. How to Report

To report a vulnerability, please email us at:

security@redswitches.com

Please include the following information in your report to help us triage and respond efficiently:

1. Description, A clear description of the vulnerability, including the type of vulnerability (e.g., SQL injection, authentication bypass, exposed credentials)
2. Affected system, The specific URL, API endpoint, IP address, or system component affected
3. Reproduction steps, Step-by-step instructions to reproduce the vulnerability reliably
4. Impact assessment, Your assessment of the potential impact, including what data or systems could be affected and how
5. Evidence, Screenshots, HTTP request/response captures, proof-of-concept code, or other supporting material (please do not include actual sensitive data extracted from our systems)
6. Your contact details, So we can follow up and credit you if you wish (optional if you prefer to remain anonymous)

You may submit reports in English. We cannot guarantee timely responses to reports submitted in other languages.

Encrypted communications are welcome. Please email security@redswitches.com to request our PGP public key if you wish to submit a report via encrypted email.

4. Safe Harbor

RedSwitches commits to the following for researchers who discover and disclose vulnerabilities in good faith and in accordance with this Policy:

• No legal action, We will not initiate or support legal action against you under computer crime statutes, intellectual property law, or any other applicable law as a result of your security research
• No punitive response, We will not terminate your service or take other adverse action against you as a result of a good-faith vulnerability report
• Good faith interpretation, We will evaluate your research charitably, recognising that security testing may involve interactions with systems that would otherwise be unauthorized

“Good faith” means that your research:

• Is conducted within the scope defined in Section 2
• Does not violate the Rules of Engagement in Section 7
• Is reported to us privately before any public disclosure
• Is intended to identify and help fix security vulnerabilities, not to exploit, exfiltrate, or profit from them

This safe harbor does not extend to activities that fall outside the scope of this Policy, violations of the Rules of Engagement, or activities that are independently unlawful for reasons unrelated to security research.

5. Response Timeline

We are committed to processing vulnerability reports promptly. Our target response timelines are:

For critical vulnerabilities (those that pose an immediate risk to client data or service integrity), we prioritize resolution and may communicate more frequently.

We ask that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to remediate it. We will work collaboratively with you to agree on a disclosure timeline. If circumstances prevent us from meeting an agreed timeline, we will communicate proactively and explain the situation.

6. Recognition

We appreciate the effort that goes into responsible security research. If you report a valid, in-scope vulnerability:

• We will credit you by name (or your chosen alias) in any public acknowledgement of the finding, if you consent to being credited
• We may list acknowledged researchers on a security acknowledgements page on our website at our discretion

RedSwitches does not operate a formal paid bug bounty program at this time. We are grateful for the security community’s contributions and we review this position periodically as our program matures.

7. Rules of Engagement

To protect our clients, our operations, and the integrity of the research process, all security research must comply with the following rules:

7.1 Data Handling

• No data exfiltration, Do not copy, extract, download, or retain any data from our systems beyond what is minimally necessary to demonstrate the vulnerability
• No data modification or destruction, Do not alter, delete, encrypt, or corrupt any data or configuration
• No accessing other users’ data, If your research leads you to a point where you could access another client’s data, stop immediately and report the access vector without proceeding further
• Report and delete, If you inadvertently access sensitive data during your research, notify us immediately and delete it from your systems

7.2 Service Integrity

• No disruption, Do not conduct denial of service (DoS) attacks, brute-force login attempts, or any activity that degrades or disrupts service for RedSwitches or our clients
• No DDoS, Do not flood our systems with traffic or requests
• Test only your own accounts, All testing must be conducted against accounts and services you own or have explicit permission to test. Do not target services belonging to other RedSwitches clients

7.3 People and Process

• No social engineering, Do not attempt to manipulate, deceive, or coerce RedSwitches staff or contractors to obtain access or information
• No physical attacks, Physical access attempts to data centers or offices are out of scope and prohibited

7.4 Disclosure

• Private reporting only, Report vulnerabilities to us at security@redswitches.com before any public disclosure
• No public disclosure before remediation, Do not post, publish, or otherwise share details of a vulnerability until we have confirmed it is remediated or we have mutually agreed on a coordinated disclosure timeline

8. Out of Scope

The following are not eligible for recognition or safe harbor protection under this Policy:

• Vulnerabilities in client-managed servers or applications (see Section 2.2)
• Publicly known, already-disclosed vulnerabilities (including unpatched CVEs in third-party software) with no novel exploitation vector specific to RedSwitches
• Social engineering attacks (phishing, vishing, pretexting) against RedSwitches employees or contractors
• Physical security testing (attempting to gain physical access to data centers or offices)
• Denial of service (DoS/DDoS) attacks or rate-limiting tests
• Spam or email deliverability issues
• Reports based solely on automated scanner output without manual verification and a demonstrated exploitability path
• Theoretical vulnerabilities with no demonstrated practical impact

9. Modifications

RedSwitches reserves the right to update this Policy at any time. Material changes will be reflected by updating the “Last Updated” date at the top of this document. If we make significant changes to the scope or safe harbor provisions, we will post a notice on our website. The current version of this Policy is always available at redswitches.com.

10. Contact

Security reports: security@redswitches.com Subject line: “Vulnerability Report, [Brief Description]”

For general security questions that do not involve an active vulnerability report, you may also reach us at the same address.

We look forward to working with the security community to keep RedSwitches and our clients safe.