Help secure both Magdox products.

Version 1.2 · Updated 9 October 2026 · Published by MAGDOX Private Limited.

1. Report privately

Email security@magdox.io. Include the affected product, URL or component version, vulnerability class, expected impact, minimal reproduction, time of testing and a way to contact you. A redacted screenshot or a small non-destructive proof of concept is useful. Tell us whether you want credit.

For an npm package report, include the exact package name and version, installation source, operating system, Node.js version and minimal reproduction commands. Use a test repository with synthetic data and redact local paths or configuration that could identify a customer or expose a secret.

Do not put credentials, access tokens, raw firmware, private source or customer records in an initial email, public issue or contact form. If sensitive evidence is necessary, ask us to agree a secure transfer channel first. Never send a working secret merely to prove you found it.

2. In-scope assets and boundaries

This list does not grant wildcard authority over every subdomain, IP address or cloud resource associated with Magdox. New, staging, internal and unlisted hosts need written scope confirmation. The retired fdie.dev marketing domain is not a second product site or an invitation to test all of its subdomains; report a suspected Magdox-controlled redirect or dangling record privately without taking it over.

A listed hostname is not a statement that a deployment is already reachable. Test only the Magdox-operated service available through that named host and its ordinary product paths. Release downloads, device approval and licence renewal are covered when invoked through an authorised Code Security workflow; this does not expand scope to a storage provider or unrelated download host.

npm package scope covers these two official package names and Magdox-maintained code distributed through them. It does not grant permission to test npm’s registry or accounts, use publisher credentials, publish or modify packages, or target unrelated dependencies. Report a dependency issue when you can demonstrate its security impact in the Magdox package; follow the upstream maintainer’s policy for testing their systems.

We welcome reports concerning remote code execution, unsafe deserialisation, unsafe firmware extraction, path traversal, injection, SSRF, signing/update failures, authentication/MFA/SSO bypass, cross-tenant access, secret leakage and unintended transfer of code or firmware. Demonstrate the smallest impact necessary, preferably in an authorised local environment.

3. Permission and testing rules

• Use only individual accounts, organisations, data and installations you own or are expressly authorised to test. A shared demo account is not permission to inspect another person’s records.
• Use low-volume, non-destructive requests. Stop if testing affects availability or encounters another customer’s data. Report the boundary failure without exploring further.
• Do not download unrelated data, persist access, change another user’s records, create privileged accounts, pivot to internal services, or execute destructive payloads. A minimal indicator is enough to start an investigation.
• Do not perform denial-of-service, resource-exhaustion, credential-stuffing, phishing, social engineering or physical testing. Do not send unsolicited scan traffic to customer or third-party endpoints.
• Keep evidence access-restricted. Coordinate secure deletion of accidentally encountered records once the minimal report is preserved; do not sell access, data or non-public exploit details.
• For potentially disruptive firmware, extraction or sandbox-escape research, use a permitted isolated installation or arrange a test environment with us before submitting it to shared hosting.

4. What this policy cannot authorise

Third-party services, including AWS and Amazon SES, Cloudflare, Oracle Cloud, Zoho, Cal.com, Zoom, Dodo Payments, Sentry, PostHog, IPinfo, OSV.dev, GitHub, npm, Homebrew, identity providers and AI services, operate their own programmes. An issue in our integration or configuration is reportable to us; that does not authorise attacking the provider. Customer-operated servers, networks, devices and data remain subject to the customer’s permission. Private repositories and employee accounts are outside this grant.

Unreproducible scanner output, a version banner or CVE without evidence of an affected deployment, missing headers without impact, self-XSS, speculative rate-limit findings and ordinary product-quality issues may not qualify as security vulnerabilities. If uncertain, send a concise private report; there is no need to increase harm to establish severity.

5. Response, fixes and advisories

We aim to acknowledge within 3 business days and provide an initial triage assessment within 5 business days. Severity reflects actual impact and exploit prerequisites, with CVSS as one input. From confirmation, our best-effort remediation targets are:

We will explain material changes, update you as work progresses and coordinate retesting. Mitigation may precede a complete fix. A target does not guarantee a date, disclose confidential investigation details or override a legal notification duty.

Hosted Code Security and FDIE are fixed in the hosted service; nothing needs to be installed. CLI fixes are released only in the latest version and older releases are not supported. Releases are published at github.com/Magdox/magdox-cli/releases and in the Release Notes. FDIE on-premises and other software run under an agreement receive security updates while the subscription or support agreement is active, through the agreed delivery channel. When we fix a vulnerability in software that customers install, we publish an advisory: for the CLI as a GitHub security advisory on github.com/Magdox/magdox-cli, and for FDIE on-premises with the release that fixes it. Where a vulnerability in a released version warrants one, we request a CVE identifier through GitHub. The Security Policy sets out the supported versions.

6. Coordinated disclosure

Keep exploit details private until remediation or 90 calendar days after the report, whichever comes first. We may request a mutually agreed extension; it is not automatic. If a deadline or active exploitation requires earlier disclosure, contact us promptly to coordinate responsible handling. Nothing here requires delaying a mandatory legal report.

Your write-up remains yours. After that window, you may publish an accurate account without customer data, credentials or unrelated confidential material. Permitted coordinated publication does not by itself remove safe harbour. This process asks for time to protect users, not indefinite silence.

7. Safe harbour

For good-faith research that follows this policy on assets we are entitled to authorise, Magdox considers the activity authorised. We will not bring civil proceedings, request criminal action or suspend an account solely for that compliant research. This includes our commitment not to make a complaint about that research under sections 43 or 66 of India’s Information Technology Act, 2000. If a third party raises a concern, we will explain the scope of the authorisation we granted.

This is Magdox’s commitment. It cannot bind another owner, a regulator, law enforcement or a court, and does not authorise third-party systems, continued exploitation, extortion or misuse of data. If you unintentionally cross a boundary, stop, minimise access and report it promptly so we can assess the circumstances. Changes to this policy do not retroactively withdraw permission for research conducted within the version then in effect.

8. Recognition and contact records

There is currently no paid bug bounty and a report does not create a payment entitlement. With permission, we acknowledge qualifying coordinated reports for either product or the website in the combined Hall of Fame. You may stay anonymous. Researcher contact and report information is handled for investigation, coordination and legal obligations under the Privacy Policy.

• Points are awarded per unique, previously unreported, confirmed in-scope vulnerability, using the final severity assigned during triage. Repeated endpoints or reports caused by the same underlying issue do not earn duplicate points.
• A qualifying report must follow the disclosure policy. Points and an entry are published after remediation or an agreed mitigation and coordinated disclosure, with the researcher's permission. Informational reports receive 0 points and do not qualify for the Hall of Fame.
• A researcher's total is the sum of their credited qualifying reports across the website, Code Security and FDIE. At least one qualifying report worth 1 or more points is required; submitting a report does not itself create an entry.
• We explain the severity and recognition decision; researchers may provide additional evidence for reconsideration. Points are recognition only, not money, credits, prizes or a promise of a future reward. Researchers may use a handle or remain unlisted.

9. Policy records and questions

Our machine-readable contact is security.txt. Check the current asset list before testing; if scope is unclear, ask security@magdox.io. Indian law and competent courts of West Bengal apply to this policy subject to non-waivable rights and applicable law. A later policy version will carry a new date.