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:04 +0000 https://db.gcve.eu/vuln/cve-2026-112911 <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, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. 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, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. This issue is fixed in version 4.2.1.</p> https://db.gcve.eu/vuln/cve-2026-112911 https://db.gcve.eu/vuln/ghsa-9c4x-gm8v-wgc4 <p><strong>Affected:</strong> PyPI: filelock</p> <p>`StrictSoftFileLock`, `AsyncStrictSoftFileLock`, `SoftReadWriteLock` and `AsyncSoftReadWriteLock` keep their whole ownership state as files in a directory derived from the lock path (`&lt;path&gt;.filelock/claims`, `&lt;path&gt;.rw/{gen,holders}`). When that directory already exists they adopt it after checking only that it is a real directory, not who owns it. Another local user who can create names in the lock&#39;s directory can create the tree before the first acquire on that path by the user running the lock (below: the lock user). In `/tmp`, `/var/tmp` or another sticky shared directory any user can do that; the sticky bit is a directory flag that lets only a file&#39;s owner remove or rename it. The other user then owns the tree. They can unlink the lock user&#39;s claims while the lock user holds the lock, so a second process of the lock user, root included, enters the same critical section and neither process sees an error.</p> <p>Against `SoftReadWriteLock` the same position also admits two writers with `on_compromise` silent. It redirects the lock user&#39;s own creates and renames into a directory the other user picks (the scanner replaced a repository&#39;s `.git/HEAD` with a filelock record written with the lock user&#39;s privileges). It also keeps the lock user&#39;s acquire or release running past any `timeout`. Affected versions are filelock 3.30.0 through 4.2.0 (finding `ANT-2026-Q5VK5JEE`).</p> <p>## Severity</p> <p>**CVSS 3.1 `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H` scores 6.3 (Medium).** `AV:L` (local):…</p> <p><strong>Affected:</strong> PyPI: filelock</p> <p>`StrictSoftFileLock`, `AsyncStrictSoftFileLock`, `SoftReadWriteLock` and `AsyncSoftReadWriteLock` keep their whole ownership state as files in a directory derived from the lock path (`&lt;path&gt;.filelock/claims`, `&lt;path&gt;.rw/{gen,holders}`). When that directory already exists they adopt it after checking only that it is a real directory, not who owns it. Another local user who can create names in the lock&#39;s directory can create the tree before the first acquire on that path by the user running the lock (below: the lock user). In `/tmp`, `/var/tmp` or another sticky shared directory any user can do that; the sticky bit is a directory flag that lets only a file&#39;s owner remove or rename it. The other user then owns the tree. They can unlink the lock user&#39;s claims while the lock user holds the lock, so a second process of the lock user, root included, enters the same critical section and neither process sees an error.</p> <p>Against `SoftReadWriteLock` the same position also admits two writers with `on_compromise` silent. It redirects the lock user&#39;s own creates and renames into a directory the other user picks (the scanner replaced a repository&#39;s `.git/HEAD` with a filelock record written with the lock user&#39;s privileges). It also keeps the lock user&#39;s acquire or release running past any `timeout`. Affected versions are filelock 3.30.0 through 4.2.0 (finding `ANT-2026-Q5VK5JEE`).</p> <p>## Severity</p> <p>**CVSS 3.1 `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H` scores 6.3 (Medium).** `AV:L` (local):…</p> https://db.gcve.eu/vuln/ghsa-9c4x-gm8v-wgc4