pydantic-settings EUVD-2026-41878

Exploitation requires two concrete conditions: (1) the application must instantiate NestedSecretsSettingsSource with secrets_nested_subdir=True - this is a non-default opt-in configuration, not enabled by default; (2) the attacker or a lower-privileged process must have write access to the configured secrets_dir, for example via a shared or world-writable mount. The CVSS PR:L confirms low-privileged local access is sufficient once these conditions are met. Exploitation is strictly local (AV:L) - remote unauthenticated exploitation is not possible. Deployments with secrets_nested_subdir omitted or set to False, or where secrets_dir is mounted read-only and owned exclusively by the application, are not exploitable regardless of library version.

The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L, score 5.3) accurately characterizes the attack surface: local access with low privileges is required, complexity is low, and no user interaction is needed. The partial C/I/A ratings reflect that the attacker reads files into application settings rather than gaining full filesystem read or write. No EPSS score was provided in the available intelligence, making probabilistic exploitation assessment unavailable. The absence of a KEV listing and any public POC lowers urgency relative to the CVSS score alone. Real-world risk is elevated in containerized or microservice environments - particularly Kubernetes deployments - where secrets are mounted as shared volumes and multiple workloads may have write access to the same mount. In tightly controlled environments where secrets_dir is owned exclusively by the application process, exploitation surface is minimal. The secrets_dir_max_size bypass adds an integrity and availability dimension that the base CVSS score partially captures but may understate in high-sensitivity deployments.

A lower-privileged sidecar container or compromised process sharing a writable Kubernetes secrets volume creates a symbolic link inside the application's secrets_dir - for example, secrets/db/password -> /etc/shadow - and waits for the application to restart or reload configuration. When the application initializes NestedSecretsSettingsSource with secrets_nested_subdir=True, the symlink is followed and the contents of /etc/shadow are loaded into the db.password settings field, potentially surfacing in logs, error messages, or downstream API responses. No public POC has been identified at time of analysis.