GHSA-4XGF-CPJX-PC3J

Summary

Summary NestedSecretsSettingsSource reads secret values from files in a configured secretsdir. When secretsnestedsubdir=True, a directory entry inside secretsdir that is a symbolic link pointing outside secretsdir is followed, so files outside the configured directory are read into settings values. The same code path bypasses the documented secretsdirmaxsize protection. An attacker or lower-privileged component able to influence entries in the configured secrets directory (for example, a writable or shared secrets mount) can turn this into an unintended local file read into settings and can defeat the advertised loading-size cap. This report does not claim network reachability by itself. Details NestedSecretsSettingsSource performed two passes over secretsdir using two different, inconsistent directory-traversal implementations: The size check in validatesecretspath() used Path.glob('/'), which does not descend into a symbolically-linked directory. The loader in loadsecrets() used glob.iglob(f'{path}//', recursive=True) followed by readtext(), which does follow symlinked directories and reads through the link target. Because the two passes disagreed on symlinks, a symlinked directory inside secretsdir whose target lives elsewhere was invisible to the size accounting (counted as 0 bytes) while still being fully read by the loader. This produces two distinct problems: Out-of-tree read (CWE-22 / CWE-59). A symlinked directory (or file) inside secretsdir that resolves outside it is followed, and the external file's contents are loaded into the corresponding settings field. secretsdirmaxsize bypass (CWE-400). The size check never sees the out-of-tree content, so the documented size cap is neither respected nor able to reject the oversized external file. A related amplification exists for cyclic in-tree symlinks, which glob.iglob(recursive=True) re-traverses, inflating the size accounting and the number of loaded secrets. Reproduction In a clean Linux container, with a secretsdir containing a symlink secrets/db -> /path/outside and an outside/passwd file of 512 bytes, while secretsdirmaxsize=100: On affected versions, Settings().db.passwd is populated with the 512-byte out-of-tree file and no SettingsError is raised, even though the file exceeds secretsdirmaxsize. Impact Applications that opt into NestedSecretsSettingsSource with secretsnestedsubdir=True and load secrets from a directory whose entries can be influenced by an attacker or a lower-privileged component (for example, a writable or shared secrets mount, or a secrets directory partially populated from untrusted input) are affected. The impact is: Confidentiality: files outside the configured secretsdir can be read into settings values (local file read). Integrity / availability of the safeguard: the advertised secretsdirmaxsize cap can be bypassed, and cyclic symlinks can inflate resource usage during loading. The vulnerability requires the ability to place a symbolic link inside the configured secrets directory; it is not remotely reachable on its own. Applications that do not use NestedSecretsSettingsSource, or that point secretsdir at a directory fully under the application's control, are not affected. Mitigation Upgrade to pydantic-settings 2.14.2, which: walks the secrets directory explicitly and only descends into directories whose resolved path stays within secretsdir, so symlinked directories pointing outside are never followed; uses a single, cycle-safe iterator for both the size check and the loader, so the size accounting and the loaded set are always consistent and each real directory is visited at most once; skips any file whose resolved path escapes secretsdir, as defense in depth. If upgrading is not immediately possible, ensure the configured secretsdir is fully owned and controlled by the application (no writable or attacker-influenced entries), or avoid secretsnested_subdir=True.

Impact

Affected versions

Security releases

Remediation advice