This repository is maintained with a security-first posture. Report vulnerabilities responsibly and do not disclose them publicly before they are reviewed and addressed.

Security review and remediation effort is focused on the latest maintained release on the default branch.

If you are running an older release, reproduce the issue against the latest code before reporting it.

Do not report vulnerabilities in public GitHub Issues, Pull Requests, Discussions, screenshots, blog posts, or social media.

Use one of the following private channels:

1. GitHub private vulnerability reporting, if enabled for the repository
2. The maintainer security contact listed by the project, if one is published

If private vulnerability reporting is not enabled and no dedicated security contact is published, open a minimal public issue requesting a private security contact without including exploit details.

A strong report should include:

• A concise description of the issue
• Affected component, file, feature, or code path
• Clear reproduction steps
• Required privileges or preconditions
• Security impact
• Proof of concept, payload, or screenshots where appropriate
• Suggested remediation ideas, if available

Reports that are specific, reproducible, and technically grounded are easier to validate and fix.

Do not:

• Publish proof-of-concept exploit details before a fix is available
• Open a public issue containing exploit steps or sensitive data
• Test against systems you do not own or have permission to assess
• Exfiltrate, modify, or destroy real user data
• Chain speculative claims without evidence

Reports are reviewed on a best-effort basis. Triage speed, remediation timing, and release timing depend on severity, reproducibility, maintainer availability, and project priorities.

Submitting a report does not guarantee an immediate response, a public credit, or a fix timeline.

When a valid issue is confirmed, remediation is prioritized according to:

• Severity and exploitability
• Exposure of sensitive data or privileged actions
• Likelihood of real-world abuse
• Backward-compatibility impact of the fix

Fixes may be released silently before broader public discussion if that is the safer path.

Coordinated disclosure is expected.

Please allow the maintainer reasonable time to investigate, remediate, test, and publish a fix before sharing technical details publicly.

For maintainers, the following baseline is recommended where available:

• Enable GitHub private vulnerability reporting
• Enable dependency and secret scanning where supported
• Review third-party dependencies conservatively
• Keep the public attack surface minimal
• Do not commit secrets, tokens, certificates, or private keys

The following are generally out of scope unless a concrete, repository-specific exploit path is shown:

• Best-practice disagreements without demonstrated impact
• Missing headers or hardening preferences without exploitability
• Vulnerabilities in unrelated third-party services
• Local environment misconfiguration not caused by repository code
• Theoretical issues without a reproducible path

Security reports are taken seriously, but they must be evidence-based. Clear reproduction and accurate technical detail matter.