Skip to main content

Reporting vulnerabilities

A vulnerability is a bug or feature that can be exploited for malicious purposes. Some examples (non-exhaustive) are unauthorized access to/modification of data and compromising the availability of a website (AKA denial of service).

If you think you've found a vulnerability, please DO NOT submit a public bug report. Publicly exposing the details of a vulnerability before a fix has been published can leave existing users of XCG vulnerable to compromise. Instead, please submit a private report using the steps below so that the XCG maintainers can handle the issue in a way that minimizes exposure to existing users.

Vulnerability reporting and disclosure process​

The first step is to submit this vulnerability reporting form. The XCG maintainer team will respond via email within 2 working days at the maximum, either to confirm/reject the vulnerability or at least to acknowledge your submission if we need more time for triage. Please provide as many details as you can to assist the team in confirming the vulnerability. Useful information includes:

  1. What version(s) you've tested on and what other versions you think may be affected
  2. The environment in which you tested the exploit, including but not limited to OS family/version and Python version
  3. Detailed steps for exploiting the vulnerability, including code snippets and screenshots if possible and helpful

If the issue is deemed to not be a vulnerability, the team will explain their reasoning and may direct you to re-raise the issue via other more appropriate channels (e.g. GitHub issues for a bug report). Further discussion can be carried out via email if you need more clarity or disagree with the team's assessment.

If the issue is confirmed as a vulnerability, the team will proceed to create a private GitHub security advisory within the affected package's GitHub repo. If you indicated interest to collaborate on the development of a fix, your GitHub user will be added as a "collaborator" in the private security advisory.

The team will create and publish a fix within 90 days from the time of reporting, as per the current industry norm. However, our goal is to push a fix much sooner than that, ideally within 2-3 weeks of confirming the vulnerability. Development of a fix will be performed in a private repository forked from the original.

Once the fix is ready, it will be merged back into the original repository and a release will be generated. The private security advisory will also be published (i.e. made public) so that package users can be notified in a timely manner. At this point, if you chose not to participate in the fix development process (as indicated in the submitted form), the team will notify you via email that a fix is available.