Vulnerability Disclosure Policy

Cloudarq operates a security platform — keeping it secure is the whole point. We welcome reports from independent researchers and treat coordinated disclosure as a partnership. This page describes how to report a vulnerability and what we'll do with it.

For all security correspondence, email [email protected]. A PGP key for that address is available on request — reply to your initial email and we'll send it.

1. Scope

1.1 In scope

• The cloudarq.net domain and all subdomains (e.g. www.cloudarq.net)
• The CloudArq REST API (paths under /api/v1/)
• The web application and all customer-facing pages
• Email-template behaviour (e.g. RFC 8058 List-Unsubscribe one-click flow)
• Authentication, authorization, and session-management flows

1.2 Out of scope

• Third-party services we use as sub-processors (Hetzner, Cloudflare, Paddle, Anthropic, Resend, Sentry, Plausible). Report those directly to the relevant vendor — see /legal/subprocessors for contacts.
• Any AWS environment that belongs to a CloudArq customer. Do not attempt to reach a customer's AWS account through CloudArq — that's the multi-tenant boundary, not our infrastructure.
• Denial-of-service attacks, traffic amplification, or any test that meaningfully degrades service for other users.
• Social-engineering attempts against CloudArq employees or contractors.
• Spam, phishing, or content-policy concerns (those go to [email protected] but aren't security vulnerabilities).
• Automated scanner output without manual verification — we'll treat raw scanner reports as low-priority noise unless they include a working proof of concept.
• Issues already publicly disclosed — please check our changelog before reporting.

2. Safe harbor

We won't pursue legal action — civil or criminal — against researchers who:

• Make a good-faith effort to comply with this policy.
• Avoid privacy violations, destruction of data, and interruption or degradation of service.
• Do not access, modify, or delete data belonging to other customers. If a vulnerability gives you access to another customer's data, stop, document the proof of concept against your own test data only, and report.
• Give us a reasonable opportunity to investigate and remediate the issue before disclosing publicly (see Section 4).
• Do not run automated scanners that overwhelm our infrastructure. Rate limits exist for a reason; respect them.

If you make a good-faith effort to follow this policy and an accidental violation occurs (e.g. you happened to see another tenant's data while exploring an authorization bug), report it immediately and stop. We'll work with you, not against you.

3. Reporting

Send your report to [email protected]. Use PGP for sensitive details (key on request). A useful report includes:

• A clear summary of the vulnerability.
• Reproduction steps. A working proof of concept against test data is best.
• Your impact assessment — what an attacker could do with it.
• Any relevant request/response captures, with credentials redacted.
• Suggested remediation, if you have one.

Don't include real customer data in your report. If a PoC incidentally captured a third party's data, redact it before sending.

4. Our response timeline

• Acknowledgment — within 48 hours of receipt (business days).
• Triage decision — within 7 days. We'll classify the severity and tell you our planned remediation window.
• Remediation target — Critical: 30 days. High: 90 days. Medium: 180 days. Low or informational: best-effort, no committed deadline.
• Public disclosure — coordinated. We'll give you a heads-up before publishing a fix changelog entry, and credit you (with permission) at /changelog.

If you don't hear from us within 48 hours, please re-send your email — assume the first one was filtered to spam.

5. Recognition

We don't run a paid bounty program (yet). What we offer for valid reports:

• Public credit in the changelog and on a researchers page (with your permission and your preferred handle).
• A token of appreciation — usually swag once we have it; sometimes a personal thank-you note from the founder.
• For severe issues that would qualify as a critical bounty elsewhere, we'll discuss a discretionary cash reward case-by-case. We can't promise a fixed schedule because we don't yet have a budget for it; we'd rather be honest than over-promise.

As we grow, this section will become a real bounty program with published payouts. For now, please report regardless of reward — the security of our customers and theirs is the actual point.

6. Out-of-policy testing — what NOT to do

• Don't access any data that isn't yours. Use a test account; we'll provision one on request if you don't have one yet.
• Don't run sustained automated scans against production. If you need to test rate-limiting, ask first and we'll set up a sandbox.
• Don't pivot from a finding into deeper exploitation. Establishing impact is fine; widening the blast radius is not.
• Don't deploy persistent backdoors, malware, or implants — even as a PoC.
• Don't share, sell, or redistribute customer data you may have incidentally observed. Delete it from your systems and let us know.

7. Updates

This policy may change. The latest version is always at https://cloudarq.net/security/disclosure. Significant changes are noted in /changelog.