CVE-2026-100406 in dbt-core
Summary
by MITRE • 10/15/2026
dbt enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications. From 2.0.0-alpha.0 until 2.0.0-alpha.5, dbt docs serve exposes the unauthenticated POST /api/v1/query endpoint in crates/dbt-docs-server/src/handlers/query.rs, which passes caller-supplied SQL to DuckDbViewsBackend::query_arrow() in crates/dbt-index-core/src/backend.rs without authorization or an allowlist. A client that can reach the server can invoke DuckDB filesystem-reading functions to read files available to the dbt process, including files outside the docs index directory. The server binds to localhost by default, but operators can expose it to a network through the host option or DBT_DOCS_HOST setting. This issue is fixed in version 2.0.0-alpha.5.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified involves an insecure direct object reference and improper authorization check within the dbt docs server component, specifically affecting versions from 2.0.0-alpha.0 through 2.0.0-alpha.5. The core issue resides in the POST /api/v1/query endpoint exposed by crates/dbt-docs-server/src/handlers/query.rs. This endpoint is designed to process SQL queries against data indexed by dbt, but it fails to implement any form of authentication or authorization mechanism. Consequently, any client that can establish a network connection to the server can submit arbitrary SQL statements without providing credentials or possessing valid session tokens. While the service binds to localhost by default, limiting immediate remote exploitation, operators who configure the host option or set the DBT_DOCS_HOST environment variable expose this endpoint to external networks, thereby creating a significant attack surface for unauthorized access.
The technical flaw lies in how user-supplied SQL is processed without validation against an allowlist of safe functions or commands. The submitted query is passed directly to DuckDbViewsBackend::query_arrow() located in crates/dbt-index-core/src/backend.rs. This backend interacts with the DuckDB engine, which supports a variety of built-in functions for file system operations. Because there are no restrictions on the SQL syntax allowed through this endpoint, an attacker can invoke DuckDB filesystem-reading functions such as read_csv or similar utilities that allow access to the underlying operating system's file structure. This lack of input sanitization and function whitelisting transforms a standard data querying interface into a vector for arbitrary file reads.
The operational impact of this vulnerability is severe, primarily constituting an information disclosure risk. An authenticated attacker who can reach the server endpoint can read any files accessible to the dbt process user account on the host system. This includes sensitive configuration files, environment variables containing secrets or API keys, source code repositories indexed by dbt, and potentially other critical data stored outside the intended docs index directory. The scope of access is determined by the privileges of the user running the dbt service, meaning that if the process runs with elevated permissions, an attacker could read system-wide sensitive files such as /etc/shadow or private SSH keys. This capability effectively bypasses standard file permission models because it leverages the application's existing high-level access to perform unauthorized reads.
From a classification perspective, this vulnerability aligns with CWE-287: Improper Authentication and CWE-434: Unrestricted Upload of File with Dangerous Type, although in this context, the danger is not uploading but rather unrestricted execution of file-read operations via SQL injection-like mechanisms. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1083: File and Directory Discovery and potentially T1560: Archive Collected Data if the attacker aggregates multiple files for exfiltration. The root cause is a failure in access control logic where the system assumes that because it is serving documentation data, all queries are benign, ignoring the potential for SQL-based side channels to interact with the host file system.
Mitigation strategies focus on both immediate remediation and long-term architectural improvements. The primary fix involves upgrading dbt to version 2.0.0-alpha.5 or later, where this authorization gap has been addressed by implementing proper access controls and restricting allowed functions within the query engine. For environments that cannot immediately upgrade, operators should ensure that the DBT_DOCS_HOST setting is not configured to expose the service beyond localhost (127.0.0.1). Additionally, running the dbt process with minimal required privileges using principles of least privilege can limit the scope of files an attacker might access even if they manage to exploit the endpoint. Implementing a reverse proxy or firewall rules that restrict access to this specific API path only from trusted internal sources provides another layer of defense in depth until the software is updated.