Skip to Content

Odoo security: login attempts happen every day, and AI will multiply them

What automated attacks are looking for, why they will become more numerous and capable, and the measures to protect an Odoo installation

Someone is already knocking

Anyone running Odoo instances reachable from the internet can see it in the logs, if they look: requests that come from no real user, at any hour, every day.

The systems we look after receive constant attempts too. They are all alike: someone tries to log in with generic usernames such as admin, odoo, demo or root, and someone tries to use the page Odoo provides to create, copy and back up databases. So far, every attempt has been turned away.

There is nothing personal about it. Nobody picked that particular company: these are programs that sweep the internet looking for any Odoo that answers, and try the same things on all of them. It is probably nothing new either, and it happens to anyone with Odoo online. That is exactly why the question is not whether someone will try, but what they will find when they do.

And Odoo is an obvious target. It holds everything a company needs to operate: customers, suppliers, orders, invoices, price lists, contracts, often employee data as well. One system, one database, and with the wrong configuration a single door to open.

The biggest door: the database manager

Every self-hosted Odoo has a page, at /web/database/manager, where databases are created, copied, deleted, downloaded and restored. During installation it is handy. In production it is the biggest door you can leave open: a backup downloaded from there holds the whole company in a single file, and one click on "Delete" erases it.

Odoo says so itself in the official documentation: it is "strongly recommended to disable the Database Manager for any internet-facing system", because it is a development and demo tool that "is not designed for use in production, and may even expose dangerous features to attackers" (Odoo 18 documentation, Database Manager Security).

When it stays on, only one thing protects it: the master password. And there is a detail few people know. As long as the master password is still the default one, whoever uses the manager first gets to choose it, and with it they can create, copy, download or delete databases. We checked this in the Odoo source code, from version 16 to 20, and the documentation puts it in its own way: until the password is set, the installation "is accessible to anyone on the internet" (Reset the master password). A freshly installed Odoo put online with its out-of-the-box settings belongs to whoever gets there first.

This is not a theoretical problem, and it is not new:

  • In 2017 Odoo published an advisory about a scanning campaign that looked for Odoo servers on the internet, listed their databases and tried to log in with admin/admin. Where it got in, it installed a malicious module to run commands on the server (ODOO-SA-2017-01-27-1).
  • Vulnerability scanners look for it on purpose. Tenable, for example, rates a manager without a master password as critical, because it lets anyone dump existing databases, set a master password or restore a compromised database (plugin 114372).
  • In February 2026 CVE-2026-25137 was published, with a severity score of 9.1 out of 10: in Odoo installations on NixOS the master password was not kept, and the manager was open to anyone, who could download or delete the entire database (NVD). A packaging mistake, not an Odoo one, but the target is always the same.

And even with a strong master password, leaving the manager reachable means giving anyone a place to try it, with no limit on attempts. An armored door is still a door: better not to have one on the street.

Why it will get worse: attacks are becoming industrial

The attempts we see today are crude: scripts repeating the same moves, with predictable usernames and default passwords. They only work against those who left the door open. The point is that the tools used to build them are changing.

In November 2025 Anthropic, the company that develops the Claude models, published an account of an espionage campaign it had detected and stopped in mid-September, attributed with high confidence to a state-sponsored group. The attack targeted roughly thirty organizations, including major technology companies and government agencies, and succeeded in a handful of cases. What was new was the method: the attackers had an AI agent carry out 80-90% of the operations on its own, from reconnaissance to vulnerability discovery to data exfiltration, with human involvement limited to a few key decisions and a request rate the report calls "physically impossible" for a human (Anthropic report, November 2025).

The report's conclusion is the one that concerns everyone: the barriers to performing sophisticated cyberattacks "have dropped substantially" and will keep dropping, and less experienced, less resourced groups can now potentially perform large-scale attacks. The same report acknowledges a limitation: the AI overstated its findings and sometimes made them up, which for now holds back fully autonomous attacks. For now.

Security professionals point the same way. In its predictions for 2026, Trend Micro speaks of "the true industrialization of cybercrime", with AI agents that "will discover, exploit, and monetize weaknesses without human input" (Trend Micro press release, November 25, 2025). It is a forecast, not a measurement, and it comes from a company that sells security; but it is consistent with what the documented cases already show.

For anyone with Odoo online the consequence is simple. When trying costs almost nothing, nobody picks targets anymore: everything is tried, on everyone, all the time, and better and better. A configuration mistake that yesterday could go unnoticed for months will, in all likelihood, be found sooner, and the same goes for a newly published vulnerability. "Good enough" security stops being good enough, because more and more people are knocking, and they are getting better at it.

What to do: the checklist

The official Odoo documentation has a chapter on security, and it opens with a sentence worth remembering: securing an information system "is a continuous process, not a one-shot operation", and you are only as secure as the weakest link (Security). What follows is the list we apply, split in two: what has to be done right away, and what separates an installation that works from one that is solid.

