☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 8.7 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H 🐛 CWE-284
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2021-23186

CVE-2021-23186 Vulnerability in Odoo
📅 PUBLISHED: 2023-04-25 00:00 UTC 🔄 UPDATED: 2026-10-11 17:42 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.64%
👁️
0.64% probability
16.1× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1190
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS VECTOR BREAKDOWN 8.7
AV: N Attack Vector Network
AC: L Attack Complexity Low
PR: H Privileges Required High
UI: N User Interaction None
S: U Scope Unchanged
C: H Confidentiality High
I: H Integrity High
A: H Availability High
8.7
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2021-23186 is a sandboxing flaw in Odoo Community and Odoo Enterprise versions 15.0 and earlier that permits authenticated administrators to access and modify database contents belonging to other tenants in a multi-tenant deployment. Attackers able to obtain a valid administrative account in one tenant can read and alter data across all tenants, effectively breaking the multi-tenancy isolation boundary. With a CVSS score of 8.7, the flaw is high severity and poses a critical confidentiality and integrity risk to hosted Odoo environments. Patch availability is claimed by a single source (Debian) but has not been independently confirmed.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Technical Analysis

The vulnerability is classified by the NVD as a "sandboxing issue" — a failure of the isolation mechanism designed to separate data and operations between distinct tenants in an Odoo multi-tenant deployment. Odoo's multi-tenant architecture typically relies on per-tenant databases with an application-level routing layer that directs authenticated sessions to the correct backend. The flaw lies in the failure of this sandbox/routing boundary: an authenticated administrator in one tenant context can cross the boundary and issue operations against another tenant's database.

From the NVD description, the affected actors are "authenticated administrators" — meaning the privilege required is the highest level of an individual tenant, but not cross-tenant administrative rights. The attack vector is network-based (CVSS AV:N) with high attack complexity listed as low (AC:L); however, the privileges required are high (PR:H — an admin account). The scope is unchanged (S:U) — the compromise does not extend outside the Odoo application's declared security scope — yet the confidentiality and integrity impacts are both rated high.

The mechanism is one of horizontal privilege escalation combined with broken tenant isolation. The vulnerability class is Improper Access Control (CWE-284): the application fails to enforce that a given authenticated principal is only permitted to interact with the data objects associated with its own tenant. In practical terms, this could manifest as insufficient tenant context propagation in internal APIs, database connection/RPC layer mixing, or weakness in the record-rule/ir.rule enforcement logic. The NVD description does not disclose specific function names, class names, or URL endpoints to have been implicated, so granular code-level detail is unavailable from authoritative data. What is known: the sandbox — the code path that mediates all interactions with tenant-owned data — does not consistently verify tenant affiliation before permitting read/write database operations.

Technical detail on the exact root cause is insufficiently disclosed in the description. It is not specified whether this is a REST API authorization lapse, an RPC-layer routing weakness, or a database cursor scoping error. The description's use of "sandboxing" suggests the intended isolation uses a sandbox context that failed in specific execution paths.

Exploitation Scenarios

No public PoC is available; the attack chain is inferred from the vulnerability class and NVD description.

  1. Reconnaissance and target identification: An attacker identifies an Odoo instance (versions ≤ 15.0) hosting multiple tenants via public internet scanning (e.g., Shodan search for Odoo banner). The target is valuable because a single Odoo deployment can serve dozens or hundreds of distinct business tenants. The attacker must first obtain a tenant-admin credential — through phishing, credential stuffing, insider compromise, or prior exploitation of a lower-privileged flaw. The vulnerability does not remove the need for an admin account; it multiplies its impact.

  2. Trigger mechanism: Once authenticated as an administrator in tenant A, the attacker submits a legitimate privileged request within tenant A's administrative console, but the request is crafted to operate on a resource belonging to tenant B. Because the sandbox fails to verify tenant isolation, the application accepts the cross-tenant target instead of rejecting it. The precise request structure (API call names, endpoint paths) is not disclosed in public CVE data; however, the flaw class is a missing access-control check on tenant scoping.

  3. Payload/execution at class level: The payload is a crafted request from an admin session that references a foreign tenant identifier directly (e.g., a database record ID, tenant-specific object handle, or inter-tenant routing parameter). The sandboxing issue permits this reference to be resolved against the foreign tenant's database. Execution yields read and write access to the foreign tenant's records — including but not limited to contact records, sales orders, accounting data, user credentials, configuration, and custom modules.

  4. Post-exploitation impact: With write access to other tenants' databases, the attacker can exfiltrate sensitive business and personal data, modify financial records, add backdoor accounts in other tenants, install malicious modules or cron jobs, and pivot to additional persistence. In a shared hosting scenario, the attacker can sequentially compromise every tenant on the platform. The kill chain ends with full multi-tenant data dominion under a single tenant's admin identity.

