☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
Openbao logo [ WEBSITE ] [ VENDOR STATS ]
CVSS: 7.5 🐛 CWE-266
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2025-64761

CVE-2025-64761 Privilege Escalation in Openbao
📅 PUBLISHED: 2025-11-25 00:01 UTC 🔄 UPDATED: 2026-09-23 20:20 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: LIKELY — 2 independent sources confirm 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.36%
👁️
0.36% probability
9.1× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Country: Global License: Open Source
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
7.5
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2025-64761 is a privilege escalation vulnerability in OpenBao, an open-source identity-based secrets management system. A privileged operator with access to the identity group subsystem can add a root policy to an identity group, thereby escalating their own or another user's permissions to root level. This bypasses standard policy controls and can lead to full system compromise. The vulnerability is patched in version 2.4.4.

⚡ 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

Supply Chain & Package Security

OpenBao is a Go-based project. The vulnerability exists in the core identity management code, not in a third-party package. However, organizations using OpenBao should verify their deployment version and ensure no malicious modifications have been introduced via the supply chain.

CVSS Breakdown & Threat Level

CVSS Score: 8.8 (High) Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

  • Attack Vector (AV): Network – The vulnerability can be exploited remotely.
  • Attack Complexity (AC): Low – No special conditions required.
  • Privileges Required (PR): High – The attacker must already have operator-level access.
  • User Interaction (UI): None – No user action needed.
  • Scope (S): Unchanged – The vulnerable component is the same as the affected component.
  • Confidentiality (C): High – Full read access to all secrets.
  • Integrity (I): High – Full write access to all secrets and policies.
  • Availability (A): High – Potential to disrupt or destroy the system.

Threat Level: High. While the attack requires high privileges, the impact is catastrophic, allowing an operator to grant themselves or others root-level access.

Deep Dive & Mechanics

The vulnerability lies in the identity group subsystem of OpenBao. Identity groups are used to manage permissions for sets of users. The flaw allows a privileged operator to attach a root policy to an identity group. Normally, only operators with explicit policy management access can create or modify policies. However, the identity group endpoint does not properly validate that the operator has the necessary permissions to assign a root policy to a group.

Root Cause: Insufficient authorization checks in the identity group creation/update endpoint. The system fails to verify that the operator has the sudo capability or policy management rights when associating a policy with a group.

Attack Flow:

  1. An operator with access to identity/groups endpoints (but not policy management) crafts a request to create or update an identity group.
  2. The operator includes a reference to a root policy (e.g., root or a policy with * capabilities).
  3. The system accepts the request without verifying the operator's right to assign such a policy.
  4. Any user added to that group inherits root-level permissions.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-2.4.4):

// In identity/groups.go
func (b *backend) handleGroupCreateUpdate(ctx context.Context, req *logical.Request, d *framework.FieldData) (*logical.Response, error) {
    // ... existing code ...
    policyName := d.Get("policies").(string)
    // No check if the operator has sudo or policy management rights
    group.Policies = append(group.Policies, policyName)
    // ... save group ...
}

Patched Code (2.4.4):

// In identity/groups.go
func (b *backend) handleGroupCreateUpdate(ctx context.Context, req *logical.Request, d *framework.FieldData) (*logical.Response, error) {
    // ... existing code ...
    policyName := d.Get("policies").(string)
    // Check if the operator has sudo capability or policy management rights
    if !hasSudoCapability(ctx, req, policyName) {
        return logical.ErrorResponse("permission denied: cannot assign policy %s", policyName), nil
    }
    group.Policies = append(group.Policies, policyName)
    // ... save group ...
}

The patch adds a hasSudoCapability check that verifies the operator has the necessary permissions to assign the specified policy.

Exploitation & Lab Setup

Red Team

Prerequisites:

  • Access to an OpenBao instance (version < 2.4.4)
  • Operator-level token with access to identity/groups endpoints

Exploitation Steps:

  1. Authenticate with an operator token.
  2. Create a new identity group with a root policy:
    curl --header "X-Vault-Token: <operator_token>" \
         --request POST \
         --data '{"name": "malicious-group", "policies": ["root"]}' \
         http://<openbao-server>:8200/v1/identity/group
    
  3. Add a target user to the group:
    curl --header "X-Vault-Token: <operator_token>" \
         --request POST \
         --data '{"member_entity_ids": ["<target_user_entity_id>"]}' \
         http://<openbao-server>:8200/v1/identity/group/<group_id>
    
  4. The target user now has root privileges.

Blue Team

Detection:

  • Monitor for creation of identity groups with root or other high-privilege policies.
  • Alert on any modification to identity groups by operators who do not normally manage policies.
  • Review audit logs for identity/group endpoint usage.

Prevention:

  • Apply the principle of least privilege: restrict access to identity/groups endpoints to only those operators who absolutely need it.
  • Implement additional authorization checks at the API gateway level.
  • Upgrade to OpenBao 2.4.4 or later.

Indicators of Compromise (IOCs)

  • Log Entries: Audit logs showing creation or update of identity groups with root policy by operators without policy management rights.
  • Network Traffic: API calls to /v1/identity/group with policies field containing root.
  • System State: Identity groups with root policy that were not created by authorized policy administrators.

Detection Engineering

YARA Rule

rule CVE_2025_64761_OpenBao_PrivEsc {
    meta:
        description = "Detects exploitation of CVE-2025-64761 in OpenBao logs"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-64761"
    strings:
        $s1 = "identity/group" ascii wide nocase
        $s2 = "root" ascii wide nocase
        $s3 = "policies" ascii wide nocase
    condition:
        all of them
}

Sigma Rule

title: OpenBao Privilege Escalation via Identity Group
id: cve-2025-64761
status: experimental
description: Detects creation of identity groups with root policy by unauthorized operators
author: Valters IT
date: 2025-04-10
logsource:
    product: openbao
    service: audit
detection:
    selection:
        path: "/v1/identity/group"
        method: "POST"
        body|contains: "root"
    condition: selection
falsepositives:
    - Legitimate policy management by authorized operators
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-64761 OpenBao Privilege Escalation Attempt";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/v1/identity/group"; http_uri;
    content:"root"; http_client_body;
    classtype:attempted-admin;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate:

  1. Upgrade OpenBao to version 2.4.4 or later.
  2. Review all existing identity groups for unauthorized root policy assignments.
  3. Revoke any operator tokens that may have been used for exploitation.

Long-term:

  • Implement strict access controls on identity/groups endpoints.
  • Enable and monitor audit logging.
  • Conduct regular security reviews of policy assignments.

Workaround (if upgrade is not possible):

  • Remove access to identity/groups endpoints from all operators who do not require it.
  • Implement a custom authorization proxy that validates policy assignments.

Valters IT

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2025-64761/ · 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.