CVE-2025-64429: 
DuckDB vulnerability analysis and mitigation

CVE-2025-64429 is a cryptographic weakness in DuckDB's block-based encryption implementation, introduced in version 1.4.0. The vulnerability encompasses multiple flaws: use of an insecure pseudo-random number generator (pcg32) for cryptographic key and IV generation, compiler-optimizable memset() calls that may leave key material in memory, a downgrade attack path from GCM to CTR mode via header manipulation, and failure to check the return value of OpenSSL's rand_bytes(). Affected versions are DuckDB 1.4.0 and 1.4.1; version 1.4.2 contains the fixes. It carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, Red Hat CVE).

The root cause is classified as CWE-327 (Use of a Broken or Risky Cryptographic Algorithm). Four distinct weaknesses exist in the implementation: (1) The RandomEngine class falls back to pcg32, a non-cryptographically-secure PRNG with only 127 bits of internal state — far below the 256 bits required for AES-256 key generation — to produce cryptographic keys, IVs, and the DatabaseID used as a SHA256 KDF salt; (2) std::memset() is used to erase keys from memory in encryption_functions.cpp and encryption_key_manager.cpp, but compilers may optimize this call away, leaving sensitive key material on the heap; (3) the unencrypted database header stores a cipher flag that an attacker can modify to downgrade from AES-GCM (which provides integrity via authentication tags) to AES-CTR (which provides no integrity checks), bypassing tamper detection; (4) the return value of OpenSSL's rand_bytes() was not checked, meaning a generator failure could silently produce deterministic or low-entropy values for keys and IVs (GitHub Advisory, Red Hat Bugzilla).

Successful exploitation of these weaknesses could allow an attacker to compromise the internal state of the RNG and derive the randomly generated encryption key used to protect temporary files, access cryptographic keys if they have read access to process memory (e.g., via a memory leak), circumvent GCM integrity checks by downgrading the cipher mode, and influence the OpenSSL RNG without DuckDB detecting the failure — all leading to predictable keys and potential plaintext recovery of encrypted database contents. The primary impacts are to confidentiality (exposure of encrypted data) and integrity (bypassing authentication tags), with no direct availability impact (GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.016% (0.000160), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation of the RNG weakness and downgrade attack requires either network access to observe public IVs or local/adjacent access to the database file or process memory, making opportunistic mass exploitation unlikely but targeted attacks feasible against high-value encrypted databases.

The primary remediation is to upgrade DuckDB to version 1.4.2 or later, which was released on November 12, 2025. Version 1.4.2 disables the insecure pcg32 fallback RNG and requires OpenSSL via the httpfs extension for all cryptographic operations, uses the secure MbedTLS mbedtls_platform_zeroize() primitive to clear key material from memory, requires explicit specification of ciphers lacking integrity checks (e.g., CTR) on ATTACH, and checks the return code of rand_bytes(). Organizations should also avoid using databases created with versions 1.4.0–1.4.1 without re-encrypting them under 1.4.2, and should consider rotating encryption keys for any databases that were encrypted under the vulnerable versions (GitHub Advisory, Red Hat Bugzilla).

The advisory was published by DuckDB maintainer hannes on November 12, 2025, with credit given to researchers skosowski and SalusaSecondus for reporting the issues (GitHub Advisory). Red Hat tracked the issue as medium severity in their security response process (Red Hat CVE). No significant broader media coverage or notable community controversy has been observed beyond standard vulnerability tracking.