Responsible Disclosure of Odoo Security Vulnerabilities

Help us keep Odoo safe and secure!

Responsible Disclosure Policy

The safety of Odoo systems is very important to us (not only because we use Odoo internally), and we consider security problems with the highest priority. We do our best every day to protect Odoo users from known security threats, and we welcome all reports of security vulnerabilities discovered by our users and contributors.

We are committed to handle vulnerability reports with the greatest attention, provided that the following rules are respected.

Reporting an issue

Please share privately the details of your security vulnerability by emailing our Security Team at   Security at odoo top-level-domain

Make sure to include as much information as possible, including the detailed steps to reproduce the problem, the versions that are affected, the expected results and actual results, and any other information that might help us react faster and more efficiently.

Important note: we receive a majority of security reports that have little to no impact on the security of Odoo or Odoo Online, and we ultimately have to reject them. To avoid a disappointing experience when contacting us, please try to put together a proof-of-concept attack and take a critical look at what's really at risk. If the proposed attack scenario turns out unrealistic, your report will probably be rejected. Also be sure to review our list of non-qualifying issues below.

You may send this report from an anonymous email account, although we promise not to disclose your identity if you do not want us to.

You can also encrypt and verify messages to/from our security team with our GPG Key with ID 0x0B9EA35A8E877D2F.

Disclosure Procedure

  1. You privately share the details of the security vulnerability with our Security Team by reporting an issue (see above)
  2. We acknowledge your submission and verify the vulnerability as soon as possible
  3. We work on a correction in collaboration with you
  4. We write a detailed Security Advisory describing the issue, its impacts, possible workarounds and solution, and we ask you to review it
  5. We privately broadcast the Security Advisory and the correction to stakeholders and customers with an Odoo Enterprise Contract
  6. We give stakeholders and customers a reasonable delay to apply the correction, before disclosing it publicly (e.g. 3 weeks)
  7. We disclose and broadcast the Security Advisory and the correction on our public channels.

Rules

We ask you to observe the following rules at all times:

  • Exclusively test vulnerabilities on your own deployments, on demo.odoo.com, or on your own trial instances of Odoo Online
  • Never attempt to access or modify data that does not belong to you
  • Never attempt to execute denial of service attacks, or to compromise the reliability and integrity of services that do not belong to you
  • Do not use scanners or automated tools to find vulnerabilities, as their effects will violate the previous rules
  • Never attempt non-technical attacks such as social engineering, phishing, or physical attacks against anyone or any system
  • Do not publicly disclose vulnerabilities without our prior consent (see also the Disclosure Procedure above). During the non-disclosure period you are authorized to use/test any correction we've provided, as long as no emphasis is put on that correction and it is not published in the form of a security report (i.e. using it on production servers is fine).

In return:

  • We will not initiate legal action against you if you followed the rules
  • We will process your report and respond as quickly as possible
  • We will provide a fix as soon as possible
  • We will keep you updated of the progress and disclosure steps (see also the Disclosure Procedure above)
  • We will work diligently with stakeholders and customers in order to help them restore the safety of their system
  • We will not publically disclose your identity if you do not want to be credited for your discovery

What to report?

Qualifying vulnerabilities

  • SQL injection vectors in public API methods
  • XSS vulnerabilities working in supported browsers
  • Broken authentication or session management, allowing unauthorized access
  • Broken sandboxing of customizations, allowing arbitrary code execution or access to system resources

NON Qualifying vulnerabilities

  • XSS vulnerabilities working only in unsupported/deprecated browsers, or requiring relaxed security settings
  • Pseudo-XSS vulnerabilities on your own Odoo Online instance. If you registered bar.odoo.com, you are the webmaster.
  • File path disclosures, which do not carry significant risk and do not enable attacks that would be otherwise impossible
  • Clickjacking or phishing attacks using social engineering tricks to abuse users, with the system working as intended
  • Tabnapping or other phishing attacks conducted by navigating other browser tabs
  • Open redirectors, considered as vectors to attempt indirect phishing attacks - those attacks are also possible directly
  • Reflected File Downloads, another attack technique that requires social engineering and is not very practical
  • Referer leak (including sensitive tokens) via social media links - very unlikely to be clicked, or to be exploited by the social medias
  • More generally, attacks relying on social engineering techniques will usually be rejected
  • Scripting/brute-forcing of components working as designed (e.g. password authentication)
  • Disclosure of public information or information that does not carry significant risks (directory listing on our downloads archive is a required feature! ;-))
  • Various policies for spam-fighting systems such as DKIM, SPF or DMARC
  • Issues in default configuration of access control rules (e.g. ACLs and record rules) - please open regular bug reports instead

If you have any doubt, please ask us first!

Thank YOU!

We are extremely grateful to the following security researchers who have worked with us to further improve the security of Odoo and the Odoo Online platform!

Researcher Year
Nils Hamerlinck 2016, 2017
Colin Newell 2015, 2016, 2017
Ondřej Kuzník 2015, 2016, 2017
Naglis Jonaitis
2015, 2016, 2017
Karim Boukabbouz, IBS North Africa 2015, 2017
Romain E Silva, Sysdream 2017
Adel Nettar, Sysdream 2017
CDL (@sxcurity) 2017
Cameron Dawe 2016
Xavier Alt 2016
Vibhuti Ranjan Vidyarshy Nath 2016
Mohammad Alhashash
2016
Nagaraju Repala
2016
Leonardo Pistone, Camptocamp France 2015
Mohamed Khaled Fathy 2015
Dipak Kumar Das 2015
Paul Catinean 2015
Muhammed Gamal Fahmy 2015
Openinside Co.  2015
ONESTEiN / Glasswall 2015
Sven Schleier, KPMG Management Consulting, SG 2015
Ondřej Kuzník & Craig Gowing, credativ Ltd 2015
Daniel Lawson 2014
​"diesenfranz" ​2014
Vo Minh Thu ​2013
Bastian Ike ​2013

The Security Team would also like to thank the following individuals for their contributions (in no particular order):
Ye Yint Min Thu Htut, Leonardo "LeartS" Donelli, Huzaifa Jawaid, Aaron Devaney, Caleb Kinney, Christophe Hanon, Cédric Krier