https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 11 Nov 2026 07:40:46 +0000 https://db.gcve.eu/vuln/cve-2026-112938 <p><strong>Affected:</strong> tox-dev filelock</p> <p>filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, On POSIX platforms, StrictSoftFileLock and AsyncStrictSoftFileLock validate the coordination directory in _ensure_protocol_directory but later reach the claims directory through _open_directory by pathname, allowing a local account that can rename the coordination name to swap in a symbolic link between check and use during acquisition. That race can create and leave claim files in another writable directory or strand claims in a different strict lock so the second lock times out. Separately, the claims property and force_break follow a resting symbolic link without a race when the lock user inspects or recovers the lock. Claims inspection discloses a file name to the other account only if the resulting exception text or claim_name reaches that account through a shared log, CI output, or error report. A blind force_break recovery that removes live claims from another strict lock can allow two processes into that lock&#39;s critical section; this path reaches other strict locks, not arbitrary files. 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.30.0 until 4.2.1, On POSIX platforms, StrictSoftFileLock and AsyncStrictSoftFileLock validate the coordination directory in _ensure_protocol_directory but later reach the claims directory through _open_directory by pathname, allowing a local account that can rename the coordination name to swap in a symbolic link between check and use during acquisition. That race can create and leave claim files in another writable directory or strand claims in a different strict lock so the second lock times out. Separately, the claims property and force_break follow a resting symbolic link without a race when the lock user inspects or recovers the lock. Claims inspection discloses a file name to the other account only if the resulting exception text or claim_name reaches that account through a shared log, CI output, or error report. A blind force_break recovery that removes live claims from another strict lock can allow two processes into that lock&#39;s critical section; this path reaches other strict locks, not arbitrary files. This issue is fixed in version 4.2.1.</p> https://db.gcve.eu/vuln/cve-2026-112938 https://db.gcve.eu/vuln/ghsa-m462-7rxw-wvpg <p><strong>Affected:</strong> PyPI: filelock</p> <p>`StrictSoftFileLock` and `AsyncStrictSoftFileLock` check `&lt;path&gt;.filelock` (the coordination directory that holds the lock&#39;s state) with one `lstat` call on its name. `lstat` reports what a name is without following a symbolic link (a file that redirects to another path). After that check, the code reaches `&lt;path&gt;.filelock/claims` by pathname for every later operation (`mkdir`, scan, publish, link, unlink). `_open_directory` passes `O_NOFOLLOW` (a flag that makes an open fail when the final name is a symbolic link), but the flag covers only the final `claims` component. The kernel follows a symbolic link in any earlier component.</p> <p>Another local user (the other user below) who can rename `&lt;path&gt;.filelock` exchanges it for a symbolic link after the check. In a shared directory without the sticky bit (a directory flag that lets only a file&#39;s owner rename or remove it), any user with write access can do this. Where the shared directory is sticky, such as `/tmp`, only the user who created `&lt;path&gt;.filelock` before the user running the lock (the lock user below) first used it can. The lock user&#39;s process (root&#39;s, if root takes the lock) then creates a `claims` directory and claim files (the files whose presence says a process wants or holds the lock) inside a directory the other user chooses but only the lock user can write.</p> <p>When the link points at another strict lock&#39;s `.filelock` directory, the stranded claims make that lock time out for every process until an operator finds and…</p> <p><strong>Affected:</strong> PyPI: filelock</p> <p>`StrictSoftFileLock` and `AsyncStrictSoftFileLock` check `&lt;path&gt;.filelock` (the coordination directory that holds the lock&#39;s state) with one `lstat` call on its name. `lstat` reports what a name is without following a symbolic link (a file that redirects to another path). After that check, the code reaches `&lt;path&gt;.filelock/claims` by pathname for every later operation (`mkdir`, scan, publish, link, unlink). `_open_directory` passes `O_NOFOLLOW` (a flag that makes an open fail when the final name is a symbolic link), but the flag covers only the final `claims` component. The kernel follows a symbolic link in any earlier component.</p> <p>Another local user (the other user below) who can rename `&lt;path&gt;.filelock` exchanges it for a symbolic link after the check. In a shared directory without the sticky bit (a directory flag that lets only a file&#39;s owner rename or remove it), any user with write access can do this. Where the shared directory is sticky, such as `/tmp`, only the user who created `&lt;path&gt;.filelock` before the user running the lock (the lock user below) first used it can. The lock user&#39;s process (root&#39;s, if root takes the lock) then creates a `claims` directory and claim files (the files whose presence says a process wants or holds the lock) inside a directory the other user chooses but only the lock user can write.</p> <p>When the link points at another strict lock&#39;s `.filelock` directory, the stranded claims make that lock time out for every process until an operator finds and…</p> https://db.gcve.eu/vuln/ghsa-m462-7rxw-wvpg