Odoo is a widely-used ERP platform with a complex backend. It’s a juicy target but also tricky due to its layered system, detailed user access controls, and extensive API usage. To pentest Odoo effectively, you need to combine automation with manual verification.

OdooMap is built for the job — a Swiss army knife for Odoo reconnaissance, enumeration, and brute-forcing. Check it out on GitHub: OdooMap

---

Disclaimer: This guide is for educational and authorized testing purposes only. Do not attempt to access or test systems you don’t own or have explicit permission to test.

Recon & Information Gathering

Before launching any attacks, first confirm the target application is running Odoo and determine its version. This will guide which exploits or weaknesses you should focus on.

odoomap -u https://example.com

• Identify Odoo version and instance details. For example, the Odoo instance running at http://localhost:8069/ reveals:

  Odoo detected (version: 18.0-20250624)
  

• Enumerate databases exposed by the instance:

  Found 1 database(s):
    - mydb
  

• Check for portal registration availability:

  Portal registration enabled at: http://localhost:8069/web/signup
  

• Enumerate publicly accessible endpoints and modules, which can indicate features in use and potential attack surfaces:

  - /web: Available (main web client)
  - /shop: Available (ecommerce)
  - /forum: Available (community forum)
  - /contactus: Available (contact page)
  - /website/info: Available (info pages)
  - /blog: Available (blog)
  - /events: Available (events management)
  - /jobs: Available (job postings)
  - /slides: Available (presentations)
  

Use this information to focus testing on modules and entry points that are actually live.

---

Enumerate Databases

Odoo instances may expose /web/database/selector or leak database names through API calls. But sometimes they don’t:

So you can brute-force with a wordlist:

odoomap -u https://example.com -n -N db-names.txt

Hints:

• Database names are case-sensitive but they are often lowercase, so your wordlist should cover business names, common names like odoo, prod, test, or even the target’s domain name.

---

Credential Brute-force

Next, bruteforce user credentials:

odoomap -u https://example.com -D discovered_db -b --usernames users.txt --passwords passwords.txt

• Usernames can be simple (demo, admin) or email addresses (e.g., test@target-domain.com).

• Accounts are database-specific, meaning each database has its own set of users. You must brute-force them separately using the -D database option.

• You can also try the default usernames/passwords lists by omitting --usernames and --passwords

Master Password Bruteforce:

Odoo’s databases are protected by a Master Password, if you obtain it, you will be able to control all the database management operations including creation, backup, duplication, and deletion.

odoomap -u https://example.com -M -p pass-list.txt

---

Model Enumeration

Once authenticated, enumerate models:

odoomap -u https://example.com -D db -U user -P pass -e

• This reveals all accessible models, including custom ones.

• Defaulted to 100, change limit using -l limit

• If your account lacks permissions, model listing may fail. In that case, OdooMap will automatically try to brute-force available models using its default wordlist, which you can replace like this:

odoomap -u https://example.com -D db -U user -P pass -e -B --model-file models.txt

Check for read/write/create/delete permissions:

odoomap -u https://example.com -D db -U user -P pass -e -pe

Why this matters:

• Permissions misconfiguration = Higher chance for data exfiltration or privilege escalation.

---

Data Extraction

If you have read access, start dumping interesting models:

odoomap -u https://example.com -D db -U user -P pass -d res.users,res.partner

You can also provide a file containing model names (make sure the file exists, or the filename itself will be treated as a model name):

odoomap -u https://example.com -D db -U user -P pass -d models.txt

• OdooMap checks if the specified file exists. If it does, it reads model names line by line. If it doesn’t, the input is treated as a single model name and attempt to dump it.

• Dumped models are saved to ./dump/model-name.json by default. To specify a directory, use -o ./dumped-data (folder, not file).

• The default record limit is set to 100. This means that once OdooMap has dumped 100 records from a specific model, it will automatically move on to the next model in the list. You can adjust this limit by using the -l limit option.

Example dump results:

---

Extending with Plugins

OdooMap isn’t limited to just dumping models. It comes with a plugin system that lets you extend functionality for custom security assessments.

To see what plugins are built into your version of OdooMap:

odoomap --list-plugins

CVE Scanner Plugin

The CVE Scanner plugin checks the detected Odoo version against known vulnerabilities from the NVD database. This is useful for quickly spotting low-hanging fruit.

odoomap -u https://example.com --plugin cve-scanner

Odoo Privilege Escalation Plugin

The old-odoo-privesc plugin attempts privilege escalation for Odoo versions < 15.0. If the target instance is outdated and the current account has insufficient privileges, this plugin can be used to escalate.

odoomap -u https://example.com -D db -U user -P pass --plugin old-odoo-privesc

---

Plugin Development

If the built-in plugins don’t cover your use case, you can easily develop your own, and we’d be happy to accept your pull requests to OdooMap.

Plugin Structure

All plugins are stored under:

odoomap/plugins/

Each plugin is just a Python file that inherits from the BasePlugin class and implements a standardized interface.

Required Methods

• get_metadata()
  Returns metadata about your plugin, such as name and description.

• run()
  The main logic of your plugin — what it actually does when executed.

Example:

Conclusion

OdooMap streamlines reconnaissance, enumeration, and exploitation efforts against Odoo instances by automating the discovery of databases, users, models, and permissions.
By combining version fingerprinting, targeted brute-forcing, and granular model analysis, it allows you to quickly identify exposed functionalities and misconfigurations that can lead to sensitive data exposure.