Skip to content
Heist/ feed
Back to feed
MediumFix available

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

Type: advisorySources: OSV

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 source

Published 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"
}