CVE-2026-39946
SQL Injection in OpenBao PostgreSQL Engine Causes Role Revocation Failures
Publication date: 2026-04-21
Last updated on: 2026-04-24
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openbao | openbao | to 2.5.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-89 | The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-39946 is a moderate severity SQL Injection vulnerability in OpenBao's PostgreSQL database secrets engine affecting versions up to 2.5.2.
The issue occurs when OpenBao revokes privileges on a role but fails to properly quote schema names provided by PostgreSQL. This improper quoting can cause role revocation failures and, in rare cases, allow SQL injection attacks executed by the management user.
The vulnerability requires the attacker to have high privileges and does not require any user interaction.
It was originally discovered in HashiCorp Vault and has been fixed in OpenBao version 2.5.3.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in OpenBao's PostgreSQL database secrets engine could potentially impact compliance with standards like GDPR and HIPAA because it allows an attacker with high privileges to perform SQL injection attacks. This could lead to unauthorized actions within the database, risking confidentiality and integrity of sensitive data.
Although the vulnerability itself does not directly impact confidentiality, integrity, or availability, the potential for high confidentiality impact due to unauthorized access or manipulation of secrets could violate data protection requirements mandated by these regulations.
Mitigation by upgrading to OpenBao v2.5.3 or auditing database schemas to prevent unauthorized schema creation and privilege grants is essential to maintain compliance.
How can this vulnerability impact me? :
An attacker with high privileges can exploit this vulnerability to perform SQL injection attacks within the PostgreSQL database secrets engine.
This can lead to role revocation failures or unauthorized actions in the database secrets engine.
While there is no direct impact on confidentiality, integrity, or availability initially, the subsequent impact can be high confidentiality compromise.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability arises from improper quoting of schema names during role privilege revocation in OpenBao's PostgreSQL database secrets engine. Detection involves auditing database schemas and monitoring role revocation operations for failures or anomalies.
Specifically, you should audit table schemas to ensure no unauthorized or suspicious schemas exist, and verify that database users cannot create new schemas or grant privileges on them.
While no explicit commands are provided, typical detection steps could include running PostgreSQL queries to list schemas and privileges, such as:
- List all schemas: SELECT schema_name FROM information_schema.schemata;
- Check role privileges on schemas: SELECT grantee, privilege_type, table_schema FROM information_schema.role_table_grants WHERE table_schema NOT IN ('pg_catalog', 'information_schema');
Additionally, monitor OpenBao logs for role revocation failures or unusual SQL errors that might indicate exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
The vulnerability is fixed in OpenBao version 2.5.3. The immediate and recommended step is to upgrade OpenBao to version 2.5.3 or later.
As a workaround before upgrading, audit your database schemas and ensure that database users cannot create new schemas or grant privileges on them.
This reduces the risk of exploitation by limiting the ability of users to introduce malicious schema names that could trigger SQL injection during role revocation.