CVE-2026-25137: A Critical Look at the NixOS Odoo Database Exposure Vulnerability
Feb 04, 2026
Introduction
Odoo is a widely used open-source ERP and CRM platform, powering accounting, sales, HR, inventory, and custom business workflows for organizations around the world. While Odoo itself is a mature project, the way it is packaged and deployed can dramatically affect its security posture.
Recently, a serious vulnerability was discovered affecting Odoo installations on NixOS, where the database manager interface was publicly exposed without authentication. This flaw allowed any unauthenticated remote user to download or delete the entire database, including Odoo’s file store.
This post explains:
- What happened
- Why this vulnerability exists
- Why it only affects NixOS-based Odoo deployments
- How to detect exploitation
- And what this teaches us about configuration-driven systems and security
What Is Odoo’s Database Manager?
Odoo includes a database manager interface, accessible at:
/web/database
This interface allows administrators to:
- Create new databases
- Drop existing databases
- Backup and restore databases
- Manage database-level settings
The database manager is intended for development and administrative use, not for public exposure.
In most deployments:
- The database manager is disabled in production, or
- Protected by a master password, acting as a second line of defense
The Vulnerability: What Went Wrong?
Affected Versions
From NixOS 21.11 up to (but not including) 25.11 and 26.05, all NixOS-based Odoo packages had a critical flaw:
The database manager was publicly accessible with no authentication.
This meant anyone who could reach the Odoo instance could:
- Download the entire database
- Delete all databases
- Access the Odoo filestore (attachments, documents, invoices, etc.)
No credentials were required.
Why Authentication Failed on NixOS
To understand the root cause, we need to understand NixOS.
What Is NixOS?
NixOS is a Linux distribution built around:
- Declarative configuration
- Immutable system state
- Reproducible builds
Instead of editing config files directly, you describe your system in configuration files (usually configuration.nix), and NixOS builds the system from that description.
Key Property: Immutability
On NixOS:
- Applications cannot modify their own configuration files
- Files under /nix/store are read-only
- Runtime changes must be declared explicitly in Nix configuration
This design is powerful but it has consequences.
Why This Only Affects Odoo on NixOS
How Odoo Normally Protects the Database Manager
On most systems:
- Odoo auto-generates a master password
- Stores it in its configuration file
- Uses it to protect /web/database
If no password exists, Odoo prompts an authenticated administrator to set one.
What Breaks on NixOS
On NixOS:
- Odoo cannot write to its own config file
- The auto-generated master password cannot be persisted
- Even manually setting the password via the web UI is lost on restart
On restart, Odoo thinks no master password exists. The database manager becomes publicly accessible, prompts any visitor to set a password, and requires no authentication at all.
Result: The database is effectively world-readable and world-deletable.
How Bad Is This?
This is a full compromise vulnerability:
- Complete database exfiltration
- Permanent data loss
- Exposure of customer data, financial records, credentials, and uploaded documents
No logging barrier or authentication step. Any attacker who discovers the endpoint can exploit it within seconds.
Detecting Exploitation
If you ran a vulnerable version, you should assume compromise unless proven otherwise.
Check for Indicators of Access
Search your logs for requests to:
/web/database
Places to look:
- Web server access logs
- Odoo application logs
- Reverse proxy logs (NGINX, Traefik, etc.)
Signs of exploitation include database backup downloads, database deletion attempts, and unrecognized IP addresses accessing /web/database.
Fix Status
The vulnerability has been fixed in:
- NixOS 25.11
- NixOS 26.05
The fix ensures the database manager is no longer exposed by default and master password handling is compatible with NixOS’s immutable model.
If you are on an affected version, upgrade immediately, rotate all credentials, and restore from a known-good backup if possible.
A Brief Note on Odoo’s Security History
This incident is not isolated. Odoo has historically suffered from authentication bypasses, access control issues, file disclosure bugs, and insecure default configurations. Many of these vulnerabilities stem not from malicious intent, but from legacy design assumptions, development-focused features leaking into production, and complex configuration paths across different deployment models. This makes defense-in-depth and secure-by-default packaging especially critical.
Lessons Learned
1. Packaging Matters as Much as Code
The vulnerability was not caused by a single bad line of code it emerged from Odoo’s assumptions, NixOS’s immutability, and a missing integration layer between the two.
2. Development Features Must Be Locked Down
Any interface that can create, delete, export, or modify databases must never be exposed publicly.
3. Declarative Systems Need Explicit Security Modeling
In declarative systems like NixOS, security cannot rely on runtime mutations. All secrets, credentials, and access controls must be explicitly declared.
Conclusion
This vulnerability highlights a critical truth in modern infrastructure: secure software can become insecure through incorrect packaging and deployment assumptions.
If you run Odoo on NixOS, ensure you are on version 25.11 or later, audit your logs, and treat past exposure seriously. More broadly, never assume defaults are safe, and always review how software behaves in your operating system’s model.