It applies to self-hosted Odoo, on your own server or in the cloud. On Odoo Online and Odoo.sh many of these aspects are handled by Odoo, while users, access and modules remain yours.

To do today

1. Turn off the database manager. In the configuration file, list_db = False blocks database selection and management, and dbfilter (together with db_name) tells Odoo which database to serve. On top of that, the proxy must refuse anything starting with /web/database. These are the recommendations of the official documentation. Creating, copying and backing up databases becomes a job for the system administrator, done on the server, not from a web page.

2. A real master password. Even with the manager turned off, the master password must be changed from its default value: random, long, different for each installation and kept in a password manager. In the configuration file it is better to write its hash rather than the plain text: Odoo accepts it, and whoever reads the file does not learn the password.

3. Odoo must not answer directly from the internet. In front of Odoo there should be a proxy (nginx, for example) handling HTTPS with a valid certificate, and Odoo should listen only on the local interface, with its ports (usually 8069 and 8072) closed from the outside. A firewall on the server leaves open only what is needed: usually SSH, HTTP and HTTPS. There is no point in guarding the front door if the service entrance is left open.

4. No admin, no default passwords. The documentation is explicit: unique logins and strong passwords for all administrators, "never" admin/admin, not even on test environments, and no demo data on internet-facing servers, because it contains well-known users and passwords (Security).

5. Two-factor authentication for every internal user. It is already in Odoo, Community edition included: the Two-Factor Authentication (TOTP) module adds the code from an app, and the 2FA by mail module lets you make it mandatory for everyone, with a code by email for those who have not set up the app yet. A stolen password, on its own, is no longer enough.

To do properly

6. A database user with minimal privileges. The PostgreSQL user Odoo connects with "must not be a superuser", and to make the manager completely unusable it should not even be able to create databases (documentation). If Odoo were compromised, the damage would stay confined to its own database.

7. Stop those guessing passwords. Odoo logs every login, successful or failed, with the user and the source address, and the documentation suggests feeding these logs to tools such as fail2ban to block anyone who fails too many times (Blocking Brute Force Attacks). Odoo also has its own slowdown after a series of failed attempts from the same address, but it only works properly if the proxy is configured correctly (proxy_mode): otherwise Odoo sees everyone coming from the same address, the proxy's.

8. Update. Install the updates for your version regularly, as the documentation recommends, and do not stay on versions that no longer receive fixes. If finding and exploiting flaws becomes a job for machines, it is reasonable to expect a published flaw to be tried at scale ever sooner: those who update late stay exposed longer.

9. Backups you can actually use. Daily backups of the database and the attached files, copied to an archive server that the Odoo server "cannot reach" (documentation): if someone gets into the server, they must not be able to delete the copies as well. And a backup is only worth something if restoring it has been tested.

10. Keep the logs, and read them. Odoo, proxy and database logs should be kept long enough to reconstruct what happened, even weeks later: a silent intrusion is often discovered late. And someone, or something, has to read them: repeated attempts on the manager or on logins are a signal not to ignore.

11. API keys and integrations under control. Each integration with its own API key, tied to a user with only the permissions it needs, and keys no longer in use revoked. A forgotten key is a password nobody is watching.

12. Third-party modules with judgment. An installed module runs with Odoo's permissions. The 2017 campaign got in precisely by installing a malicious module (ODOO-SA-2017-01-27-1). Before installing a module: who publishes it, who maintains it, what it does.

13. Production separate from testing and staging. Test and staging environments on different machines from production and with the same protections, as the documentation suggests: they often hold a copy of the real data, but are guarded less carefully.

The one-minute test

Three checks anyone can run on their own Odoo, from a browser, without touching anything:

  1. Open https://your-domain/web/database/manager. If the page for creating, copying or backing up databases appears, the manager is reachable by anyone. If it appears but says the manager has been disabled, it is off but the page is still exposed: the block in the proxy is missing. The right answer is an error page.
  2. Open http://your-domain:8069. If Odoo answers, the server can be reached directly, bypassing the proxy and its HTTPS. The right answer is no answer at all.
  3. Ask yourself: when was restoring a backup last tested? If the answer is "never", the backup is a hope, not a protection.

If even one of these checks fails, or if you do not know who should notice an intrusion attempt on your Odoo, it is time to take a look.

We can do it for you: we review the security of your Odoo installation, from configuration to access, from backups to logs, and give you the list of what to fix, in order of priority. It is a paid service: the cost depends on the installation and we define it after an initial analysis. Contact us.

Security is not a feature you install once: it is a habit. Attacks will become more numerous and more capable; a well-configured, updated and monitored Odoo is still a hard target, and that is exactly the kind those who try everything on everyone tend to give up on.

news November 7, 2026
Archive
Sign in to leave a comment
Odoo 20 offline: what really works without a connection and what the limits are
We tested Odoo 20 offline mode: what you can do, what stays blocked and three behaviors to know before using it in your company.