https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 30 Oct 2026 23:48:38 +0000 https://db.gcve.eu/vuln/cve-2026-112935 <p><strong>Affected:</strong> tox-dev filelock</p> <p>filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can break a stale marker after an attacker frees its own marker following the stale read, an honest contender creates a live successor on the reused inode, and the successor&#39;s modification time is not newer than the saved observation, causing the live marker to be removed and two holders to be admitted. This issue is fixed in version 4.2.1.</p> <p><strong>Affected:</strong> tox-dev filelock</p> <p>filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can break a stale marker after an attacker frees its own marker following the stale read, an honest contender creates a live successor on the reused inode, and the successor&#39;s modification time is not newer than the saved observation, causing the live marker to be removed and two holders to be admitted. This issue is fixed in version 4.2.1.</p> https://db.gcve.eu/vuln/cve-2026-112935 https://db.gcve.eu/vuln/ghsa-fq56-3cx3-fjxp <p><strong>Affected:</strong> PyPI: filelock</p> <p>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 &#34;not implemented&#34; error) recognises the marker it judged stale by two values. The marker is the lock file at `&lt;path&gt;`, whose presence says a process holds the lock. The values are its inode number (the kernel&#39;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.</p> <p>On a filesystem that hands a freed inode number straight to the next file (ext4, xfs, overlayfs on them) the next holder&#39;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&#39;s directory, a sticky `/tmp` included (the sticky bit is a directory flag that lets only a file&#39;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 running the lock (the lock user below) then hold the same default-configured lock at once, and nothing raises or logs. Affected versions: filelock &gt;= 3.22.0 and &lt;= 4.2.0 (finding `ANT-2026-KIIS96IX`).</p> <p>## Severity</p> <p>**CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N, 4.7 (Medium).**</p> <p>`AV:L…</p> <p><strong>Affected:</strong> PyPI: filelock</p> <p>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 &#34;not implemented&#34; error) recognises the marker it judged stale by two values. The marker is the lock file at `&lt;path&gt;`, whose presence says a process holds the lock. The values are its inode number (the kernel&#39;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.</p> <p>On a filesystem that hands a freed inode number straight to the next file (ext4, xfs, overlayfs on them) the next holder&#39;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&#39;s directory, a sticky `/tmp` included (the sticky bit is a directory flag that lets only a file&#39;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 running the lock (the lock user below) then hold the same default-configured lock at once, and nothing raises or logs. Affected versions: filelock &gt;= 3.22.0 and &lt;= 4.2.0 (finding `ANT-2026-KIIS96IX`).</p> <p>## Severity</p> <p>**CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N, 4.7 (Medium).**</p> <p>`AV:L…</p> https://db.gcve.eu/vuln/ghsa-fq56-3cx3-fjxp