Skip to content

Security: cube-js/cube

SECURITY.md

Security Policy

Reporting a vulnerability

Report vulnerabilities privately through either channel:

Please do not open GitHub issues, pull requests, discussions or Slack threads about a vulnerability before a fix is released.

Include as much of the following as you can:

  • the affected component and version or commit;
  • steps to reproduce, or a proof of concept;
  • the impact you observed, and what an attacker could achieve;
  • your name or handle, if you would like to be credited.

Supported versions

Security fixes for Cube Core are released in the latest release. Upgrade to the latest release to receive them.

What happens next

  • We acknowledge your report within 3 business days.
  • We confirm whether the issue is a vulnerability, assess its severity and keep you updated until it is resolved.
  • We fix confirmed vulnerabilities according to their severity and coordinate the disclosure date with you.
  • Vulnerabilities in Cube Core are published as GitHub Security Advisories with a CVE assigned. Reporters are credited unless they ask not to be.

Safe harbor

We will not pursue legal action against research that is done in good faith and within these guidelines:

  • test only against your own deployment of Cube Core or your own Cube Cloud account;
  • do not access, modify or keep data that does not belong to you;
  • do not degrade the service for other users, for example through denial-of-service or high-volume automated testing;
  • give us reasonable time to release a fix before you disclose the issue publicly.

Rewards

Cube does not run a bug bounty program. A reward is considered case by case, and only for a report that demonstrates, against your own deployment or account, a vulnerability that gives access to critical data, such as unauthorized access to a connected data source.

Learn more about advisories related to cube-js/cube in the GitHub Advisory Database