CVE-2026-28684

What it actually does

CVE-2026-28684 is a local file-write vulnerability in python-dotenv before 1.2.2. The vulnerable set_key() and unset_key() routines rewrite .env files in a way that can follow symbolic links when a cross-device rename fallback path is used. If a local attacker can place or replace the targeted .env file with a symlink and then cause a more privileged user or process to update that file through python-dotenv, the library may overwrite the symlink target. The primary impact is high integrity and availability risk: attacker-influenced dotenv-formatted content can be written to arbitrary files reachable by the victim process permissions. The flaw does not directly disclose secrets, but it can corrupt configuration, break services, or potentially support privilege escalation depending on which files can be targeted and what privileged process performs the write.

Why it matters to the business

Organizations using vulnerable python-dotenv versions may be exposed to local privilege escalation or service disruption if untrusted users, build jobs, deployment scripts, developer tools, or automation can manipulate .env file paths used by higher-privileged processes. Successful exploitation could overwrite important configuration or application files, causing outages, deployment failures, or unauthorized changes to runtime behavior. The EPSS score is currently low and the vulnerability is not listed in CISA KEV, with no known mature public exploitation indicated, but it still matters in shared development systems, CI/CD workers, hosting platforms, and servers where lower-privileged users can influence project files processed by privileged automation.

How an attack unfolds

An attacker first needs local access or equivalent write access to a directory where a victim process expects to manage a .env file using python-dotenv. The attacker replaces the expected .env file with a symbolic link pointing to a file the victim process can write but the attacker normally cannot modify directly. The attacker then waits for or induces a privileged workflow, command, script, deployment tool, or application code path to call set_key() or unset_key() on that .env path. When python-dotenv rewrites the .env file and the operation enters the cross-device rename fallback path, the vulnerable code follows the symlink instead of safely replacing only the intended .env file. The target file is overwritten with dotenv-style key/value content, which can corrupt the file, change configuration, interrupt service startup, or in favorable cases help the attacker gain greater privileges by altering files consumed by privileged software.

How to fix it

Upgrade python-dotenv to version 1.2.2 or later wherever it is installed, including application dependencies, development tooling, CI/CD images, virtual environments, containers, and base images. If immediate upgrade is not possible, manually apply the upstream patch referenced by the project and avoid invoking set_key() or unset_key() on .env paths located in directories writable by less-privileged users. As compensating controls, ensure .env files and their parent directories are owned by the account running the application or deployment process, are not world-writable, and cannot be replaced by untrusted users. Avoid running dotenv update operations as root or elevated service accounts. In shared systems, mount project workspaces and temporary directories with least privilege and monitor for symlinked .env files. Rebuild and redeploy artifacts after dependency updates so the fixed library is actually present at runtime.

How to confirm the fix worked

Confirm installed python-dotenv versions are 1.2.2 or later using package inventory, SBOMs, lockfiles, and runtime checks such as `python -m pip show python-dotenv`, `pip freeze`, `pipenv graph`, `poetry show python-dotenv`, or equivalent dependency scanners. Verify all virtual environments, containers, build images, and deployment runners have been rebuilt and no longer contain vulnerable versions below 1.2.2. Review application and automation code for use of `set_key()` and `unset_key()` and confirm these functions are not operating on .env files in untrusted or shared writable directories. Check filesystem permissions to ensure .env files are regular files, not symlinks, and that parent directories are not writable by untrusted users. Where safe, perform a controlled non-production test to confirm updating a .env file does not follow a symlink and does not modify the symlink target after the upgrade.

Typical attack path

1. Gain local low-privileged access, or obtain write access to a project/workspace directory used by automation or a more privileged account.
2. Identify a .env file path that is later modified through python-dotenv set_key() or unset_key().
3. Replace the expected .env file with a symbolic link to a target file writable by the victim process.
4. Trigger or wait for a privileged script, CLI command, deployment step, or application workflow to update or remove an environment key.
5. Ensure conditions cause the cross-device rename fallback path to run during the rewrite operation.
6. The vulnerable python-dotenv code follows the symlink and overwrites the symlink target.
7. Use the resulting file corruption or configuration change to disrupt service, alter application behavior, or support local privilege escalation.

How to detect it

Look for evidence that a .env file was replaced with or resolved through a symbolic link and then modified by a Python process, deployment script, CI/CD job, or administrative command using python-dotenv. Useful log sources include endpoint detection telemetry, Linux auditd, file integrity monitoring, shell history, CI/CD job logs, package inventory, process execution logs, and filesystem metadata. Investigate unexpected symlinks named .env, especially in directories writable by non-administrative users or shared build/workspace locations. Review audit events showing symlink creation, deletion, rename, or chmod/chown activity around .env files followed by writes to sensitive configuration files by Python, dotenv CLI wrappers, deployment tooling, or privileged service accounts. Look for recently modified privileged files whose contents now resemble dotenv key/value syntax. Correlate modifications to target files with process lineage involving Python, package managers, application management commands, or CI/CD runners. Since there are no universal network indicators and exploitation is local, detection should focus on filesystem artifacts, process lineage, and anomalous file modifications rather than network traffic.

• .env ->
• set_key(
• unset_key(
• python-dotenv
• dotenv set
• dotenv unset

What your security team should do

• Inventory all uses of python-dotenv and prioritize upgrades to version 1.2.2 or later, especially on shared hosts, CI/CD runners, developer workstations, build systems, and production deployment automation.
• Search source code and scripts for `set_key()` and `unset_key()` usage and review whether the .env path can be influenced by lower-privileged users.
• Harden permissions on .env files and parent directories so untrusted users cannot replace them with symlinks.
• Avoid running dotenv file update operations with elevated privileges unless absolutely required.
• Add dependency scanning or policy checks to block python-dotenv versions below 1.2.2 in new builds.
• Investigate symlinked .env files and unexpected modifications to privileged configuration files on systems that previously ran vulnerable versions.
• Because the vulnerability is not currently in CISA KEV and has low EPSS, prioritize based on local multi-user exposure and privileged automation rather than broad internet-facing urgency.