Because the vulnerability is exploitable only with an admin account, it is less likely to be mass-exploited by opportunistic scanners; instead, it is a severe escalation lever once a foothold in any tenant is achieved.

Impact Assessment

The CVSS base score of 8.7 reflects High confidentiality impact, High integrity impact, High privileges required, and No user interaction. The environment would typically be a multi-tenant-complex scenario (CVSS environmental subscore could raise or lower this depending on deployment specifics).

Business impact is substantial for SaaS providers and system integrators running Odoo as a multi-tenant platform: the core value proposition of tenant isolation is voided. A compromise in one customer's org can surface data from all other customer orgs — creating cascading regulatory violations (GDPR, HIPAA, PCI-DSS depending on vertical), contractual breach, class-action exposure, and customer trust erosion. The attack does not require user interaction (UI:N), making silent cross-tenant exfiltration feasible. Blast radius spans every database bound to the compromised Odoo instance; there is no stated limitation on which tenants are reachable. The integrity impact is likewise severe: records can be altered without any audit trail visible to the target tenant — a determined attacker could subtly corrupt financial ledgers or stock levels across many tenants, causing follow-on operational damage.

Availability is not directly impacted (A:H is not listed in the vector — availability is either not scored or lower), meaning the primary threats are confidentiality and integrity. Nonetheless, tampering with data at scale can create business interruption downstream.

Detection Guidance

The following detections are based on the vulnerability class (privileged cross-tenant access) and general Odoo attack patterns. No vendor-specific exploit signatures are public. Detections should be tuned to local environment.

Sigma Rule

title: Suspected Cross-Tenant Access Attempt Against Odoo
id: 6a1cd4d0-9f3a-4c8e-b2a5-0b4e7f68d3a1
status: experimental
description: Detects authenticated Odoo admin sessions referencing resources across tenant boundaries, indicative of CVE-2021-23186 exploitation.
logsource:
  category: application
  product: odoo
  service: server
detection:
  selection_admin:
    user.role: "admin"
  selection_cross_tenant:
    event.action|contains: "read"
    event.outcome: "success"
    db.tenant: "internal"
    request.path|contains: "web/dataset/call"
  selection_anomaly:
    request.url_extension|endswith: "/jsonrpc"
  condition: selection_admin and (selection_cross_tenant or selection_anomaly)
  timeframe: 15m
falsepositives:
  - Legitimate cross-tenant maintenance operations performed by platform administrators
  - Odoo native multi-database routing operations
level: high
tags:
  - attack.t1190
  - cve.2021.23186
  - capec.1

YARA Rule

rule Odoo_CVE_2021_23186_Cross_Tenant_Access
{
    meta:
        author = "ValtersIT Threat Intel"
        description = "Detects log patterns and code hints indicative of cross-tenant database access in Odoo"
        cve = "CVE-2021-23186"
        date = "2025-01-01"
        severity = "high"
    strings:
        $log1 = "Warning! Access to database of other tenant" ascii wide
        $log2 = "MultitennantError" ascii wide
        $log3 = "access denied to database with id" ascii wide
        $log4 = "calling method on different tenant" ascii wide
        $log5 = "cross-database read" ascii wide
        $log6 = "AnotherUser tenant access" ascii wide
        $code1 = "db_list" ascii
        $code2 = "session.cr" ascii
    condition:
        uint16(0) == 0x5A4D and 2 of ($log*) or 1 of ($code*)
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"Odoo CVE-2021-23186 Potential Cross-Tenant Admin Access"; flow:established,to_server; content:"POST"; http_method; content:"/web/dataset/call_kw"; http_uri; content:"&quot;params&quot;"; http_client_body; content:"&quot;model&quot;"; http_client_body; content:"&quot;method&quot;"; http_client_body; pcre:"/dbname|\"db\"/i"; detection_filter:track by_src, count 5, seconds 60; metadata:service http; reference:cve,2021-23186; classtype:attempted-admin; sid:10023186; rev:1;)

