SECURITY

Report a vulnerability.

If you have found a security problem in VoxisLive, this page tells you where to send it, what we will do with it, and what we promise you in return. We do not run a paid bounty programme — this is a disclosure policy, and it is written to be kept.

Where to send it

Email [email protected] with “security” in the subject line. The same address is published in our security.txt, which is the machine-readable version of this page.

Please do not open a public GitHub issue for a security problem. The repository there is a read-only excerpt published for audit, and an issue on it is world-readable from the moment you press send.

What to include

A report we can reproduce is worth far more than a scanner score. The more of this you can give us, the faster it gets fixed:

  • What you found, in one or two sentences.
  • Where — the exact URL, the app version, or the extension version.
  • Steps to reproduce, in the order you did them.
  • What an attacker could actually do with it. A finding with no impact path is still welcome, but say so honestly rather than inflating it.
  • Anything that helps us confirm it: a request/response pair, a screenshot, a short video.

Please do not include other people's data. If your proof-of-concept happens to expose someone else's account, transcript or email address, tell us that it does and stop there — do not collect it, and do not attach it to the report.

What we commit to

  • We acknowledge within one business day, at the latest two. Business days run Monday to Friday, Türkiye time (UTC+3). This is the same commitment we make on every other support channel.
  • We tell you what we think. You get our assessment — confirmed, not reproducible, or accepted-but-won't-fix — and the reasoning, not a silent close.
  • We keep you updated while we work on it, rather than going quiet until it ships.
  • We credit you if you want it, by whatever name or handle you choose, on this page. You can also ask to stay anonymous.
  • We tell you when it is fixed, and we do not ask you to keep it secret forever.

We ask one thing back: give us a reasonable window to fix the problem before you publish it. Ninety days is the norm we work to, and if something is taking longer than that we would rather talk to you about it than let the clock run out in silence.

Safe harbour

If you make a good-faith effort to follow this policy, we will not pursue legal action against you, and we will not ask your hosting provider or employer to. We will treat your research as authorised, and if a third party brings a claim about it we will make clear that you were acting within this policy.

“Good faith” means: you stopped as soon as you had proof, you did not access, modify or destroy data that is not yours, you did not degrade the service for anyone else, and you gave us the chance to fix it first. Safe harbour covers the things this page puts in scope — it cannot cover our providers' systems, and it is not a licence to attack them.

In scope

  • voxislive.com and its language subpaths, plus the account, sign-in and billing flows on it.
  • The auth and usage API that the apps talk to.
  • The Windows desktop application and the Linux snap.
  • The Chrome and Edge browser extension.
  • The enterprise panel, if you have been given access to one.

Out of scope

These are either not ours to authorise, or they tell us nothing we can act on:

  • Denial of service, load testing, or anything that degrades the service for real users.
  • Social engineering of our team, our customers or our providers; phishing; physical access attempts.
  • The systems of our sub-processors — Google, Alibaba Cloud, Polar and Resend all run their own disclosure programmes, and we cannot grant you permission on their infrastructure. Our sub-processor list names each of them.
  • Reports that are only a scanner output or a missing-header score with no demonstrated impact.
  • Missing best-practice hardening with no attack path — tell us anyway, but expect it to be triaged as an improvement rather than a vulnerability.
  • Spam, brute-forcing your way into an account you do not own, or anything that involves another person's data.

There is no bounty

We do not pay for vulnerability reports. We would rather say that plainly than let you spend hours expecting one. What we do offer is a fast, human answer, public credit if you want it, and a fix you can verify yourself.

What we do not claim

A disclosure policy is not a certification. We hold no ISO 27001 certificate, no SOC 2 report and no third-party attestation, and we do not sign Business Associate Agreements. The trust centre sets out what we do claim and, just as importantly, what we do not — including where your audio goes, what never leaves your machine, and which third parties are involved.

Acknowledgements

Nobody has reported a vulnerability to us yet. When someone does and wants the credit, their name goes here.

FAQ

Common questions

01Do you pay for vulnerability reports?
No. There is no bounty and no swag. You get an acknowledgement within one business day, a real assessment, public credit if you want it, and a fix you can verify.
02Can I publish what I found?
Yes, once it is fixed or once a reasonable window has passed — we work to ninety days. We will not ask you to stay quiet indefinitely, and if a fix is taking longer than that we would rather agree a date with you than let it drift.
03I found something in the desktop app, not the website. Is that in scope?
Yes. The Windows application, the Linux snap and the browser extension are all in scope, as is the API they talk to. Include the version number — it is shown in the app's settings and on the changelog page.
04What if the problem is really in Google's or Alibaba's service?
Tell us anyway, and we will pass it on and tell you we have. But we cannot authorise testing on their infrastructure, so the safe harbour above does not extend there — go through their own disclosure programmes for anything you want to test directly.
05Is this a bug bounty programme?
No. It is a vulnerability disclosure policy: a published commitment about how we handle reports. A bounty programme pays for findings and usually runs on a platform; this does neither.
06How do I report a non-security bug?
Use Report a problem inside the app. It attaches a scrubbed log and diagnostics, and it never sends anything if the scrubbing fails. That route gets a normal bug to the right place much faster than email.