Responsible Disclosure Policy

1. Our Commitment

Magdox Private Limited (Magdox, we, us) treats the security of our products, including FDIE, as core to how we operate. We know that independent security researchers often find things our own team misses, and we want to make it easy and safe for you to tell us about them.

This policy explains how to report a vulnerability to us, what we ask of you while you do, and what you can expect from us once you have.

2. No Monetary Rewards

Magdox does not currently run a paid bug bounty program. We are not able to offer cash rewards for vulnerability reports at this time.

What we do offer is public recognition. Every researcher who submits a valid, previously unreported vulnerability is credited on our Hall of Fame page, with their name or handle and a short description of what they found, unless they would rather stay anonymous.

We may introduce paid rewards in the future. If we do, this policy will be updated first.

3. Scope

In scope:

• https://magdox.io and every subdomain under *.magdox.io, including our product application at https://fdie.magdox.io and its API.

Out of scope:

• mail.magdox.io. This subdomain is part of our Zoho Mail setup and is operated by Zoho, not by us. Any vulnerability there belongs to Zoho’s own security team, not ours, and we cannot offer safe harbor for testing infrastructure we do not control.
• Any third-party service we use but do not operate ourselves, including our payment processor, our CRM, and our hosting provider. Please report issues with those services directly to the company that runs them.
• Physical security, social engineering aimed at our employees, and denial-of-service testing of any kind.

4. How to Report

Email [email protected] with as much detail as you can give us. A report that lets us reproduce the issue on the first try gets fixed faster than one that does not.

Please include:

• What the vulnerability is and what kind of issue it is (for example, an authentication bypass or a stored XSS).
• Which URL, endpoint, or feature is affected.
• Step by step instructions to reproduce it.
• Proof of concept, if you have one. A screenshot or short screen recording is fine.
• What the impact is, in your own words.
• How you would fix it, if you have a suggestion. This part is optional.
• Your name or handle, and whether you would like to be credited publicly if we confirm the issue.

We read every report ourselves. We aim to acknowledge your email within three business days and keep you updated as we work through it. How long a fix takes depends on how severe and how complex the issue is, but we will tell you where things stand at each step.

5. Ground Rules

We ask that you:

• Only test against accounts and data you own, or that you have explicit permission to test against.
• Make a good faith effort to avoid privacy violations, data destruction, and any interruption or degradation of our service.
• Avoid social engineering of any kind, including phishing our staff or customers.
• Give us a reasonable amount of time to fix an issue before discussing it publicly.
• Send us one report per vulnerability, unless several smaller issues need to be reported together to show their combined impact.
• Avoid running aggressive, high-volume automated scanners against our production systems. Manual testing, or a scanner configured to be gentle with rate limits, is fine.

If you follow these rules in good faith, we will not pursue legal action against you for your research, and we will not suspend your account because of it. If a third party takes legal action against you for activity that was consistent with this policy, we will do what we can to make clear to them that your work was authorized.

6. What We Prioritize

We do not currently score reports for a payout, but we still triage every report by real world impact so the most serious issues get looked at first. Reports we treat as high priority include things like:

• Authentication or authorization bypass, including anything that lets one organization see or touch another organization’s firmware, findings, or account data.
• Remote code execution, anywhere in our upload, extraction, or analysis pipeline.
• Server-side request forgery that reaches internal infrastructure.
• Exposure of API keys, session tokens, or other credentials belonging to us or our customers.
• Injection vulnerabilities that expose or modify data you should not have access to.

Lower-priority issues, such as missing security headers on their own, or something only exploitable through clickjacking, are still worth reporting, but will usually not be treated as urgent.

7. What Is Not In Scope for Reporting

We generally do not need reports about:

• Rate limiting, unless you can show it leads to real data loss or a real business impact.
• Open redirects on their own.
• Clickjacking or issues that only work through clickjacking.
• Missing SPF, DKIM, or DMARC hardening beyond what we already publish.
• Username or email enumeration on public forms.
• Self-XSS that requires the victim to paste something into their own browser console.
• Descriptive error messages or stack traces that do not expose secrets or user data.
• Best-practice suggestions that are not themselves exploitable, such as a missing HSTS preload flag.
• Anything found using an out of date patch, reported within 30 days of the patch becoming available.

If you are not sure whether something counts, send it anyway. We would rather see a report that turns out to be low impact than miss a real one.

8. Confidentiality

If you report a vulnerability to us, you may come across information that is not public. This could include details about how our systems are built, our product roadmap, or other non-public technical or business information.

Please keep anything you learn through this process confidential. Do not publish it, share it, or use it for anything other than helping us fix the issue you found, for five years from when you learned it. Any technical materials or write-ups you prepare as part of a report, along with any copies you make of information we share with you, remain our property, and we may ask you to delete or return them once the issue is resolved.

If you are found to have broken this confidentiality obligation, or misused a vulnerability you found instead of reporting it responsibly, we reserve the right to take legal action, and to seek an injunction or other court order in addition to any other remedy available to us, since a breach here can cause harm that is difficult to fix with money alone.

9. Nothing Guaranteed

Submitting a report does not obligate Magdox to share any additional information with you, to fix the issue on any particular timeline, or to take any specific action. We will always tell you what we decided and why.

10. Changes to This Policy

We may update this policy from time to time as our program matures, including if we introduce paid rewards later. We will post the update here with a new effective date.

11. Governing Law

This policy is governed by the laws of India. Any dispute arising from it will be handled in the competent courts of West Bengal, India.

Thank you for taking the time to help keep Magdox and our customers safe.