CVE-2023-0620: HashiCorp Vault SQLI Vulnerability

CVE-2023-0620 Overview

CVE-2023-0620 is a SQL injection vulnerability [CWE-89] affecting HashiCorp Vault and Vault Enterprise versions 0.8.0 through 1.13.1. The flaw resides in the Microsoft SQL (MSSQL) Database Storage Backend. When an operator configures the MSSQL plugin through the local configuration, certain parameters are not sanitized before they are passed to the user-provided MSSQL database. An attacker with high privileges who controls those configuration parameters can inject and execute arbitrary SQL commands against the backing database. HashiCorp addressed the issue in Vault 1.13.1, 1.12.5, and 1.11.9.

Critical Impact
A privileged local actor able to influence MSSQL storage backend configuration parameters can execute arbitrary SQL statements, compromising the confidentiality, integrity, and availability of the database that stores Vault secrets.

Affected Products

HashiCorp Vault versions 0.8.0 through 1.13.1
HashiCorp Vault Enterprise versions 0.8.0 through 1.13.1
Deployments using the Microsoft SQL (MSSQL) Database Storage Backend

Discovery Timeline

2023-03-30 - CVE-2023-0620 published to NVD
2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-0620

Vulnerability Analysis

HashiCorp Vault supports multiple storage backends for persisting encrypted secret data. The MSSQL storage backend allows Vault to store its data in a Microsoft SQL Server instance. Configuration of this backend is performed through Vault's local configuration file, where operators supply parameters such as database name, schema, and table identifiers.

The vulnerability stems from missing input sanitization on these configuration parameters before they are concatenated into SQL statements executed against the MSSQL server. Because the affected values are interpolated directly rather than passed as bound parameters, an attacker who can alter the configuration can break out of the intended identifier context and append arbitrary SQL.

Exploitation requires local access and high privileges, which limits the attack surface to operators or accounts that can read or modify Vault's configuration. Once exploited, the injected SQL runs with the privileges of the database account used by Vault, which typically has full control over the schema that stores secret material.

Root Cause

The root cause is improper neutralization of special elements used in an SQL command [CWE-89]. Identifier fields supplied through the MSSQL backend configuration are not validated or escaped before being embedded into dynamically constructed SQL statements during plugin initialization.

Attack Vector

The attack vector is local. An attacker with the ability to modify Vault's configuration file or environment-supplied MSSQL backend parameters supplies malicious SQL fragments in place of expected identifiers. When Vault initializes the storage backend, the crafted strings are executed against the MSSQL instance, allowing the attacker to read, alter, or delete rows in any database the Vault service account can reach. No verified proof-of-concept exploit is publicly available, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.

Detection Methods for CVE-2023-0620

Indicators of Compromise

Unexpected SQL statements in MSSQL server logs originating from the Vault service account, particularly statements that reference identifiers outside the configured Vault schema.
Modifications to Vault configuration files containing quote characters, semicolons, or SQL keywords inside identifier fields such as database name, schema, or table.
New, altered, or dropped objects in the MSSQL instance backing Vault that do not correspond to a planned Vault upgrade or migration.

Detection Strategies

Audit Vault configuration files and Infrastructure-as-Code templates for MSSQL storage backend parameters containing non-alphanumeric characters in identifier fields.
Enable MSSQL auditing for the Vault service account and alert on Data Definition Language (DDL) statements or queries that touch tables outside the Vault schema.
Compare running Vault versions against the fixed releases 1.13.1, 1.12.5, and 1.11.9 during configuration management drift checks.

Monitoring Recommendations

Forward MSSQL audit logs and Vault operational logs to a centralized analytics platform and build correlation rules between Vault restarts and unusual SQL activity.
Monitor file integrity on Vault configuration paths and alert on unauthorized changes to the storage "mssql" block.
Track privileged access to Vault hosts, since exploitation requires local, high-privilege access to alter configuration.

How to Mitigate CVE-2023-0620

Immediate Actions Required

Upgrade HashiCorp Vault or Vault Enterprise to version 1.13.1, 1.12.5, or 1.11.9 or later.
Inventory all Vault deployments using the MSSQL storage backend and prioritize them for patching.
Restrict write access to Vault configuration files and environment variables to a minimal set of trusted operators.

Patch Information

HashiCorp resolved CVE-2023-0620 in Vault and Vault Enterprise versions 1.13.1, 1.12.5, and 1.11.9. Patch details and upgrade guidance are available in the HashiCorp Vault SQL Injection Advisory (HCSEC-2023-12). Downstream guidance for affected appliances is provided in the NetApp Security Advisory ntap-20230526-0008.

Workarounds

Until patching is complete, validate MSSQL backend configuration values against a strict allowlist of alphanumeric identifiers and reject any value containing quoting or statement-terminator characters.
Run the Vault MSSQL service account with the minimum privileges required, removing rights to create or drop objects outside the Vault schema.
Enforce change control and code review on all Vault configuration files and Infrastructure-as-Code modules that define storage backend parameters.

bash

# Verify the installed Vault version and confirm it is at or above a fixed release
vault version

# Example minimal MSSQL backend configuration using a strict identifier allowlist
# storage "mssql" {
#   server   = "mssql.internal.example.com"
#   port     = "1433"
#   database = "vault"     # alphanumeric only
#   schema   = "dbo"        # alphanumeric only
#   table    = "vault_kv"   # alphanumeric and underscore only
# }