---
id: "CVE-2026-112934"
kind: "vulnerability"
aliases: ["CVE-2026-112934"]
title: "filelock: local user can stall or write through Python file locks"
severity: "medium"
cvss: 6.1
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "tox-dev filelock", "fixed": ["4.2.1"], "affected": ">= 4.0.0, < 4.2.1", "ecosystem": "vendor"}]
ecosystems: ["vendor"]
tags: ["filelock", "package", "python", "self-hosted", "shared-hosts"]
not_affected_if: ["no-softreadwritelock", "non-shared-lock-directory", "single-user-host"]
published_at: "2026-10-20T15:17:16+00:00"
first_seen_at: "2026-10-23T21:57:20+00:00"
updated_at: "2026-10-25T04:04:09+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112934", "first_seen_at": "2026-10-23T21:57:20+00:00"}]
---

# filelock: local user can stall or write through Python file locks

Versions 4.0.0 through 4.2.1 of the filelock Python package let another local user with rename access to the lock directory swap a holder record for a named pipe, stalling the lock. Under a permissive hard-link policy, the same user can link a target file so the lock user writes through it.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:tox-dev filelock affected >= 4.0.0, < 4.2.1 fixed 4.2.1

## How to check

- Run `pip show filelock` or `python -c "import filelock; print(filelock.__version__)"` and check whether the version is `4.0.0` to `4.2.1`.
- Check whether the project or service uses `SoftReadWriteLock` (grep the code for `SoftReadWriteLock`).
- Check whether the lock directory is writable by other local users.

## Fix

- Upgrade filelock to `4.2.1` or later (`pip install --upgrade "filelock>=4.2.1"`).
- Restrict the lock directory so only the service account can rename or create files in it.

## Timeline

- 2026-10-23T21:57:20+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-112934

## From the sources

filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_