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:29:42 +0000 https://db.gcve.eu/vuln/cve-2026-112941 <p><strong>Affected:</strong> tox-dev filelock</p> <p>filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the &lt;path&gt;.rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. 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 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the &lt;path&gt;.rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. This issue is fixed in version 4.2.1.</p> https://db.gcve.eu/vuln/cve-2026-112941 https://db.gcve.eu/vuln/ghsa-wfhq-q4j2-c37m <p><strong>Affected:</strong> PyPI: filelock</p> <p>`SoftReadWriteLock` (and `AsyncSoftReadWriteLock`, which wraps one) checks once per lock object, by name, that `&lt;path&gt;.rw`, `&lt;path&gt;.rw/gen` and `&lt;path&gt;.rw/holders` are real directories and not symbolic links (files that redirect to another path). It then keeps only a boolean. Every later record operation resolves the full path again, and `O_NOFOLLOW` (a flag that makes an open fail when the final name is a symbolic link) protects the last component only. Another local user (the other user below) who can write the directory holding the lock, or who created `&lt;path&gt;.rw` first in a sticky directory such as `/tmp` (the sticky bit is a directory flag that lets only a file&#39;s owner rename or remove it), can put a tree under that name whose `gen` or `holders` is a symbolic link into a directory of the user running the lock (the lock user below).</p> <p>A long-running process of the lock user that has already passed the check then creates, renames over and deletes files there with the lock user&#39;s privileges, including in `0700` directories the other user cannot open. The names and bytes are filelock&#39;s own lock records, not chosen by the other user. The scanner&#39;s reproducer replaces `.git/HEAD` in the lock user&#39;s private repository so that `git status` fails. There is no race. Affected versions: filelock &gt;= 4.1.0 and &lt;= 4.2.0. Anthropic&#39;s OSS Scanner reported it in private as `ANT-2026-WXXRI4M4` [high, CWE-367], titled &#34;SoftReadWriteLock follows gen dir swapped for a symlink after first acqu…</p> <p><strong>Affected:</strong> PyPI: filelock</p> <p>`SoftReadWriteLock` (and `AsyncSoftReadWriteLock`, which wraps one) checks once per lock object, by name, that `&lt;path&gt;.rw`, `&lt;path&gt;.rw/gen` and `&lt;path&gt;.rw/holders` are real directories and not symbolic links (files that redirect to another path). It then keeps only a boolean. Every later record operation resolves the full path again, and `O_NOFOLLOW` (a flag that makes an open fail when the final name is a symbolic link) protects the last component only. Another local user (the other user below) who can write the directory holding the lock, or who created `&lt;path&gt;.rw` first in a sticky directory such as `/tmp` (the sticky bit is a directory flag that lets only a file&#39;s owner rename or remove it), can put a tree under that name whose `gen` or `holders` is a symbolic link into a directory of the user running the lock (the lock user below).</p> <p>A long-running process of the lock user that has already passed the check then creates, renames over and deletes files there with the lock user&#39;s privileges, including in `0700` directories the other user cannot open. The names and bytes are filelock&#39;s own lock records, not chosen by the other user. The scanner&#39;s reproducer replaces `.git/HEAD` in the lock user&#39;s private repository so that `git status` fails. There is no race. Affected versions: filelock &gt;= 4.1.0 and &lt;= 4.2.0. Anthropic&#39;s OSS Scanner reported it in private as `ANT-2026-WXXRI4M4` [high, CWE-367], titled &#34;SoftReadWriteLock follows gen dir swapped for a symlink after first acqu…</p> https://db.gcve.eu/vuln/ghsa-wfhq-q4j2-c37m