CVE-2026-39946: SQL Injection in OpenBao PostgreSQL Secrets Engine via Unquoted Schema Identifiers

OpenBao is an open-source identity-based secrets management system. The PostgreSQL database secrets engine manages dynamic database credentials. This engine creates temporary database roles and revokes their privileges when their lease expires.

Version 2.5.3 resolves a security flaw in this revocation logic. The engine fails to sanitize database schema identifiers during the privilege revocation process. This flaw maps to CWE-89, representing an improper neutralization of special elements in an SQL command.

The vulnerability exposes administrative database operations to SQL injection. The OpenBao management user typically operates with elevated database privileges, such as SUPERUSER or CREATEROLE. An attacker who exploits this vulnerability executes arbitrary SQL under this privileged context.

The privilege revocation process in OpenBao relies on dynamic SQL generation. When dynamic roles expire, OpenBao generates SQL REVOKE statements to remove access privileges before deleting the role. This cleanup process must query the database to identify which schemas the role currently has access to.

The system queries PostgreSQL system catalogs to retrieve these schema names. The code assumes that data returned from database system catalogs is inherently safe. It treats these catalog responses as trusted input and uses them directly in string formatting operations.

The specific flaw occurs because the trusted input is passed to fmt.Sprintf without utilizing a dedicated identifier quoting function. While the role name is correctly quoted, the schema name is interpolated as raw text. This bypasses the typical parameterization requirements for database identifiers, allowing control characters within the schema name to break out of the intended SQL syntax.

The vulnerability resides in plugins/database/postgresql/postgresql.go within the defaultDeleteUser function. This function constructs the array of REVOKE statements required to clean up a managed role. The string formatting directly references the schema variable.

revocationStmts = append(revocationStmts, fmt.Sprintf(
    `REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA %s FROM %s;`,
    (schema), // VULNERABLE: Direct interpolation of the schema variable
    dbutil.QuoteIdentifier(username))) // Correctly quoted

The fix applied in commit 80693a46ebb4fc2455f1c51ed1dd853b28c2fd77 addresses this directly. The patched code wraps the schema variable in the dbutil.QuoteIdentifier() function, ensuring that the schema name is properly escaped before interpolation.

revocationStmts = append(revocationStmts, fmt.Sprintf(
    `REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA %s FROM %s;`,
    dbutil.QuoteIdentifier(schema), // FIXED: Schema is now properly quoted
    dbutil.QuoteIdentifier(username)))

This fix is mechanically complete. The addition of dbutil.QuoteIdentifier guarantees that schema names are treated strictly as identifiers by the PostgreSQL parser. Any embedded control characters, such as double quotes or semicolons, are escaped, neutralizing the SQL injection vector.

Exploitation requires specific prerequisites. The attacker must possess enough privileges to create or alter database schemas within the managed PostgreSQL instance. This limits the attack surface to authenticated database users with specific grant combinations.

The attacker constructs a malicious payload by creating a new schema with a crafted name. The schema name must contain a double quote to close the identifier string, a semicolon to terminate the REVOKE statement, and the malicious SQL statement to execute. A functional payload resembles public"; DROP TABLE users; --.

When OpenBao attempts to clean up a managed role, it fetches the malicious schema name from the database. It interpolates the name into the REVOKE command. The resulting query string sent to PostgreSQL evaluates to REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA "public"; DROP TABLE users; -- FROM "managed_role";.

The injected command runs under the context of the OpenBao management user. PostgreSQL processes the statement as multiple commands. The initial REVOKE executes against the public schema, followed immediately by the execution of the injected DROP TABLE command.

Successful exploitation grants the attacker the ability to execute arbitrary SQL commands with the privileges of the OpenBao management role. Because this role typically requires high privileges to manage users and grants, the attacker gains near-administrative control over the target database.

The CVSS v4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N) reflects these conditions. The Attack Requirements (AT:P) and Privileges Required (PR:H) metrics designate the high barrier to entry. The Subsequent Confidentiality (SC:H) metric captures the severe impact on the database environment once the injection occurs.

The probability of exploitation in the wild remains extremely low. The EPSS score is 0.00028, placing it in the 7.89th percentile. There is no evidence of active exploitation, and the vulnerability is not listed in the CISA KEV catalog.

The primary remediation strategy is an immediate upgrade. System administrators must upgrade OpenBao to version 2.5.3 or later. This version contains the fully verified patch that implements correct identifier quoting for schema names.

Administrators who cannot immediately upgrade must implement temporary mitigations. The primary defense involves auditing existing database schemas for anomalous names. Queries should identify any schema names containing quotes, semicolons, or standard SQL keywords.

Organizations must also review and enforce the principle of least privilege within the database. Standard database users should be restricted from creating new schemas. While the management user requires elevated permissions to operate, its scope should be strictly limited to necessary administrative domains.