Vulnerability Disclosure Policy

1. Scope

This policy covers vulnerabilities in assets Cracken owns and operates:

• cracken.ai and its subdomains;
• Cracken's own publicly reachable infrastructure, including the application, its APIs and the supporting services Cracken exposes to the internet.

The following are out of scope, without exception:

• customer environments, and any system Cracken tests on a customer's behalf. Those assets belong to the customer, and Cracken cannot authorize testing against them;
• third-party services Cracken uses, including the sub-processors listed in the Sub-processor List. Report those to the provider under its own disclosure policy;
• anything requiring physical access to Cracken premises or hardware, or social engineering of Cracken staff.

2. Safe harbor

If you act in good faith and stay within this policy, Cracken treats your research as authorized. Cracken will not pursue legal action against you for it, and will not support legal action brought by others in respect of it.

That authorization covers Cracken's own assets only. It does not authorize testing of customer systems, third-party systems or any target Cracken tests on a customer's behalf. Cracken cannot grant authorization it does not hold, and this policy gives you no cover for testing outside the assets listed in section 1.

If you make a good-faith mistake while following this policy, stop, say so in your report, and Cracken will treat it as the mistake it was.

3. Rules

• Stop at the minimum proof that a vulnerability is exploitable. Do not pivot further into systems, escalate beyond what the proof needs, or establish persistence.
• Do not access, modify, exfiltrate or retain data belonging to Cracken, its customers or any third party. If you encounter such data, stop immediately and report what you saw.
• No denial of service, resource exhaustion, or automated scanning that degrades service for anyone else.
• No spam, no social engineering, no physical intrusion.
• Report promptly. Do not sit on a finding while it is exploitable.

Research that breaks these rules falls outside this policy, and outside the safe harbor in section 2.

4. How to report

Send reports to security@cracken.ai. Include:

• the affected asset: the exact host, URL or endpoint;
• reproduction steps precise enough for Cracken to follow them without guessing;
• the impact you were able to demonstrate;
• any proof-of-concept, script, request and response capture, or screenshot.

Reports may be sent in English.

5. What to expect

Cracken commits to:

• acknowledgement of your report within 3 business days;
• a triage decision within 10 business days, stating whether the report is accepted, a duplicate, out of scope or not a vulnerability, and why;
• progress updates until the issue is resolved or closed.

These are commitments, not aspirations. If Cracken misses one, chase it on the same thread at security@cracken.ai.

6. Coordinated disclosure

Give Cracken 90 days from acknowledgement before disclosing publicly. Where the fix is straightforward, Cracken will work to a shorter timeline and tell you when the fix has shipped. 90 days is a ceiling, not a schedule.

Once a fix has shipped, Cracken will not object to publication. If you need a different timeline, raise it early rather than at day 89.

7. Recognition and bounty

Cracken does not run a paid bug bounty. There is no reward budget and no report will be paid. If that changes, this policy will say so.

What Cracken does offer is credit. Tell Cracken in your report the name or handle you want listed, and Cracken will credit you in an acknowledgements list once the issue is fixed. The default is no public mention, so researchers who prefer to stay unnamed do not have to ask.

Owner: security@cracken.ai