CVE-2026-49360 in Recceinfo

Summary

by MITRE • 08/22/2026

Recce is a data-validation toolkit for enhanced dbt (data build tool) PR review. Prior to version 1.50.0, OSS server deployments that expose the server to an untrusted network without authentication are vulnerable to unauthenticated SQL execution through the query run API. When Recce is configured with a DuckDB-backed project, an attacker can use DuckDB filesystem primitives to read and write files accessible to the Recce server process. The impact depends on how Recce is deployed, but may include disclosure of local files, tampering with Recce/dbt artifacts, modification of browser-served static files leading to stored XSS, and modification of application files if those paths are writable. If Recce is run as root, file access occurs with root privileges inside that host or container. This issue has been patched in Recce `v1.50.0`. Users should upgrade to Recce `v1.50.0` or later. The patch restricts unsafe file read/write behavior for DuckDB-backed query execution and hardens the affected query path. Other warehouse adapters have also been reviewed for similar exposure. Users who cannot upgrade immediately should avoid exposing `recce server` to the public internet or any untrusted network. Recommended mitigations include enabling authentication or placing Recce behind an authenticated reverse proxy/VPN, running Recce as a non-root user, using a read-only application filesystem where possible, and ensuring that sensitive files or credentials are not available to the Recce process.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 08/22/2026

The vulnerability identified in Recce prior to version 1.50.0 represents a critical security flaw affecting open-source server deployments that expose their query run API to untrusted networks without adequate authentication mechanisms. This issue stems from an improper restriction of file system access when the tool is configured with a DuckDB-backed project, allowing attackers to leverage internal database primitives for unauthorized read and write operations on the host operating system. The core technical flaw lies in the lack of sandboxing or path validation within the query execution engine, which permits the injection of SQL commands that interact directly with local file paths through DuckDB's built-in filesystem functions. This behavior effectively bypasses application-level security controls because the database engine operates with the same privileges as the Recce server process itself, creating a direct bridge between the data layer and the underlying operating system infrastructure.

From an operational perspective, this vulnerability enables severe consequences depending on the deployment context and user permissions of the running service. An unauthenticated attacker can read arbitrary files accessible to the Recce process, leading to potential disclosure of sensitive configuration files, environment variables containing credentials, or proprietary business logic stored in local artifacts. Furthermore, the ability to write to specific directories allows for tampering with dbt project structures and application files. In scenarios where static web assets are served directly from writable directories within the container or host filesystem, an attacker can inject malicious scripts into these files, resulting in stored cross-site scripting attacks against users who subsequently load those pages. If the Recce service is executed with root privileges, which is a common misconfiguration in some containerized environments, all file operations occur with full administrative rights, potentially allowing complete compromise of the host system or adjacent containers through privilege escalation and lateral movement techniques.

This vulnerability aligns closely with CWE-94 Improper Control of Generation of Code (Code Injection) as it involves executing database commands that result in unintended side effects on the operating system, specifically categorized under CWE-78 OS Command Injection when considering the broader impact of file manipulation. Additionally, the exploitation path relates to ATT&CK technique T1059 Command and Scripting Interpreter via SQL queries, demonstrating how application-layer vulnerabilities can be leveraged for deeper infrastructure compromise. The lack of authentication on exposed endpoints further exacerbates the risk by removing a primary layer of defense, allowing remote attackers to initiate these attacks without prior access credentials.

To mitigate this vulnerability, organizations must prioritize upgrading Recce to version 1.50.0 or later, which implements strict restrictions on unsafe file read and write behaviors for DuckDB-backed query execution and hardens the affected API paths against such exploitation attempts. For deployments that cannot be immediately upgraded, it is imperative to ensure that the recce server endpoint is not exposed to public internet access or any untrusted network segments. Implementing authentication mechanisms at the application level or placing Recce behind an authenticated reverse proxy or virtual private network provides essential access control barriers. Operational hardening should also include running the service under a dedicated non-root user account with minimal permissions, configuring read-only filesystems for application directories where possible to prevent persistent modifications, and ensuring that sensitive credentials and configuration files are stored outside of accessible paths or protected by strict file system permissions.

Responsible

GitHub M

Reservation

05/29/2026

Disclosure

08/22/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!