CVE-2026-112939: filelock: SoftFileLock removes a live holder's marker when another user forges the PID in a writable marker
SoftFileLock, MarkerSoftFileLock, SoftFileLease, their async variants and a FileLock that has fallen back to a soft lock on ENOSYS decide from the record inside the marker file whether its owner is gone. The marker is the file whose presence says a process holds the lock. They do not check who could have written that record.
A local user who can write the marker but cannot remove it rewrites the holder’s record to name a dead PID (process id). That position arises with an explicit mode with group or other write bits, or the default mode under a lax umask (the process setting that strips permission bits from new files), in a sticky or otherwise non-removable directory. The sticky bit is a directory flag that lets only a file’s owner remove or rename it. The next contender running as the holder’s account, or root, judges the lock stale, removes the live marker on that user’s behalf and acquires it. Two processes then run the critical section together and neither gets an error. Affected versions are filelock 3.22.0 through 4.2.0 (finding ANT-2026-W1H9NXUH).
References
- github.com/advisories/GHSA-rfpc-qcw5-3pc4
- github.com/tox-dev/filelock/commit/eeceaa846cbe4df72718d94c8371ca1ab8f5b3cc
- github.com/tox-dev/filelock/pull/836
- github.com/tox-dev/filelock/releases/tag/4.2.1
- github.com/tox-dev/filelock/security/advisories/GHSA-rfpc-qcw5-3pc4
- nvd.nist.gov/vuln/detail/CVE-2026-112939
Code Behaviors & Features
Detect and mitigate CVE-2026-112939 with GitLab Dependency Scanning
Secure your software supply chain by verifying that all open source dependencies used in your projects contain no disclosed vulnerabilities. Dependency Scanning using SBOM also detects vulnerabilities from proprietary advisories that this site does not include. Learn more about Dependency Scanning using SBOM →