A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c) in Google Brotli versions 1.0.3 through 1.2.0 on all platforms allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream. Users need to update any Brotli libraries or binaries between 1.0.3 through 1.2.0 to the latest available version: 1.0.10 or 1.1.1 or 1.2.1.

Repository: migration-planner Priority: High Location: pkg/duckdbparser/inventorybuilder.go:65 → pkg/duckdbparser/builder.go

Description: Users upload RVTools .xlsx exports which DuckDB ingests safely. The inventory builder then runs SELECT DISTINCT "Cluster" FROM vinfo to enumerate cluster names and feeds each returned string back into ~27 query templates via text/template - unescaped, inside single quotes. A spreadsheet cell like x' UNION SELECT readtext('/var/run/secrets/kubernetes.io/serviceaccount/token') -- becomes executable SQL on the second pass.

Security Impact:

DuckDB worker runs in-process inside planner-api pod without sandbox

DuckDB's readtext()/readblob() enable arbitrary file read on pod

Can access Kubernetes service-account token, Postgres credentials, agent-JWT signing key

Single tenant's xlsx upload escalates to full SaaS compromise

Fix Suggestion: Apply existing escapeSQLString() helper (already used for ClusterFeaturesQuery) to every string field of queryParams before template execution. Patch covers all 27 call sites in builder.go. Long-term: prefer DuckDB prepared statements over text/template. See patches/f007.patch.

DuckDB is a SQL database management system. DuckDB implemented block-based encryption of DB on the filesystem starting with DuckDB 1.4.0. There are a few issues related to this implementation. The DuckDB can fall back to an insecure random number generator (pcg32) to generate cryptographic keys or IVs. When clearing keys from memory, the compiler may remove the memset() and leave sensitive data on the heap. By modifying the database header, an attacker could downgrade the encryption mode from GCM to CTR to bypass integrity checks. There may be a failure to check return value on call to OpenSSL randbytes(). An attacker could use public IVs to compromise the internal state of RNG and determine the randomly generated key used to encrypt temporary files, get access to cryptographic keys if they have access to process memory (e.g. through memory leak),circumvent GCM integrity checks, and/or influence the OpenSSL random number generator and DuckDB would not be able to detect a failure of the generator. Version 1.4.2 has disabled the insecure random number generator by no longer using the fallback to write to or create databases. Instead, DuckDB will now attempt to install and load the OpenSSL implementation in the httpfs extension. DuckDB now uses secure MbedTLS primitive to clear memory as recommended and requires explicit specification of ciphers without integrity checks like CTR on ATTACH. Additionally, DuckDB now checks the return code.

Summary Content in filesystem is accessible for reading using sniffcsv, even with enableexternalaccess=false.

Details During a pentest, a security researcher was able to access environment variable data and other system data by using the sniffcsv function, even though we set enableexternalaccess to false.

PoC SQL SET enableexternalaccess=false; SET lockconfiguration=true;

SELECT Columns FROM sniffcsv('/proc/self/environ');

Impact Provides an attacker with access to filesystem even when access is expected to be disabled and other similar functions do NOT provide access.

For example select from readcsv('/proc/self/environ') fails with a permission error.

There seems to be two vectors to this vulnerability: 1. Access to files that should otherwise not be allowed. (We expect Permission Error: Scanning CSV files is disabled through configuration and not to provide any access to the file or even acknowledge that it exists). 2. The content from a (non-csv?) file can be read (e.g. /etc/hosts, proc/self/environ, etc) even though that doesn't seem to be the intent of the sniffcsv function (my understanding is it's intending to provide information about the shape of the data, but not provide the data itself).

Workaround It is possible to work around the issue by disabling the local file system using the disabledfilesystems setting: SQL SET disabledfilesystems='LocalFileSystem'; SET lockconfiguration=true;

SELECT Columns FROM sniffcsv('/proc/self/environ');

will result in Permission Error: File system LocalFileSystem has been disabled by configuration.

Fix A fix has been merged into the main branch (https://github.com/duckdb/duckdb/pull/13133), and will be released with the next DuckDB release.