Vulnerability Disclosure and Security Research Policy

1. Purpose and Scope

This Vulnerability Disclosure and Security Research Policy provides a clear process for good-faith security researchers to report suspected vulnerabilities affecting Spark Rack systems while protecting Customers, data, personnel, and network stability.

This Policy is not a public bug-bounty offer and does not authorize unlimited testing.

Research is authorized only to the extent expressly described in this Policy and applicable scope information.

2. Good-Faith Research

Good-faith research is activity intended to identify and report a security weakness without causing harm, obtaining unnecessary data, disrupting Services, violating privacy, extorting payment, or exploiting the weakness beyond what is reasonably necessary to demonstrate it.

A researcher must stop testing and report promptly if the researcher encounters Customer Data, credentials, private communications, financial information, regulated data, or the ability to materially affect another person.

3. Authorized Scope

Unless Spark Rack publishes a more specific scope, authorized testing is limited to publicly accessible systems and applications directly operated by Spark Rack under the Spark Rack brand.

A researcher must verify ownership before testing. The presence of a Spark Rack IP address, certificate, DNS record, or hosting relationship does not prove that Spark Rack owns or authorizes testing of the Customer application.

Customer websites, Customer servers, Customer applications, reseller systems, third-party systems, data-center systems, payment systems, registrar systems, and vendor platforms are out of scope unless expressly listed in writing.

4. Out-of-Scope Systems

1. Customer Content and Customer-controlled applications;
2. Customer virtual machines and dedicated servers;
3. Third-party payment processors;
4. Domain registrars and registries;
5. Data centers and upstream carriers;
6. Third-party authentication providers;
7. Third-party support, monitoring, analytics, or software platforms;
8. Employee personal accounts or devices;
9. Physical facilities;
10. Social media accounts;
11. Telephone systems;
12. Email accounts not expressly designated for testing;
13. Production data not created by the researcher; and
14. Any system whose ownership or authorization is uncertain.

A researcher who discovers a weakness in an out-of-scope Customer system should report it through the Abuse Reporting Policy without further testing.

5. Permitted Testing

Within authorized scope, a researcher may perform limited, non-disruptive testing reasonably necessary to confirm a vulnerability, such as:

1. Manual review of public application behavior;
2. Low-rate requests using a researcher-controlled Account;
3. Testing authorization boundaries using only researcher-created data;
4. Testing input validation without executing destructive payloads;
5. Reviewing public headers, certificates, DNS, and exposed metadata;
6. Demonstrating access to a minimal harmless test record created by the researcher;
7. Using proof-of-concept code that does not persist, spread, or damage systems; and
8. Collecting the minimum evidence needed to explain the vulnerability.

6. Prohibited Testing

The following activities are not authorized:

1. Denial-of-service, distributed denial-of-service, stress, volumetric, or resource-exhaustion testing;
2. High-volume automated scanning that may degrade Services;
3. Social engineering, phishing, pretexting, or impersonation;
4. Physical intrusion, tailgating, surveillance, or facility testing;
5. Testing employees’ personal devices or accounts;
6. Password spraying, credential stuffing, brute force, or attempts using leaked credentials;
7. Accessing, modifying, deleting, downloading, or retaining another person’s data;
8. Changing another user’s password, email, multifactor settings, permissions, or billing information;
9. Sending spam, malware, ransomware, or malicious files;
10. Establishing persistence, command-and-control, backdoors, scheduled tasks, or new privileged accounts;
11. Exfiltrating secrets or credentials beyond the minimum redacted proof;
12. Pivoting to another system;
13. Testing third-party or Customer systems;
14. Disclosing a vulnerability publicly before coordinated remediation;
15. Demanding payment or threatening disclosure;
16. Violating law, privacy, or contractual rights; and
17. Any activity likely to create operational, financial, legal, or safety harm.

7. Automated Scanning

Low-rate automated scanning may be permitted only when it remains within authorized scope, does not evade controls, does not generate excessive traffic, and does not test Customer systems.

Spark Rack may block or rate limit scanners without notice. Blocking does not confirm or deny the existence of a vulnerability.

8. Use of Accounts

Testing should use an Account owned and controlled by the researcher and created with accurate information.

The researcher must not use stolen, shared, compromised, or another person’s credentials.

Charges incurred through a research Account remain the researcher’s responsibility unless Spark Rack expressly agrees otherwise.

9. Handling Sensitive Data

If testing unexpectedly exposes sensitive or Customer information, the researcher must:

1. Stop access immediately;
2. Avoid opening additional records;
3. Avoid copying or downloading content;
4. Avoid changing or deleting data;
5. Record only the minimum metadata necessary to identify the issue;
6. Securely report the exposure;
7. Delete any inadvertently retained information after Spark Rack confirms receipt, unless preservation is legally required; and
8. Follow Spark Rack’s reasonable instructions for secure handling.

10. Report Contents

A vulnerability report should include:

1. The researcher’s name or chosen identifier and reliable contact method;
2. The affected hostname, URL, IP address, application, and feature;
3. The vulnerability type and likely impact;
4. Detailed reproduction steps;
5. The date and time of testing;
6. The Account used, if applicable;
7. Sanitized request and response examples;
8. Screenshots or proof-of-concept code where useful;
9. The minimum data accessed;
10. Whether testing has stopped;
11. Suggested remediation where known; and
12. Any planned disclosure timeline.

Reports should not include unnecessary Personal Information, full credentials, large data exports, malware, or unredacted Customer Content.

11. Reporting Channel

Reports should be submitted through the published Spark Rack security or vulnerability-reporting channel.

A report sent to general support may be rerouted but could be delayed.

For highly sensitive findings, the researcher may request a secure transfer method before sending full technical details.

12. What Spark Rack Will Attempt to Do

For a sufficiently detailed good-faith report within scope, Spark Rack will attempt to:

1. Acknowledge receipt;
2. Assign the report for review;
3. Request clarification where needed;
4. Assess scope and severity;
5. Contain urgent risk;
6. Coordinate with affected providers or Customers when necessary;
7. Develop or request remediation;
8. Communicate material status changes when practical;
9. Confirm when the issue is resolved or otherwise closed; and
10. Discuss coordinated disclosure where appropriate.

These are good-faith process goals, not guaranteed response or remediation times.

13. Researcher Communication

The researcher should remain available for reasonable questions and should promptly disclose new evidence, accidental data access, expanded impact, or public exploitation.

Duplicate reports may be closed or consolidated. Spark Rack may be unable to provide detailed status because of security, privacy, legal, Customer, or provider restrictions.

14. Safe-Harbor Statement

When a researcher makes a good-faith effort to comply with this Policy, limits testing to authorized scope, avoids harm, and promptly reports the issue, Spark Rack will not initiate legal action solely because of that authorized research.

If Spark Rack concludes that activity was accidental and undertaken in good faith, Spark Rack will attempt to clarify the concern before pursuing legal action where appropriate.

This safe-harbor statement does not bind third parties, law enforcement, Customers, registrars, data centers, software vendors, or other rights holders, and it does not authorize violation of their terms or systems.

15. No Immunity for Harmful Conduct

Safe harbor does not apply to extortion, data theft, privacy invasion, disruption, persistence, credential abuse, public exploitation, Customer-system testing, physical intrusion, social engineering, or conduct outside this Policy.

Spark Rack may preserve evidence, block access, suspend Accounts, notify affected parties, or refer harmful activity to authorities.

16. Coordinated Disclosure

A researcher should allow Spark Rack a reasonable opportunity to investigate and remediate before public disclosure.

Disclosure timing depends on severity, exploitability, vendor dependencies, testing, Customer impact, legal obligations, and active exploitation.

The parties may agree on a disclosure date, advisory wording, credit, or temporary delay. Spark Rack does not require indefinite silence but may request delay when disclosure would materially increase risk.

17. Public Disclosure Without Coordination

Publicly disclosing exploit details, sensitive data, credentials, or an unremediated vulnerability before reasonable coordination may fall outside safe harbor and may harm Customers.

Spark Rack may take protective and legal action when disclosure is reckless, extortionate, knowingly harmful, or violates law.

18. Recognition and Bounties

This Policy does not create a bug-bounty program or promise payment.

Spark Rack may choose to provide acknowledgment, thanks, credit, merchandise, or a discretionary reward, but no reward is owed unless Spark Rack expressly agrees in writing before or after review.

A researcher must not condition nondisclosure or deletion of data on payment.

19. Duplicate, Known, and Low-Impact Reports

Spark Rack may close a report that is duplicate, already known, not reproducible, out of scope, informational, dependent on unsupported software, based on intended behavior, or lacking meaningful security impact.

Examples often considered low impact include missing cosmetic headers without a demonstrated exploit, version information without vulnerability, self-XSS requiring the victim to paste code, or rate-limit observations without abuse impact. Each report is reviewed on its facts.

20. Third-Party Vulnerabilities

When a report concerns third-party software or infrastructure, Spark Rack may coordinate with the vendor, apply mitigation, restrict a feature, or refer the researcher to the vendor.

Spark Rack does not control third-party remediation timelines and may be unable to disclose vendor communications.

21. Customer Vulnerabilities

A vulnerability in a Customer-controlled website, server, or application is not authorized testing under this Policy.

The researcher should stop testing and report the issue through the Abuse Reporting Policy with minimal evidence.

Spark Rack may forward the report to Customer but does not guarantee remediation or researcher communication.

22. Privacy and Retention

Spark Rack may retain vulnerability reports, researcher contact information, technical evidence, and remediation records for security, legal, fraud-prevention, and operational purposes.

Spark Rack does not sell report information or use it for AI or model training.

23. No Warranty or Researcher Relationship

Participation does not create employment, agency, partnership, contractor status, confidentiality agreement, compensation right, support entitlement, or continuing relationship.

Testing is performed at the researcher’s own risk and expense.

24. Contact

Reports should use the published security-reporting channel. Written correspondence may be mailed to:

Spark Rack
Attn: Vulnerability Disclosure and Security Research
PO Box 2215
Valdosta, GA 31604
United States

25. Acknowledgment

By conducting authorized research, the researcher acknowledges that:

1. Only systems directly operated by Spark Rack and expressly within scope may be tested.
2. Customer and third-party systems are out of scope.
3. Denial-of-service, social engineering, credential attacks, data access, persistence, and destructive testing are prohibited.
4. Testing must stop when sensitive data or material risk is encountered.
5. Reports must be made promptly and in sufficient detail.
6. This Policy is not a bug-bounty promise.
7. Safe harbor applies only to good-faith activity within this Policy and does not bind third parties.
8. Public disclosure should be coordinated to reduce harm.