Responsible Disclosure of Odoo Security Vulnerabilities

The safety of Odoo systems is very important to us not only because we use Odoo internally, but also because 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 handling vulnerability reports with the greatest attention, provided that the following rules are respected.

Top Researchers

Nils Hamerlinck (Trobz)

Colin Newell

IBS Group

See the full Hall of Fame

Reporting an issue

Please share the details of your security vulnerability privately by emailing our Security Team at security@odoo.com. Include as much information as possible: detailed steps to reproduce the problem, the versions affected, expected vs. actual results, and anything else that helps us react faster. We prefer text-based bug descriptions with a proof-of-concept over long videos.

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.

Heads up: Most reports we receive have little to no real impact and get rejected. Before reaching out, put together a proof-of-concept attack and take a critical look at what's really at risk. Also, please review the non-qualifying list below.

Our GPG key

4096R/8E877D2F

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

Download key (keys.openpgp.org) Download key (mirror)

Incident response procedure

You privately share the vulnerability details with our Security Team.
We acknowledge your submission and verify the vulnerability. Our first answer generally comes within 48h.
If valid and in scope, we request a CVE ID and share it with you as soon as it's assigned.
We work on a correction in collaboration with you.
We write a detailed Security Advisory covering the issue, its impact, workarounds and solution, and ask you to review it.
We privately broadcast the advisory and correction to stakeholders and Odoo Enterprise customers.
We give stakeholders and customers a reasonable delay to apply the fix before disclosing publicly (e.g. 2–3 weeks).
We disclose and broadcast the advisory and correction on our public channels.

Rules of engagement

We ask you to always:

Test exclusively on your own deployments, demo.odoo.com, or your own Odoo Cloud databases
Never access or modify data that isn't yours
Never attempt denial-of-service attacks or compromise services that aren't yours
Avoid automated scanners unless throttled to under 5 req/s (ideally 1 req/s) and rule-compliant
Use AI responsibly, always review results, never allow automatic submissions
Never use social engineering, phishing, or physical attacks without our prior consent
Keep vulnerabilities private until we've agreed on disclosure

In return, we commit to:

Not initiate legal action against you if you followed the rules
Process your report and respond as quickly as possible
Provide a fix as soon as possible
Work diligently with stakeholders to help restore system safety
Keep your identity private, unless you want to be credited

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 code execution or system access

Non-qualifying vulnerabilities — do not report

Unsupported Browser XSS: Cross-Site Scripting (XSS) that only works in outdated or unsupported browsers, or requires relaxed browser security settings.
Self-XSS: Attacks where a user must be tricked into actively copying and pasting malicious code into their own browser console.
Administrator "XSS": Script injection or XSS via file uploads (SVG, HTML, JS) by users with Administrator privileges. Administrators are effectively webmasters; security restrictions do not apply to them by design.
Rate-limiting / Brute-forcing: Lack of rate limiting or brute-force protections on components working as designed (e.g., password authentication, password resets).
User Enumeration: The ability to verify whether a username exists. This carries minimal risk and cannot be prevented without deteriorating the legitimate user experience.
File Path Disclosure: Revealing file paths on the server, which does not pose a significant risk or enable further attacks.
Clickjacking & Social Engineering: Phishing or clickjacking attacks that rely on social engineering to trick users, while the system itself is functioning as intended.
Tabnapping: Phishing attacks conducted by manipulating or navigating other browser tabs.
Logout CSRF: Forcing a user to log out via Cross-Site Request Forgery. This is not considered a plausible attack unless combined with Login CSRF, and is practically unpreventable.
Open Redirectors: These are merely one phishing vector among many (see our detailed explanation).
Reflected File Downloads: An attack technique requiring social engineering that is rarely practical in real-world scenarios.
CSV/XLSX Injection: Formula injection issues that require the victim to explicitly ignore and bypass security warnings in modern spreadsheet software (like Excel).
Referer Leaks: Leaking sensitive tokens via the Referer header to social media links, ads, or analytics requests. These are highly unlikely to be clicked or exploited within their validity period by mainstream providers.
Physical & Social Attacks: Any attack relying on physical access to a device or social engineering techniques against users or staff.
Non-permanent DoS/DDoS: Denial of Service attacks that exhaust resources (CPU, network, memory) simply by sending a sustained, massive stream of requests or packets.
Password Policies: Weaknesses related to password length, formats, character classes, or expiration policies.
Email Verification Bypass: Missing or partial verification of email addresses, or methods to circumvent the verification process.
Public Information Disclosure: Revealing public data or information with no significant risk (e.g., directory listings on our public download archives are a required feature).
Spam-fighting Policies: Missing or misconfigured DKIM, SPF, or DMARC records.
HSTS Configuration: The absence of HTTP Strict Transport Security (HSTS) headers, HSTS preloading, or HSTS policies.
Weak SSL/Ciphers: Specifics of weak ciphers or SSL deployments, as long as our benchmark remains an 'A' grade on SSLLabs with maximum compatibility for users.
SSRF Attacks: Server-Side Request Forgery, unless it allows access to special protocol handlers (e.g., file://) or successfully bypasses access controls on Odoo Cloud Hosting.
Default Access Control Rules: Issues stemming from the default configuration of access control rules (like ACLs and record rules). Please report these as regular bug reports instead.
Prior Account Takeover Required: Attack scenarios that require the attacker to have already compromised the user's Odoo account or email account. Please open regular bug reports for these.

If you have any doubt, please ask.

Reward

If you report a new security issue confirmed to be critical, we'll publicly thank you by adding your name to the Odoo Security Hall of Fame below.

Special thanks

Aaron Devaney, Abhishek Venkat, Ahsan Khan, Ameya Darshan, Caleb Kinney, Cédric Krier, Christophe Hanon, Deepali Malekar, Fazal Ur Rahman, Flo van der Vlist, Huzaifa Jawaid, Ismail Tasdelen, Ivan Yelizariev, Jairo Llopis, Khan Janny, Leonardo "LeartS" Donelli, Mohammed Israil, Mohamed Karara, Niyas Raphy, Riccardo Ancarani, Saddam Maniyar, Sameer Phad, Sébastien Versailles, "St00rm N00b", Suyog Palav, Tarun Manhor-Abhaychandra Chede, Tayler Porter, Ye Yint Min Thu Htut, Ziaur Rashid.

Responsible Disclosure Policy