Vulnerability Disclosure
Version 1.0 · GZ-08-0011 · Last updated 28 August 2026
If you have found a security flaw in GetZuga, we want to hear about it and we will not treat you as a problem for telling us.
Reporting
security@getzuga.com
Please include what you found, how to reproduce it, and what you believe the impact is.
What we commit to
- We will acknowledge your report within 5 working days.
- We will keep you updated while we investigate.
- We will not pursue legal action against you for research carried out in good faith under this policy.
- We will credit you if you would like to be credited.
Rewards
We do not offer monetary rewards. We do offer credit.
Said plainly because the alternative is worse: a researcher who assumes a bounty and finds there isn't one has been wasted, and that is how a disclosure turns adversarial.
Please do
- Test only against your own account and data.
- Report promptly, and give us reasonable time to fix an issue before publishing it.
Please do not
- Access, modify or delete other people's data.
- Degrade the service — no denial of service, and no bulk automated scanning against production.
- Use social engineering against our staff or our users.
- Test physical security.
Out of scope
- Missing hardening headers with no demonstrated exploit path.
- Automated scanner output with no demonstrated impact.
- Issues in third-party services we do not operate.
security.txt
Published at /.well-known/security.txt per RFC 9116.
For the build, not for readers: security.txt must carry Contact: mailto:security@getzuga.com, Policy: https://www.getzuga.com/trust/security, Preferred-Languages: en, and an Expires value computed at build time as publication date plus twelve months. The file is invalid without Expires, and invalid again once it has passed — so the build check should fail if Expires is absent or in the past, rather than only on first publication. /.well-known/ is already exempt from the apex redirect, so the path works today.