CVE-2026-112938: filelock StrictSoftFileLock symlink race privilege escalation

CVE-2026-112938 · Severity: medium · CVSS 5.8 · Published 2026-11-05

filelock is a library that implements distributed file-based locks for Python. An attacker with a local user account can race a symbolic link swap to cause the lock user's process to create lock coordination files in a directory of the attacker's choosing, potentially blocking other locks or leaking file names. This allows an unprivileged user to deny service to other processes or extract limited information from directories they cannot directly access.

Technologies: filelock (PyPI), Tox-Dev Filelock. Vendors: PyPI, Tox-Dev.

Quick answers

Is CVE-2026-112938 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-112938 being exploited in the wild.
How severe is CVE-2026-112938?
Medium severity, with a CVSS score of 5.8, published 5 November 2026.
Which products and versions are affected?
filelock (PyPI) >= 3.30.0, <= 4.2.0, ECOSYSTEM:introduced=3.30.0,fixed=4.2.1; Tox-Dev Filelock 3.30.0 through 4.2.0.
Is there a fix for CVE-2026-112938?
Yes. filelock (PyPI): upgrade to 4.2.1 or later. Until then: Keep strict locks in directories no other user can write. In sticky shared directories like /tmp, create the lock directory as the service user before any other account can access it. Do not run the recovery loop from docs/tutorials.rst on locks in shared directories without first verifying the claim owner is actually gone. Treat unexpected SoftFileLockProtocolError exceptions as potential indicators of symlink manipulation. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-112938 attacked?
It is attacked with local access, in a software library.
Am I affected by CVE-2026-112938?
Check whether you run filelock (PyPI) or Tox-Dev Filelock at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • filelock (PyPI): upgrade to 4.2.1 or later
    pip install "filelock>=4.2.1"

Keep strict locks in directories no other user can write. In sticky shared directories like /tmp, create the lock directory as the service user before any other account can access it. Do not run the recovery loop from docs/tutorials.rst on locks in shared directories without first verifying the claim owner is actually gone. Treat unexpected SoftFileLockProtocolError exceptions as potential indicators of symlink manipulation.

Technical details

StrictSoftFileLock checks whether a coordination directory exists via lstat but then operates on it by pathname, following symbolic links in intermediate path components. An attacker can use renameat2(RENAME_EXCHANGE) to atomically swap a real directory with a symbolic link between the check and subsequent operations. The O_NOFOLLOW flag only covers the final pathname component, not intermediate ones. By repeating this swap, the attacker can cause the lock user's process to create claim files in an attacker-chosen directory with the lock user's privileges, potentially starving other locks or leaking information via exception messages.

Affected products

  • tox-dev filelock 3.30.0 through 4.2.0

Identifiers

  • CVE-2026-112938
  • GHSA-m462-7rxw-wvpg

Timeline

  • 2026-10-15: disclosed: Vulnerability reported by Anthropic's OSS Scanner
  • 2026-10-16: patched: Fix PR #839 opened
  • 2026-10-28: advisory

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.