CarboneIO SAS takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations.

While the discovery of new vulnerabilities is rare, we also recommend always using the latest versions of CarboneJS to ensure your application remains as secure as possible.

** Please do not report security vulnerabilities through public GitHub issues. **

If you believe you have found a security issue in Carbonejs, Carbone Studio, Carbone Render or anything related to the Carbone ecosystem, please responsibly disclose by contacting us at support[at]carbone.io. Even when you are not 100% certain that it is actually a security issue. Typically, you will receive an answer within a day or even within a few hours. If possible, encrypt your message with our PGP key.

When a vulnerability is reported, it immediately becomes our top concern, with a full-time contributor dropping everything to work on it. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message.

Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:

• Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
• Full paths of source file(s) related to the manifestation of the issue
• The location of the affected source code (tag/branch/commit or direct URL)
• Any special configuration required to reproduce the issue
• Step-by-step instructions to reproduce the issue
• Proof-of-concept or exploit code (if possible)
• Impact of the issue, including how an attacker might exploit the issue

Thank you for improving the security of Carbone and its ecosystem. Your efforts and responsible disclosure are greatly appreciated and will be acknowledged.

The carbone npm package is a library. It has no HTTP server and no network attack surface: every input comes from the code of the application that integrates it.

• Template paths given to carbone.render() and carbone.getFileExtension() are trusted and chosen by the developer. Relative paths (resolved from templatePath) and absolute paths are accepted by design, like fs.readFile(), new sqlite3.Database(path), sharp(path) or ejs.renderFile(path).
• Options, set() parameters and custom formatters are also provided by the developer.
• The application is responsible for validating any end-user input before passing it to Carbone (for example, only accept an ID that maps to a known template).

Reports that require the integrating application to pass unvalidated end-user input as a file path, option or formatter are out of scope: the vulnerability would be in that application, not in Carbone. Carbone On-Premise and Carbone Cloud (the HTTP server editions) validate these inputs before calling the library.

If you have suggestions on how this process could be improved please submit a pull request to discuss.