Security fixes are provided for one series: the latest minor of the current major. They are delivered as a new release of that series, not as a patch to an older one, and there is no backport commitment to a previous major. This is the same policy VERSIONING.md states for bug fixes, deliberately worded the same way — a security policy that promises more than the release policy delivers is worse than one that promises less.
| Version | Supported |
|---|---|
| 3.0.x | Yes |
| 2.6.x | No — superseded by 3.0; fixes ship in the 3.0 series |
| < 2.0 | No |
Note that 3.0 is a major release with source-breaking changes, so "upgrade to the supported series" is not always a drop-in move; CHANGELOG.md lists what changed, and the migration guide covers the paths that need edits. If that is a genuine obstacle for a reported vulnerability, say so in the report — the decision is made per report, and it is better made with that information than without it.
Do not report security issues through public GitHub issues, pull requests, or discussions.
Report vulnerabilities privately through GitHub's coordinated disclosure:
- Go to the repository's Security tab.
- Select Report a vulnerability to open a private advisory.
- Include the affected version, a description of the impact, and a minimal reproduction if possible.
Please include enough detail to reproduce and assess the issue: affected component (qb-core, qb-io, a transport, crypto, QUIC), configuration and build flags, platform and compiler, and a proof of concept where applicable.
- Acknowledgement of your report within a few business days.
- An initial assessment of severity and affected versions.
- Coordination on a fix and a disclosure timeline. We aim to resolve confirmed high-severity issues promptly and will keep you informed of progress.
- Credit for the discovery in the release notes, unless you prefer to remain anonymous.
Please give us reasonable time to investigate and release a fix before any public disclosure.
In scope: memory-safety defects, denial-of-service vectors, authentication or cryptographic weaknesses, and
input-handling flaws in qb's own code (qb-core, qb-io) and in how qb integrates and configures the bundled
third-party components under src/qb/vendor — the libev fork qev (which carries wepoll on Windows),
nanolog, ska_hash, and stduuid.
Out of scope: defects in the upstream third-party projects themselves (libev, stduuid, nlohmann/json, …) —
report those to their maintainers; and issues that require a misconfiguration explicitly warned against in
the documentation. Findings in the optional qbm modules belong to their respective repositories.
nlohmann/json is a dependency, not a bundled component: since 3.0 it is resolved with
find_package(nlohmann_json), so a defect in it is upstream's, while qb's use of it is in scope.