Do not report security vulnerabilities through public issues, discussions, pull requests, or social media.

Use GitHub private vulnerability reporting for the affected repository. If private reporting is unavailable, contact the organization through its published security contact.

Include:

• A clear description of the vulnerability
• The affected repository, version, endpoint, or feature
• Reproduction steps or a proof of concept
• Expected impact
• Suggested remediation when available
• Whether the issue may have been actively exploited

Do not include real user credentials, private keys, seed phrases, wallet signatures, bearer tokens, provider secrets, or production personal data. Use test accounts and sanitized evidence.

The maintainers will:

1. Acknowledge the report.
2. Validate scope and severity.
3. Coordinate remediation and disclosure.
4. Provide status updates when practical.
5. Publish an advisory when disclosure is appropriate.

Do not publicly disclose the vulnerability before the maintainers confirm that affected users have had a reasonable opportunity to update.

Reports involving any of the following should always use private reporting:

• Authentication or session bypass
• Cross-account access
• Wallet ownership or signature verification
• Private keys, API credentials, or encryption keys
• Order manipulation, duplication, or unauthorized cancellation
• Balance, allowance, position, or PnL corruption
• Automation execution outside approved constraints
• Injection, remote code execution, or dependency compromise
• Personal data exposure

Security fixes are applied to the latest supported release and active deployment branches. Older versions may be required to upgrade before receiving a fix.