How to report
- Email security@revenuedot.app, or use GitHub's private Report a vulnerability form on the repository.
- Include the affected component and version or URL, steps to reproduce, the impact you think it has, and how to reach you.
- Please do not open a public issue or discuss it publicly until we have released a fix.
What happens next
| Acknowledgement | Within 2 business days |
|---|---|
| First assessment | Within 5 business days, with a severity and a plan |
| Fix | Critical and high issues as fast as we can, usually within 30 days; we keep you updated |
| Disclosure | We publish an advisory with the fix and credit you, if you want credit |
In scope
- The open-source server, dashboard, importer, CLI and MCP server in github.com/revenuedot.
- The RevenueDot SDK forks, for issues our patches introduce. Issues in upstream RevenueCat code should also go to RevenueCat.
- RevenueDot Cloud and revenuedot.app, including api.revenuedot.app.
We are especially interested in: granting or keeping entitlements without a valid purchase, bypassing receipt or notification signature checks, reading another project's data, webhook signature bypass, and authentication or session flaws.
Out of scope
- Denial-of-service and volumetric testing, spam and social engineering of our team.
- Findings that need a compromised device, a rooted phone or physical access.
- Missing security headers or best-practice notes without a working exploit.
- Other customers' self-hosted installs. Report those to their operators.
Safe harbor
If you act in good faith and follow this policy, we will not pursue or support legal action against you for your research. Good faith means: use only your own accounts and test data, stop and tell us as soon as you reach data that is not yours, do not keep or share it, and do not degrade the Service for others. If in doubt, ask first at security@revenuedot.app.
How we protect RevenueDot
- Every App Store transaction is verified against Apple's signed JWS and the App Store Server API, and every Google Play purchase with the Play Developer API, on the server. Nothing is trusted from the device alone.
- App Store notifications are checked against Apple's signature, Google Play pushes can require a Google-signed token, and every Google notification is confirmed with the Play Developer API before it changes state.
- Webhooks carry an Authorization header and an HMAC signature so your backend can verify them.
- Passwords are hashed with PBKDF2; sessions use HttpOnly cookies.
- SDK responses are signed so the SDKs' Trusted Entitlements verification works with the RevenueDot forks.
A machine-readable contact file is at /.well-known/security.txt.