Reporting a vulnerability
If you have found a security issue in Virtik, we want to hear about it — and we would rather hear it from you than read about it later.
Report a vulnerabilityGoes to the security route, not general support, so it is not queued behind billing questions.
What to include
What makes a report actionable
A report we can reproduce gets fixed. One we cannot gets a round trip of questions first.
- Enough detail to reproduce the issue — steps, request/response, and the account or tenant context you used.
- The affected surface: www.virtik.ai, app.virtik.ai, the mobile surface, or an API endpoint.
- What you believe the impact is, and whether you were able to confirm it.
- Whether any customer data was accessible, and how much you needed to see to demonstrate the finding.
Good-faith research
What we ask of you
Research conducted within these bounds is research we will not pursue action over.
- Respect user privacy — access only what is necessary to demonstrate the finding, and stop there.
- Do not degrade the service. No denial of service, no bulk automated scanning against production.
- Do not access, modify, exfiltrate or retain data belonging to another organisation.
- Give us a reasonable opportunity to remediate before disclosing publicly.
What we commit to
We will acknowledge your report, investigate it, and tell you what we found — including if we conclude it is not a vulnerability, and why.
We are not publishing a response-time target, because we do not yet have the on-call rotation to guarantee one. Committing to a number we might miss would be a poor first interaction with exactly the people most likely to notice.
A formal disclosure policy and a security advisory feed are planned as part of the Trust Center. Until they exist, this page and the security contact route are the process.
Not a vulnerability report?
Security questions during an evaluation, architecture review requests and documentation requests go through the security review route instead.