CVE-2025-64429: DuckDB Information Disclosure Vulnerability

CVE-2025-64429 Overview

DuckDB is an in-process SQL Online Analytical Processing (OLAP) database management system. Starting with version 1.4.0, DuckDB introduced block-based encryption for on-disk databases. The implementation contains several cryptographic weaknesses that undermine confidentiality and integrity guarantees. DuckDB can fall back to an insecure pcg32 random number generator when producing cryptographic keys or initialization vectors (IVs). Attackers may downgrade encryption from Galois/Counter Mode (GCM) to Counter Mode (CTR) by modifying the database header, bypassing integrity checks. The flaw is tracked under [CWE-327: Use of a Broken or Risky Cryptographic Algorithm].

Critical Impact
Attackers can recover encryption keys, tamper with encrypted databases undetected, and read sensitive data from process memory due to failed key zeroization.

Affected Products

DuckDB 1.4.0
DuckDB 1.4.1
DuckDB versions prior to 1.4.2

Discovery Timeline

2025-11-12 - CVE-2025-64429 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-64429

Vulnerability Analysis

The DuckDB encryption implementation contains four distinct cryptographic weaknesses that compound to break confidentiality and integrity guarantees. The core issue is reliance on non-cryptographic randomness and missing validation of cryptographic primitives. When the OpenSSL implementation is unavailable, DuckDB falls back to the pcg32 pseudo-random number generator to produce keys and IVs. This generator is not cryptographically secure and its internal state can be recovered from observed outputs such as public IVs.

A second flaw affects memory hygiene. When DuckDB clears sensitive key material with memset(), compilers may optimize the call away as dead code because the buffer is not read afterward. Sensitive keys therefore remain resident on the heap and are exposed to any process-memory read primitive.

A third flaw is the absence of a return code check on OpenSSL's rand_bytes() function. A silent RNG failure produces predictable output without raising an error.

Root Cause

The vulnerabilities stem from insecure default behavior in the block encryption module introduced in DuckDB 1.4.0. The library trusted an internal fallback RNG (pcg32), did not use a compiler-safe memory clearing primitive, and did not validate cipher mode integrity guarantees encoded in the database header.

Attack Vector

An attacker with access to encrypted database files or process memory can exploit any of the four weaknesses. By observing publicly stored IVs, the attacker can reconstruct the pcg32 state and derive the key used to encrypt temporary files. By modifying header bytes, the attacker can downgrade the cipher mode from GCM to CTR, stripping the authentication tag and enabling silent ciphertext tampering. Memory disclosure primitives can extract residual keys that memset() failed to zeroize.

No working exploit code is publicly available. See the GitHub Security Advisory GHSA-vmp8-hg63-v2hp for technical details.

Detection Methods for CVE-2025-64429

Indicators of Compromise

Presence of DuckDB binaries at versions 1.4.0 or 1.4.1 in application inventories
Encrypted DuckDB database files with cipher mode header values indicating CTR when GCM was expected
Unexpected ATTACH statements in query logs specifying non-authenticated cipher modes
Missing or absent httpfs extension with OpenSSL support in DuckDB deployments

Detection Strategies

Inventory all installed DuckDB library versions across endpoints, containers, and data pipelines to identify vulnerable 1.4.x installs
Audit application source and configuration for calls to ATTACH that enable encryption without explicit cipher specification
Review database file headers programmatically to confirm the encryption mode matches the intended policy

Monitoring Recommendations

Log all DuckDB ATTACH and database creation events and alert on encrypted databases created by pre-1.4.2 binaries
Monitor process memory dumps and crash artifacts for DuckDB processes that may leak residual key material
Track deployment of the httpfs extension to ensure OpenSSL-backed cryptographic primitives are loaded at runtime

How to Mitigate CVE-2025-64429

Immediate Actions Required

Upgrade DuckDB to version 1.4.2 or later on all systems that read, write, or create encrypted databases
Rotate any cryptographic keys previously generated by DuckDB 1.4.0 or 1.4.1 and re-encrypt affected databases
Install and load the httpfs extension so DuckDB uses the OpenSSL implementation rather than the internal fallback
Explicitly specify authenticated cipher modes such as GCM on every ATTACH statement

Patch Information

DuckDB 1.4.2 disables the insecure pcg32 fallback for writing to or creating encrypted databases. The release replaces memset() with the MbedTLS secure memory clearing primitive, requires explicit specification of non-authenticated ciphers like CTR on ATTACH, and validates the return code from OpenSSL's rand_bytes(). See the DuckDB fix pull request #17275 and the GitHub Security Advisory GHSA-vmp8-hg63-v2hp.

Workarounds

Avoid creating or writing to encrypted DuckDB databases with versions prior to 1.4.2
Store DuckDB database files on filesystems with independent encryption at rest such as LUKS or BitLocker
Restrict process memory access to DuckDB workloads through operating-system-level isolation and least-privilege user contexts

bash

# Configuration example
# Upgrade DuckDB to the patched release
pip install --upgrade 'duckdb>=1.4.2'

# When attaching an encrypted database, specify an authenticated cipher explicitly
# duckdb> ATTACH 'secure.duckdb' AS enc (ENCRYPTION_KEY 'REDACTED', ENCRYPTION_CIPHER 'GCM');