Responsible Disclosure Policy

For Odoo Security Vulnerabilities

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

. 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. We tend to prefer text-based bug descriptions accompanied with a proof-of-concept script/exploit, rather than long videos.

Our GPG Key

4096R/8E877D2F

Fingerprint: 9083 DE46 54A7 8DE3 CFAD D880 0B9E A35A 8E87 7D2F

Download: https://keys.openpgp.org/vks/v1/by-fingerprint/9083DE4654A78DE3CFADD8800B9EA35A8E877D2F

Download: https://download.odoo.com/files/odoo_security.asc

Reporting vulnerabilities via third-party websites is not acceptable, as it breaches the terms of our policy. If you are looking for a third-party reward, we may forward the list of CVE IDs assigned to you, so they can verify your rewards - but the issues have to be reported to us directly.

Please 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

[#what](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 the GPG key linked above.

Incident Response Procedure

You privately share the details of the security vulnerability with our Security Team by reporting an issue (see above)
We acknowledge your submission and verify the vulnerability. Our first answer generally comes under 48h.
If the vulnerability is valid and in scope, we request a CVE ID and give it to you as soon as it is assigned.
We work on a correction in collaboration with you.
We write a detailed Security Advisory describing the issue, its impacts, possible workarounds and solution, and we ask you to review it
We privately broadcast the Security Advisory and the correction to stakeholders and customers with an Odoo Enterprise Contract
We give stakeholders and customers a reasonable delay to apply the correction, before disclosing it publicly (e.g. 2-3 weeks)
We disclose and broadcast the Security Advisory and the correction on

[/r/security-issues](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 databases on Odoo Cloud (SaaS/SH)
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 could violate the previous rules (unless you can guarantee that they will be throttled to less than 5 requests/second, ideally 1 r/s, and will not break any other rules)
Never attempt non-technical attacks such as social engineering, phishing, or physical attacks against anyone or any system without our prior consent
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 work diligently with stakeholders and customers in order to help them restore the safety of their systems
We will not publicly disclose your identity if you do not want to be credited for your discovery

What to report?

Qualifying vulnerabilities - DO REPORT!

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 - DO NOT REPORT!

XSS vulnerabilities working only in unsupported/deprecated browsers, or requiring relaxed security settings
Self-XSS attacks requiring the user to actively copy/paste malicious code into their own browser window
"XSS attacks" by admins, e.g. via file uploads (SVG, HTML, JS, ...) or script injection. Administrators are webmasters, security restrictions don't apply to them, this is a feature.
Rate-limiting / Brute-forcing / Scripting of components working as designed (e.g. password authentication, password reset, etc.)
User enumeration (ability to verify that a username exists). Does not carry much risk, and can't be prevented without deteriorating the user experience.
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
Logout CSRF (no plausible attack unless combined with Login CSRF + not preventable e.g. via cookie tossing or cookie jar overflow)
Open redirectors, which are simply one vector for phishing among many others ([/page/security-nonvuln-redirectors]( see our detailed explanation))
Reflected File Downloads, another attack technique that requires social engineering and is not very practical
CSV/XLSX injection issues that require users to explicitly bypass security warnings in modern spreadsheet applications
Referer leak (including sensitive tokens) via social media links or ads/analytics requests - very unlikely to be clicked, or to be exploited within validity period by those mainstream companies!
More generally, attacks relying on physical or social engineering techniques will usually be rejected
Non-permanent Denial of Service (DoS) and distributed DoS (DDoS) that maintain resource exhaustion (cpu/network/memory/...) via a sustained stream of requests/packets
Password policies (length, format, character classes, etc.)
Missing or partial verification of email addresses, or ways to circumvent it
Disclosure of public information or information that does not carry significant risks (directory listing on our downloads archive is a required feature! ;-))
Spam-fighting policies and systems such as DKIM, SPF or DMARC

Absence of HTTP Strict Transport Security (HSTS) headers, HSTS preloading, and HSTS policies

Weak ciphers or SSL deployments details. Our benchmark is an A grade on [https://www.ssllabs.com/ssltest/analyze.html](SSLLab's test) yet a maximal compatibility with user browsers. We are currently phasing out TLS 1.0 on www.odoo.com, already done for our customer hosting services

SSRF attacks, unless they allow access to special protocol handlers (e.g. file://), or can be used in a working scenario to bypass access control on the Odoo Cloud Hosting (cfr [https://www.odoo.com/documentation/13.0/setup/deploy.html#security](deployment documentation))
Issues in default configuration of access control rules (e.g. ACLs and record rules) - please open regular bug reports instead
Attack scenarios that include a prior takeover of the user account or an email account of the user - please open regular bug reports instead

If you have any doubt, please ask us first!

Reward

If you report a new security issue that is confirmed to be critical (see the DO REPORT section), we will publicly thank you by adding your name to the Odoo Security Hall of Fame, on the right of this page.

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 Cloud platforms!

Researcher | Year |

Nils Hamerlinck

https://trobz.com/ | 2024, 2022, 2021, 2020, 2019, 2018, 2017, 2016 |

Colin Newell | 2017, 2016, 2015 |

[http://ibsgroup.io/](IBS Group) | 2019, 2018, 2017, 2015 |

Naglis Jonaitis | 2018, 2017, 2016, 2015 |

[https://github.com/sswapnesh](Swapnesh Shah) | 2019, 2018 |

Ondřej Kuzník | 2017, 2016, 2015 |

https://github.com/lebr0nli | 2024 |

Elliot Ward | 2024, 2023 |

Florent Mirieu de Labarre | 2019, 2018 |

Alexandre Moens | 2023, 2021 |

iamsushi | 2021, 2019 |

[https://github.com/ghostvirus62](Jayendra Yogi (ghostvirus)) | 2025 |

David Vidal) | 2025 |

[https://www.linkedin.com/in/shankar-biswas-53a4b2239](Shankar Biswas) | 2025 |

[https://www.linkedin.com/in/kristjan-tehu](Kristjan Tehu) | 2025 |

[https://www.linkedin.com/in/rafi-shapiro](Rafi Shapiro) | 2023 |

[https://github.com/tardo](Alexandre Díaz) | 2021, 2020 |

Yenthe Van Ginneken | 2019, 2018 |

[https://www.linkedin.com/in/fbpatel](Bhavin Fadadu) | 2023 |

[https://www.linkedin.com/in/niyas-raphy-2a9001139/](Niyas Raphy) | 2022 |

[https://www.linkedin.com/in/rifat-al-jubayer](Rifat Al Jubayer) | 2022 |

Andreas Perhab [https://www.wt-io-it.at/]((WT-IO-IT GmbH)) | 2021 |

Parth Gajjar | 2021 |

Theodoros Malachias | 2021 |

Ranjit Pahan | 2021 |

Iago Ruiz | 2021 |

Johannes Moritz (Cure53) | 2021 |

[https://www.linkedin.com/in/moezhemani/](Moez Hemani) | 2021 |

[https://linkedin.com/in/loctv](Loc Truong) | 2020 |

[https://www.linkedin.com/in/damien-lescos](Damien LESCOS) | 2020 |

Santosh Kumar Sha | 2020 |

Kennedy Sanchez | 2020 |

[https://www.huntr.dev/users/Anon-Artist/](Abhiram V) | 2020 |

Christopher Riis Bubeck Eriksen | 2020 |

"Raspina Net Pars Group" | 2020 |

Alessandro Innocenti | 2020 |

Holger Brunn

([https://hunki-enterprises.com](Hunki Enterprises BV)) | 2019 |

[https://github.com/MaioSource](Agustín Ezequiel Maio) | 2019 |

Emre Övünç | 2019 |

Lauri Vakkala (Silverskin) | 2019 |

P. Valov (SoCyber) | 2019 |

Nathanael ROTA (Capgemini) | 2019 |

Tomas Canzoniero | 2019 |

Subash SN (Appsecco) | 2019 |

Bharath Kumar (Appsecco) | 2019 |

Dipanshu Agrawal | 2019 |

Anıl Yüksel | 2019 |

Aitor Fuentes (kr0no) | 2019 |

Erwin van der Ploeg [https://odooexperts.nl]((Odoo Experts)) | 2018 |

Benoît Chenal (Excellium-services – Application Security) | 2018 |

Adan Álvarez (A2secure) | 2018 |

Bharath Kumar (Appsecco) | 2018 |

Subash SN (Appsecco) | 2018 |

Stéphane Bidoul (ACSONE) | 2018 |

[https://www.linkedin.com/in/mehmetuncer](Mehmet Tuncer) | 2018 |

Hugo Rodrigues | 2018 |

[https://github.com/moylop260](Moises Lopez) | 2018 |

[https://github.com/carlosdauden](Carlos Daudén), [https://www.tecnativa.com/](Tecnativa S.L.) | 2018 |

Andrew Grasso (Logic Supply) | 2017 |

Juba Baghdad | 2017 | Prakash Dhatti | 2017 |

JubaBaghdad | 2017 |

Romain E Silva (Sysdream) | 2017 |

Adel Nettar (Sysdream) | 2017 |

Azizul Hakim | 2017 |

"Ayrx" via SSD | 2017 |

Wolfgang Taferner [https://www.wt-io-it.at/]((WT-IO-IT GmbH)) | 2017 |

Corben Leo | 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 |

Special Thanks -

The Security Team would also like to thank the following individuals for their contributions to improve the security of Odoo users (in alphabetical order):

openerp.com

openerp.com

Details

Responsible Disclosure Policy

For Odoo Security Vulnerabilities

Incident Response Procedure

What to report?

Qualifying vulnerabilities - DO REPORT!

NON Qualifying vulnerabilities - DO NOT REPORT!

Responsible Disclosure Policy

For Odoo Security Vulnerabilities

Incident Response Procedure

What to report?

Qualifying vulnerabilities - DO REPORT!

NON Qualifying vulnerabilities - DO NOT REPORT!