Responsible Disclosure Policy

Short version: email security@shellorbit.com. Test only against your own account and data, do not run aggressive scanners at production, and give us time to fix things before you publish. Do that and we will not come after you.

1. Our Commitment

Magdox Private Limited (Magdox, we, us) treats the security of our products, including ShellOrbit, 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

ShellOrbit 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

ShellOrbit receives webhooks on your behalf, stores the payloads, and delivers them onward with retries. That shape is worth knowing before you start: the interesting surface is the boundary between one organization’s stored payloads and another’s, and the point where we make an outbound request to an address a customer chose.

In scope:

https://shellorbit.com and every subdomain under *.shellorbit.com.
The dashboard at https://app.shellorbit.com and its REST API.
The webhook ingest endpoint at https://hooks.shellorbit.com, including signature verification, payload handling, and the delivery and replay pipeline behind it.

Out of scope:

mail.shellorbit.com. 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 harbour for testing infrastructure we do not control.
Any third-party service we use but do not operate ourselves. That includes Paddle, who is our merchant of record and handles all payment details; WorkOS, who holds identity records on our behalf; ZeptoMail, who sends our email; Sentry, who receives our error reports; and Amazon Web Services, who host us. Please report issues with those services directly to the company that runs them. Our subprocessors page lists who does what.
Delivery to a destination you control. Pointing one of your own endpoints at your own server and observing that we make the request is the product working as designed, not server-side request forgery. What we do want to hear about is any way to make us reach an address a customer should not be able to reach, such as internal or link-local ranges, or to reach one through a redirect or a DNS answer that changes between our check and our request.
Physical security, social engineering aimed at our employees or customers, and denial-of-service testing of any kind.

4. How to Report and SLA Response Targets

Email security@shellorbit.com 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.
Your name or handle, and whether you would like to be credited publicly if we confirm the issue.

Response and Resolution SLAs

We read every report ourselves. On a best-efforts basis, we adhere to the following targets:

Initial acknowledgement: within 3 business days of receipt.
Triage and confirmation: within 5 business days of receipt.
Target resolution timeframes, based on CVSS severity:
- Critical (CVSS 9.0 to 10.0): 14 business days
- High (CVSS 7.0 to 8.9): 30 business days
- Medium (CVSS 4.0 to 6.9): 60 business days
- Low (CVSS 0.1 to 3.9): 90 business days

We will keep you informed on progress at each stage of remediation.

5. Ground Rules and Safe Harbour

We ask that you:

Only test against accounts and data you own, or that you have explicit permission to test against. A free account takes a minute to create and is the right place to do this.
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. Our ingest endpoint is designed to accept a lot of traffic, which makes it easy to hurt other people’s delivery while testing; please be careful with it.

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 triage every report by real-world impact so the most serious issues get looked at first. The table below shows how we categorize severity. It is not exhaustive; we apply judgment on a case-by-case basis.

Severity	CVSS Range	Example vulnerability types
Critical	9.0 to 10.0	Remote code execution anywhere in the ingest, delivery, or replay pipeline; authentication bypass allowing cross-tenant access; any read of another organization’s stored webhook payloads; bulk data exfiltration
High	7.0 to 8.9	Authentication or authorization bypass within a single tenant; account takeover without user interaction; IDOR exposing stored payloads, endpoint configuration, or API keys; vertical privilege escalation; stored XSS; server-side request forgery reaching internal infrastructure through a delivery destination; API key or session token exposure; forging a valid signature on an inbound webhook
Medium	4.0 to 6.9	Account takeover requiring user interaction; IDOR exposing non-sensitive data; reflected or DOM XSS capable of stealing session cookies; subdomain takeover on active domains; CSRF on a state-changing endpoint; billing manipulation such as granting a plan without paying for it
Low	0.1 to 3.9	Path traversal to non-sensitive files; IDOR on non-sensitive references; subdomain takeover on inactive domains; captcha bypass

Lower-priority issues, such as missing security headers on their own, or something only usable 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 do not themselves put data or accounts at risk, 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, other customers’ webhook payloads, 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 come across another customer’s data while testing, stop, do not save a copy beyond the minimum needed to show us the problem, and tell us in your report.

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 ShellOrbit 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, including the Information Technology Act, 2000. 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 ShellOrbit and our customers safe.