If you find a vulnerability in libxmlb you should let us know using a private vulnerability disclosure on GitHub, with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue.

Failing that, please report the issue against the libxmlb component in Red Hat bugzilla, with the security checkbox set. You should get a response within 3 days. We have no bug bounty program, but we're happy to credit you in updates if this is what you would like us to do.

Security bugs found or assisted by AI tools must also include two additional things:

• A reproducer that clearly shows the vulnerability on an unmodified xb-tool binary that is running with all the usual OS level protections.

• A pull requests that fixes the security vulnerability and adds unit tests; the logic being that if you're using an autonomous system to find a theoretical issue you should also have the common courtesy to submit a PR that fixes the vulnerability.

Any security issue with the premise of “an attacker can supply a crafted xmlb file” will be closed. The .xmlb binary file is an internal-ABI trusted memory-mapped blob -- it is not a loadable file format and cannot be used like that. No libxmlb user is shipping pre-compiled .xmlb blobs to end users, and due to the implementation of the silo GUID it would be impossible to do so.

Additionally, we will not issue CVEs or GHSA IDs for AI-discovered security issues lower than moderate -- doing so offers nothing to the libxmlb community (anyone can use similar tools to find the same issue) and adds a huge burden on the existing maintenance team.

The CVSS scoring of reported bugs is often wildly inflated by AI tools (for various reasons), and the actual CVSS scoring may be modified at the libxmlb maintainers discretion.

So-called "low severity" security bugs or "hardening enhancements" will be treated as normal issues and will be fixed as part of the next tarball release with no coordinated disclosure process.