Maintainer setup: Fill in this table before release. Support means maintainers intend to consider security fixes for that version; it is not a response-time promise.
| Version or branch | Security fixes? |
|---|---|
| [CURRENT_SUPPORTED_VERSION_OR_BRANCH] | [Yes/No] |
| [OLDER_VERSION_OR_BRANCH, if any] | [Yes/No] |
Until this table is completed, no support commitment has been stated.
Maintainer action required: Enable GitHub's private vulnerability reporting through Security Advisories and link to [PRIVATE_SECURITY_REPORT_URL], or replace [SECURITY_CONTACT] with a monitored security email address. Verify the channel works before publishing. Do not use a public issue or pull request for exploit details.
Include a concise description, affected version or commit, steps to reproduce, likely impact, and any safe proof of concept. State whether data may have been exposed. Remove credentials, personal data, and unnecessary exploit payloads from reports. If a secure way to share sensitive evidence is needed, agree on it with maintainers first.
Maintainers should acknowledge a report when they can, investigate and reproduce it, coordinate a fix, and agree with the reporter on responsible public disclosure. Avoid publishing details that would help exploitation before users have a reasonable opportunity to update. A security advisory and release notes can describe affected versions, impact, mitigation, and credit when appropriate. No fixed response or resolution time is promised here.