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
When a soft-lock stale break finds that the marker (the lock file at ``) it renamed aside was a live one recreated by a successor, the restore branch of `break_lock_file()` checks the break name with `lstat` (a check that reads a name without following a symbolic link) and then calls `os.link(break_path, lock_file)` by name. On CPython 3.12 and later on Linux (and on macOS) that call follows a symbolic link (a file that redirects to another path). A local user (the other user below) who can write a shared lock directory without the sticky bit (a directory flag that lets only a file's owner rename or remove it) replaces the break name with a symbolic link between those two calls. The `SoftFileLock`, `MarkerSoftFileLock`, `SoftFileLease` or `lifetime` break of the user running the lock (the lock user below) then creates a hard link (a second name for the same file), in that directory, to any of the lock user's own files on the same filesystem. That includes files inside directories the other user cannot enter and links that `fs.protected_hardlinks` (a Linux setting that forbids hard links to files one does not own) refuses the other user when it asks itself. The link exposes the file's size, times, mode and owner, keeps the inode (the kernel's identity for a file, independent of its name) alive, and gives the other user a name it can move. On 4.2.0 a later `FileLock` of the lock user on that name truncated the file. Affected versions: filelock >= 4.1.0 and <= 4.2.0 (finding `AN
- Products
- filelock
- Affected versions
- 4.1.0, 4.1.1, 4.1.2, 4.2.0
- Fixed versions
- 4.2.1
- CVEs
- CVE-2026-112914
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 1 Nov 2026, 03:20 UTC · Revision 1
Source evidence
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
core-osv · Original sourcePublished 23 Oct 2026, 22:00 UTC
When a soft-lock stale break finds that the marker (the lock file at ``) it renamed aside was a live one recreated by a successor, the restore branch of `break_lock_file()` checks the break name with `lstat` (a check that reads a name without following a symbolic link) and then calls `os.link(break_path, lock_file)` by name. On CPython 3.12 and later on Linux (and on macOS) that call follows a symbolic link (a file that redirects to another path). A local user (the other user below) who can write a shared lock directory without the sticky bit (a directory flag that lets only a file's owner rename or remove it) replaces the break name with a symbolic link between those two calls. The `SoftFileLock`, `MarkerSoftFileLock`, `SoftFileLease` or `lifetime` break of the user running the lock (the lock user below) then creates a hard link (a second name for the same file), in that directory, to any of the lock user's own files on the same filesystem. That includes files inside directories the other user cannot enter and links that `fs.protected_hardlinks` (a Linux setting that forbids hard links to files one does not own) refuses the other user when it asks itself. The link exposes the file's size, times, mode and owner, keeps the inode (the kernel's identity for a file, independent of its name) alive, and gives the other user a name it can move. On 4.2.0 a later `FileLock` of the lock user on that name truncated the file. Affected versions: filelock >= 4.1.0 and <= 4.2.0 (finding `AN
osv:GHSA-crv4-6mhj-j5jh
filelock
Fixed versions: 4.2.1
Complete source record
{
"id": "4f25ca7d505731a2ae7e65311ab3ce13742ed6a1450e68b0122fce56fefcbd97",
"url": "https://osv.dev/vulnerability/GHSA-crv4-6mhj-j5jh",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "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",
"summary": "When a soft-lock stale break finds that the marker (the lock file at ``) it renamed aside was a live one recreated by a successor, the restore branch of `break_lock_file()` checks the break name with `lstat` (a check that reads a name without following a symbolic link) and then calls `os.link(break_path, lock_file)` by name. On CPython 3.12 and later on Linux (and on macOS) that call follows a symbolic link (a file that redirects to another path). A local user (the other user below) who can write a shared lock directory without the sticky bit (a directory flag that lets only a file's owner rename or remove it) replaces the break name with a symbolic link between those two calls. The `SoftFileLock`, `MarkerSoftFileLock`, `SoftFileLease` or `lifetime` break of the user running the lock (the lock user below) then creates a hard link (a second name for the same file), in that directory, to any of the lock user's own files on the same filesystem. That includes files inside directories the other user cannot enter and links that `fs.protected_hardlinks` (a Linux setting that forbids hard links to files one does not own) refuses the other user when it asks itself. The link exposes the file's size, times, mode and owner, keeps the inode (the kernel's identity for a file, independent of its name) alive, and gives the other user a name it can move. On 4.2.0 a later `FileLock` of the lock user on that name truncated the file. Affected versions: filelock >= 4.1.0 and <= 4.2.0 (finding `AN",
"evidence": "osv:GHSA-crv4-6mhj-j5jh",
"products": [
{
"name": {
"value": "filelock",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "4.2.1",
"evidence": "/affected/0/ranges"
}
],
"affected_versions": [
{
"value": "4.1.0",
"evidence": "/affected/0/versions"
},
{
"value": "4.1.1",
"evidence": "/affected/0/versions"
},
{
"value": "4.1.2",
"evidence": "/affected/0/versions"
},
{
"value": "4.2.0",
"evidence": "/affected/0/versions"
}
]
}
],
"severity": "medium",
"structured": {
"id": "GHSA-crv4-6mhj-j5jh",
"aliases": [
"CVE-2026-112914",
"GHSA-crv4-6mhj-j5jh"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:N"
}
],
"affected": [
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.1.0"
},
{
"fixed": "4.2.1"
}
]
}
],
"package": {
"name": "filelock",
"purl": "pkg:pypi/filelock",
"ecosystem": "PyPI"
},
"versions": [
"4.1.0",
"4.1.1",
"4.1.2",
"4.2.0"
],
"database_specific": {
"source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/10/GHSA-crv4-6mhj-j5jh/GHSA-crv4-6mhj-j5jh.json",
"last_known_affected_version_range": "<= 4.2.0"
}
}
],
"modified": "2026-10-23T22:15:05.387500982Z",
"provider": "osv",
"references": [
"https://github.com/tox-dev/filelock/security/advisories/GHSA-crv4-6mhj-j5jh",
"https://nvd.nist.gov/vuln/detail/CVE-2026-112914",
"https://github.com/tox-dev/filelock/pull/843",
"https://github.com/tox-dev/filelock/commit/740ff666b62a88496c8d7394e4e6230605e4d62b",
"https://github.com/tox-dev/filelock",
"https://github.com/tox-dev/filelock/releases/tag/4.2.1"
],
"provider_metadata": {
"cwe_ids": [
"CWE-363",
"CWE-59"
],
"severity": "MODERATE",
"github_reviewed": true,
"nvd_published_at": "2026-10-20T15:17:15Z",
"github_reviewed_at": "2026-10-23T22:00:11Z"
}
},
"related_cves": [
{
"value": "CVE-2026-112914",
"evidence": "/aliases"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 427058,
"published_at": "2026-10-23T22:00:11+00:00"
}