4.7 Medium

filelock: SoftFileLock stale-lock break removes a live lock file on a reused inode number and admits two holders

CVE-2026-112935

The stale-lock break shared by SoftFileLock, MarkerSoftFileLock and SoftFileLease (and their async variants, and a FileLock that has fallen back to a soft lock on ENOSYS, the "not implemented" error) recognises the marker it judged stale by two values. The marker is the lock file at , whose presence says a process holds the lock. The values are its inode number (the kernel's identity for a file, independent of its name) and its modification time (mtime) not being newer. The check runs after the contender has already closed the marker, so nothing keeps the inode allocated. On a filesystem that hands a freed inode number straight to the next file (ext4, xfs, overlayfs on them) the next holder's marker can carry that number. A contender still between its read and its break then renames and unlinks the live marker. Another local user (the other user below) who can create files in the lock's directory, a sticky /tmp included (the sticky bit is a directory flag that lets only a file's owner remove it), forces this at will. It plants a marker with a stale owner record and a modification time in the future and unlinks it as soon as a contender has read it. Two processes of the user…

Assessment

CVSS: 4.7 (v3.1)
Severity: Medium
EPSS: 0.00132% chance of exploitation in the next 30 days
Known exploited: Not listed in CISA KEV
Exploit availability: Nothing found in Exploit-DB, Metasploit, Nuclei or public PoC repositories
Published: 28 October 2026
Last updated: 28 October 2026
Affected: pip · filelock
Weakness: CWE-367

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

At the source

GitHub Advisories

References

Community proofs of concept

No community proof of concept yet. If you have one for a published vulnerability and the right to share it, add it below — it will appear here once reviewed.

Submit a proof of concept

Only for publicly disclosed vulnerabilities, and only material from testing you were authorised to perform. This platform does not buy, sell, or broker exploits — see earning from vulnerability research for legitimate bounty programs. Submissions are reviewed before they appear. Text only; do not include live credentials, personal data, or anything targeting systems you are not permitted to test.

Title *

Proof of concept *

Write-up (optional)

Affected versions (optional)

Name or handle (optional)

References (optional, one URL per line)

Licence for your contribution *

Private contact (optional, never shown)

Before you submit * This vulnerability is already publicly disclosed (it has a published CVE). This material comes only from testing I was authorised to perform. I have the legal right to publish this content and am not breaching any agreement by doing so. It contains no live credentials, personal data, or anything targeting systems I am not authorised to test. I understand it will be reviewed before it appears publicly and may be rejected. I agree to the submission terms.

What is 6 + 1? *

Query this programmatically

Agents can read this through the MCP endpoint, or over HTTP:

curl https://cve.zerocrew.in/api/cve/CVE-2026-112935