https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 27 Oct 2026 04:36:58 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-112940 <p>filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock let SQLite reopen the database and side files by name; on POSIX systems an attacker with rename access in a non-sticky parent can swap those names to cause overwrite or unlink operations, while a writable adjacent hot journal is additionally required for attacker-chosen content overwrites. This issue is fixed in version 4.2.1.</p> <p>filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock let SQLite reopen the database and side files by name; on POSIX systems an attacker with rename access in a non-sticky parent can swap those names to cause overwrite or unlink operations, while a writable adjacent hot journal is additionally required for attacker-chosen content overwrites. This issue is fixed in version 4.2.1.</p> https://db.gcve.eu/vuln/fkie_cve-2026-112940 https://db.gcve.eu/vuln/ghsa-v4x8-3wr5-3wq8 <p><strong>Affected:</strong> PyPI: filelock</p> <p>`ReadWriteLock` and `AsyncReadWriteLock` (the SQLite-backed reader/writer lock) hand SQLite a name they do not control. On Linux the lock validates its database through a descriptor (the number the kernel gives a process for an open file). It then connects SQLite to `/proc/self/fd/&lt;n&gt;`, a Linux path that names the process&#39;s own open file `n`. SQLite turns that path back into a plain path and reopens it by name, following symlinks (a symlink is a file that points at another path). On every POSIX route SQLite also acts on `-journal`, `-wal` and `-shm` files it finds beside that name. Those are SQLite&#39;s side files: the rollback journal (pages saved to undo an interrupted write), the write-ahead log or WAL (changes kept outside the main file), and the shared-memory index for the WAL.</p> <p>Another local user who can create or rename entries in the directory that holds the lock database can turn this against the user running the lock (below: the lock user). Such a directory is a `0777` or group-writable cache, build or project directory without the sticky bit (a directory flag that lets only a file&#39;s owner remove or rename it). That other user can make the lock user&#39;s ordinary `read_lock()` or `write_lock()` write bytes of the other user&#39;s choosing into the lock user&#39;s own files. The same position lets the other user make that call create or unlink files of the lock user, admit a reader beside a writer, or kill the holder. All of this runs with the lock user&#39;s privileges. In a sticky…</p> <p><strong>Affected:</strong> PyPI: filelock</p> <p>`ReadWriteLock` and `AsyncReadWriteLock` (the SQLite-backed reader/writer lock) hand SQLite a name they do not control. On Linux the lock validates its database through a descriptor (the number the kernel gives a process for an open file). It then connects SQLite to `/proc/self/fd/&lt;n&gt;`, a Linux path that names the process&#39;s own open file `n`. SQLite turns that path back into a plain path and reopens it by name, following symlinks (a symlink is a file that points at another path). On every POSIX route SQLite also acts on `-journal`, `-wal` and `-shm` files it finds beside that name. Those are SQLite&#39;s side files: the rollback journal (pages saved to undo an interrupted write), the write-ahead log or WAL (changes kept outside the main file), and the shared-memory index for the WAL.</p> <p>Another local user who can create or rename entries in the directory that holds the lock database can turn this against the user running the lock (below: the lock user). Such a directory is a `0777` or group-writable cache, build or project directory without the sticky bit (a directory flag that lets only a file&#39;s owner remove or rename it). That other user can make the lock user&#39;s ordinary `read_lock()` or `write_lock()` write bytes of the other user&#39;s choosing into the lock user&#39;s own files. The same position lets the other user make that call create or unlink files of the lock user, admit a reader beside a writer, or kill the holder. All of this runs with the lock user&#39;s privileges. In a sticky…</p> https://db.gcve.eu/vuln/ghsa-v4x8-3wr5-3wq8 https://db.gcve.eu/vuln/ubuntu-cve-2026-112940 <p><strong>Affected:</strong> Ubuntu:Pro:18.04:LTS: python-filelock, Ubuntu:Pro:20.04:LTS: python-filelock, Ubuntu:Pro:22.04:LTS: python-filelock, Ubuntu:Pro:24.04:LTS: python-filelock, Ubuntu:26.10: python-filelock, Ubuntu:26.04:LTS: python-filelock</p> <p>(filelock is a platform-independent file lock for Python. From 3.20.4 u ...)</p> <p><strong>Affected:</strong> Ubuntu:Pro:18.04:LTS: python-filelock, Ubuntu:Pro:20.04:LTS: python-filelock, Ubuntu:Pro:22.04:LTS: python-filelock, Ubuntu:Pro:24.04:LTS: python-filelock, Ubuntu:26.10: python-filelock, Ubuntu:26.04:LTS: python-filelock</p> <p>(filelock is a platform-independent file lock for Python. From 3.20.4 u ...)</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-112940