Skip to content

GHSA-mf9w-mj56-hr94 CVE-2026-28684 PYSEC-2026-2270

python-dotenv: Symlink following in set_key allows arbitrary file overwrite via cross-device rename fallback

Medium PyPI
Severity
6.6 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.25%
Chance of exploitation in the next 30 days. Higher than 16.77% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-59 Improper Link Resolution Before File Access ('Link Following')
CWE-61 UNIX Symbolic Link (Symlink) Following
Fix
1.2.2
Upgrade python-dotenv to this version or later

Description

Summary

set_key() and unset_key() in python-dotenv follow symbolic links when rewriting .env files, allowing a local attacker to overwrite arbitrary files via a crafted symlink when a cross-device rename fallback is triggered.

Details

The rewrite() context manager in dotenv/main.py is used by both set_key() and unset_key() to safely modify .env files. It works by writing to a temporary file (created in the system's default temp directory, typically /tmp) and then using shutil.move() to replace the original file.

When the .env path is a symbolic link and the temp directory resides on a different filesystem than the target (a common configuration on Linux systems using tmpfs for /tmp), the following sequence occurs:

  1. shutil.move() first attempts os.rename(), which fails with an OSError because atomic renames cannot cross device boundaries.
  2. On failure, shutil.move() falls back to shutil.copy2() followed by os.unlink().
  3. shutil.copy2() calls shutil.copyfile() with follow_symlinks=True by default.
  4. This causes the content to be written to the symlink target rather than replacing the symlink itself.

An attacker who has write access to the directory containing a .env file can pre-place a symlink pointing to any file that the application process has write access to. When the application (or a privileged process such as a deploy script, Docker entrypoint, or CI pipeline) calls set_key() or unset_key(), the symlink target is overwritten with the new .env content.

This vulnerability does not require a race condition and is fully deterministic once the preconditions are met.

Impact

The primary impacts are to integrity and availability:

  • File overwrite / destruction (DoS): An attacker can cause an application or privileged process to corrupt or destroy configuration files, database configs, or other sensitive files it would not normally have access to modify.
  • Integrity violation: The target file's original content is replaced with .env-formatted content controlled by the attacker.
  • Potential privilege escalation: In scenarios where a privileged process (running as root or a service account) calls set_key(), the attacker can leverage this to write to files beyond their own access level.

The scope of impact depends on the application using python-dotenv and the privileges under which it runs.

Proof of Concept

The following script demonstrates the vulnerability. It requires /tmp and the user's home directory to reside on different devices (common on systemd-based Linux systems with tmpfs).

import os
import sys
import tempfile
from dotenv import set_key

# Pre-condition: /tmp must be on a different device than the target directory.
tmp_dev = os.stat("/tmp").st_dev
home_dev = os.stat(os.path.expanduser("~")).st_dev
assert tmp_dev != home_dev, "Skipped: /tmp and ~ are on the same device (no cross-device move)"

with tempfile.TemporaryDirectory(dir=os.path.expanduser("~")) as workdir:
    # File an attacker wants to overwrite
    target = os.path.join(workdir, "victim_config.txt")
    with open(target, "w") as f:
        f.write("DB_PASSWORD=supersecret\n")

    # Attacker pre-places a symlink at the path the application will use as .env
    env_symlink = os.path.join(workdir, ".env")
    os.symlink(target, env_symlink)

    before = open(target).read()

    # Application writes a new key -- triggers the cross-device fallback
    set_key(env_symlink, "INJECTED", "attacker_value")

    after = open(target).read()

    print("Before:", repr(before))
    print("After: ", repr(after))
    print("Symlink target overwritten:", target)

Expected output:

Before: 'DB_PASSWORD=supersecret\n'
After:  "DB_PASSWORD=supersecret\nINJECTED='attacker_value'\n"
Symlink target overwritten: /home/user/tmp806nut2g/victim_config.txt

Remediation

The fix changes the rewrite() context manager in the following ways:

  1. Symlinks are no longer followed by default. When the .env path is a symlink, rewrite() now resolves it to the real path before proceeding, or (by default) operates on the symlink entry itself rather than the target.
  2. A follow_symlinks: bool = False parameter is added to set_key() and unset_key() for users who explicitly need the old behavior.
  3. Temp files are written in the same directory as the target .env file (instead of the system temp directory), eliminating the cross-device rename condition entirely.
  4. os.replace() is used instead of shutil.move(), providing atomic replacement without symlink-following fallback behavior.

Users are advised to upgrade to the patched version as soon as it is available on PyPI.

Timeline

Date Event
2026-01-09 Initial report received from Giorgos Tsigourakos regarding a separate, unrelated issue also located in rewrite()
2026-01-10 Co-maintainer acknowledged report, requested clarification
2026-01-11 Initial report assessed as not exploitable and closed
2026-02-24 Reporter identified new, distinct cross-device symlink attack vector with deterministic exploitation
2026-02-26 Co-maintainer confirmed vulnerability and shared draft patch
2026-02-26 Reporter validated fix with monkeypatched PoC, proposed CVSS
2026-03-01 Patch merged to main
2026-03-01 Patched version released to PyPI
2026-04-20 Advisory published

Patches

Upgrade to v.1.2.2 or use the patch from https://github.com/theskumar/python-dotenv/commit/790c5c02991100aa1bf41ee5330aca75edc51311.patch

Affected versions

PyPI

PackageVulnerableFixed in
python-dotenv
< 1.2.2
1.2.2
python-dotenv
< 1.2.2
1.2.2

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

python-dotenv PyPI → 1.2.2

pip
pip install --upgrade "python-dotenv>=1.2.2"
poetry
poetry add "python-dotenv>=1.2.2"
uv
uv add "python-dotenv>=1.2.2"

Severity breakdown

CVSS 3.1 6.6

CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:H

Attack vector
Local
Attack complexity
Low
Privileges required
Low
User interaction
Required
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
High

Weakness

CWE-59: Improper Link Resolution Before File Access ('Link Following')

The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.

How to prevent it
  • Architecture and Design: Follow the principle of least privilege when assigning access rights to entities in a software system. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.

CWE-61: UNIX Symbolic Link (Symlink) Following

The product, when opening a file or directory, does not sufficiently account for when the file is a symbolic link that resolves to a target outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.

How to prevent it
  • Implementation: Symbolic link attacks often occur when a program creates a tmp directory that stores files/links. Access to the directory should be restricted to the program as to prevent attackers from manipulating the files.
  • Architecture and Design: Follow the principle of least privilege when assigning access rights to entities in a software system. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-hjqx-j4rw-g7xv
zip: Arbitrary file write outside the extraction directory, because ZipArchive::extract validates symlink targets lexically.
High Same weakness, CWE-59
GHSA-4vjg-vx72-qq4g
systeminformation has path traversal in Linux networkStats() that allows symlink-based file disclosure outside /sys/class/net
Low Same weakness, CWE-59
GHSA-9j6q-wvj5-jgjg
filelock: Symlink swap during SoftFileLock's writability check leaks whether a path exists and is writable by the lock taker
Low Same weakness, CWE-59
GHSA-j8f7-rjxc-mr56
filelock: ReadWriteLock follows a symlink at the lock path into SQLite
Medium Same weakness, CWE-59
GHSA-crv4-6mhj-j5jh
filelock: SoftFileLock stale-break restore follows a swapped-in symbolic link and hard-links a file of the user running the lock into the lock directory
Medium Same weakness, CWE-59
GHSA-v4x8-3wr5-3wq8
filelock ReadWriteLock: SQLite reopens the lock database by name, so a planted symlink or journal file makes the lock user's process overwrite or unlink its own files
High Same weakness, CWE-59
GHSA-gq48-pqfc-9p58
GitPython: Submodule.move() follows an attacker-committed intermediate symlink outside the worktree
Medium Same weakness, CWE-59
GHSA-2j93-m82w-73j2
Microsoft Security Advisory CVE-2026-96231 - .NET and Visual Studio Elevation of Privilege Vulnerability
High Same weakness, CWE-59

Credits: bbc2, tsigouris007

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor