We take the security of our services and the privacy of our users' data very seriously. If you have discovered a security vulnerability, we appreciate your help in disclosing it to us responsibly.

Please do not report security vulnerabilities through public GitHub issues or public forums.

Please choose the path that best fits your intent:

• Responsible Disclosure: If you have identified a security vulnerability, please email security@mixpanel.com.

  • Note: Your report will be routed to our internal ticketing system. We will acknowledge receipt of your findings. Please be advised that we do not maintain ongoing communication regarding the status of reports unless we have specific follow-up questions.

• Bug Bounty Program: If you are a security researcher interested in participating in our private bug bounty program, please email bugbounty@mixpanel.com to request onboarding instructions.

  • Note: Participation in our private program is subject to eligibility requirements, including a verification process to ensure researchers are in good standing on the HackerOne platform.

To help us triage the issue effectively, please include:

• Summary: A clear description of the vulnerability.
• Environment: The affected service, SDK, or repository.
• Reproduction Steps: Step-by-step instructions to reproduce the issue.
• Impact: A description of the potential risk.
• Remediation Suggestions: Any specific recommendations you have for mitigating or fixing the vulnerability.

This policy applies across our public repositories. Reports are evaluated against our released and distributed software and its runtime dependencies — the code and artifacts we actually ship to users — not against build-time tooling or repository contents that are never distributed.

Out of scope:

• Development and build dependencies (for example, devDependencies in a package manifest): bundlers, linters, test tooling, and their transitive dependencies. These are not distributed to users — a production install of a released package does not include them — and they are not present in released artifacts.
• Dependencies of sample, example, or documentation code in our repositories.
• Findings produced by scanning a repository or its lock files that do not demonstrate impact on the released or distributed artifact.

Where we publish a Software Bill of Materials (SBOM) with a release, it reflects the actual distributed dependency set and is the correct basis for assessing that component's supply chain. Please demonstrate impact on released software or one of its runtime dependencies.

We are committed to securing our latest stable releases. We recommend all users keep their implementations updated to the most current version to ensure they have the latest security patches.