Elastic Detection

sequence by process.entity_id with maxspan=5m
  [ authentication where user.name == null and message like "*login*" ]
  [ network where process.name == "odoo" and destination.port == 8069 and http.request.method == "POST" ]
  [ file where event.action == "read" and file.path like "*odoo*" and file.extension == "db" ]

Splunk SPL Query

index=odoo sourcetype=odoo:server
| search (user.role="admin" OR "access_rights=admin")
| search ("dbname" OR "db_name" OR "tenant")
| search NOT (user.name="odoo_su")
| stats count values(host) as source_host values(db) as target_db by user.name, src_ip
| where count > 10

Wazuh OSSEC Rule

<group name="odoo,">
  <rule id="100231" level="12">
    <decoded>true</decoded>
    <field name="log_type">odoo</field>
    <match>cross-tenant</match>
    <regex>admin</regex>
    <description>Odoo admin user attempting cross-tenant data access - CVE-2021-23186</description>
    <group>authentication_failures,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 — CLAIMED (single source — Debian — claims a fix exists; not independently confirmed).

The Odoo project itself has not issued a formally published CVE-2021-23186 patch reference in the data provided. Administrators should treat the Debian claim as a signal to check their distro package repository rather than as a confirmed vendor fix. The recommended actions:

  1. Immediate mitigations (if unpatched):

    • Restrict administrative account creation and review all admin accounts for anomaly.
    • Enable Odoo's two-factor authentication for all admin accounts to reduce credential-based takeover.
    • Place Odoo behind an application-level firewall and restrict admin UI access to allowlisted IP ranges.
    • Enable database-level auditing and log all cross-schema queries.
    • Reduce admin-console exposure by forcing VPN for administrative access.
  2. Patch/upgrade steps:

    • Check Debian package python3-odoo for patched version (details not listed; query apt-cache policy odoo).
    • Contact Odoo support/SaaS provider to ascertain patched build for your version.
    • If using Community, watch the official Odoo repository for a security release post-15.0 (16.0+ likely contains the fix).
    • Apply the fix in a staging environment first; verify tenant isolation with a synthetic cross-tenant read test.
  3. Long-term hardening:

    • Migrate to a supported Odoo version where the sandboxing flaw is closed.
    • Separate high-value tenants onto dedicated Odoo instances rather than one shared multi-tenant host.
    • Implement custom system — audit logs that flag any privileged access to objects outside an admin's owning tenant.
    • Run periodic tenant-isolation penetration tests in multi-tenant deployments.
    • Continuously monitor for CISA KEV enrichment; currently this CVE is not on the KEV list, but status can change if exploitation is observed.

References

  1. NVD Entry — https://nvd.nist.gov/vuln/detail/CVE-2021-23186
  2. Debian Security Tracker (patch claim) — https://security-tracker.debian.org/tracker/CVE-2021-23186
  3. MITRE CVE — https://www.cve.org/CVERecord?id=CVE-2021-23186
  4. CISA Known Exploited Vulnerabilities Catalog (CVE not listed) — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  5. Odoo Official Site / Security Advisory region — https://www.odoo.com/security

Threat actor activity: No known campaign or in-the-wild exploitation has been publicly reported for CVE-2021-23186 as of this report. EPSS score 0.00644 (47.5th percentile) indicates low but non-zero estimated exploitation probability. Given the high privilege requirement, opportunistic mass exploitation is unlikely; however, targeted attacks against multi-tenant Odoo service providers by actors with admin credentials are plausible and should be treated with caution.

👁️ SHODAN DORKS (THREAT HUNTING)

What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.

title:"Odoo"
http.title:"Odoo"
product:"Odoo" "Login"
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2021-23186/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.