Security fixes are applied to the latest stable release and, when affected, the current beta line. Older releases should be upgraded before a report is validated.

Do not open a public issue for a suspected vulnerability.

Use GitHub's private vulnerability reporting to send the report to the maintainer.

Include:

• The affected version or commit.
• The affected component and runtime profile.
• Reproduction steps or a minimal proof of concept.
• The impact you observed.
• Any known mitigations.

Do not include live credentials, personal data, or access to a production system. Use test accounts and redact logs.

The maintainer will confirm receipt, investigate the report, coordinate a fix, and credit the reporter when requested and appropriate. Please allow time for a release before publishing technical details.

Reports are especially useful when they involve:

• Authentication or authorization bypass.
• Cross-user mailbox or admin-boundary data access.
• Secret, token, or personal-data exposure.
• Encryption, session, API-key, OAuth, or bearer-token handling flaws.
• Mail sync, SMTP send, MCP host, or external API authorization failures.
• Injection through HTTP, WebSocket, MCP, mail content, or AI input surfaces.

Questions about hardening a normal deployment belong in a GitHub issue and should not include secrets.