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:26:54 +0000 https://db.gcve.eu/vuln/brew-aws-google-auth-cve-2026-112913 <p><strong>Affected:</strong> Homebrew: aws-google-auth</p> <p>On Windows, `ReadWriteLock` and `AsyncReadWriteLock` (the SQLite-backed reader/writer lock) connect SQLite to the lock database by its path, in every directory. SQLite derives three side files from that path: `&lt;database&gt;-journal`, the rollback journal (pages saved to undo an interrupted write); `&lt;database&gt;-wal`, the write-ahead log (changes kept outside the main file); and `&lt;database&gt;-shm`, the shared-memory index of the WAL. SQLite acts on whichever of these it finds beside the database before the lock runs any statement. Another local account that can create files in the database&#39;s directory, but not delete files of other accounts there, places such a side file beside the database and denies everyone `DELETE` on it, which a file&#39;s creator may do. `C:\Windows\Temp` (the temporary directory of services, granting `BUILTIN\Users` create but not delete) and `C:\Users\Public` are such directories.</p> <p>With a `-wal` in place, every `read_lock()` and `write_lock()` of the user running the lock (below: the lock user) raises `sqlite3.OperationalError: disk I/O error` at once, whatever `timeout` says, until that account removes its file; the lock user cannot. With a `-journal` beside a lock database that holds a table, SQLite replays the journal and deletes the file the journal names, a file of the lock user, and the acquire reports success. Affected versions are filelock 3.20.4 through 4.2.0 on Windows. The maintainers found this while reviewing the fix for the POSIX form of the defect…</p> <p><strong>Affected:</strong> Homebrew: aws-google-auth</p> <p>On Windows, `ReadWriteLock` and `AsyncReadWriteLock` (the SQLite-backed reader/writer lock) connect SQLite to the lock database by its path, in every directory. SQLite derives three side files from that path: `&lt;database&gt;-journal`, the rollback journal (pages saved to undo an interrupted write); `&lt;database&gt;-wal`, the write-ahead log (changes kept outside the main file); and `&lt;database&gt;-shm`, the shared-memory index of the WAL. SQLite acts on whichever of these it finds beside the database before the lock runs any statement. Another local account that can create files in the database&#39;s directory, but not delete files of other accounts there, places such a side file beside the database and denies everyone `DELETE` on it, which a file&#39;s creator may do. `C:\Windows\Temp` (the temporary directory of services, granting `BUILTIN\Users` create but not delete) and `C:\Users\Public` are such directories.</p> <p>With a `-wal` in place, every `read_lock()` and `write_lock()` of the user running the lock (below: the lock user) raises `sqlite3.OperationalError: disk I/O error` at once, whatever `timeout` says, until that account removes its file; the lock user cannot. With a `-journal` beside a lock database that holds a table, SQLite replays the journal and deletes the file the journal names, a file of the lock user, and the acquire reports success. Affected versions are filelock 3.20.4 through 4.2.0 on Windows. The maintainers found this while reviewing the fix for the POSIX form of the defect…</p> https://db.gcve.eu/vuln/brew-aws-google-auth-cve-2026-112913 https://db.gcve.eu/vuln/cleanstart-2026-yd37887 <p><strong>Affected:</strong> CleanStart: litellm-database</p> <p>Security vulnerability affects the litellm-database package. This issue is resolved in later releases. See references for vulnerability details.</p> <p><strong>Affected:</strong> CleanStart: litellm-database</p> <p>Security vulnerability affects the litellm-database package. This issue is resolved in later releases. See references for vulnerability details.</p> https://db.gcve.eu/vuln/cleanstart-2026-yd37887 https://db.gcve.eu/vuln/fkie_cve-2026-112913 <p>filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock and AsyncReadWriteLock on Windows use _connect to attach SQLite to the lock database by pathname, allowing another local account that can create adjacent names to place a database-wal or database-journal side file before acquisition. An undeletable WAL file makes each read or write acquisition fail immediately with sqlite3.OperationalError regardless of timeout. Separately, when the database contains at least one table, a hot journal that grants the lock account modify rights can cause SQLite recovery to delete a file named by that journal only when the lock account has permission to delete the target. The issue requires a directory writable by another account, such as a shared Windows temporary directory, and does not affect private directories. 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 and AsyncReadWriteLock on Windows use _connect to attach SQLite to the lock database by pathname, allowing another local account that can create adjacent names to place a database-wal or database-journal side file before acquisition. An undeletable WAL file makes each read or write acquisition fail immediately with sqlite3.OperationalError regardless of timeout. Separately, when the database contains at least one table, a hot journal that grants the lock account modify rights can cause SQLite recovery to delete a file named by that journal only when the lock account has permission to delete the target. The issue requires a directory writable by another account, such as a shared Windows temporary directory, and does not affect private directories. This issue is fixed in version 4.2.1.</p> https://db.gcve.eu/vuln/fkie_cve-2026-112913 https://db.gcve.eu/vuln/ghsa-9vhv-jxww-xfm5 <p><strong>Affected:</strong> PyPI: filelock</p> <p>On Windows, `ReadWriteLock` and `AsyncReadWriteLock` (the SQLite-backed reader/writer lock) connect SQLite to the lock database by its path, in every directory. SQLite derives three side files from that path: `&lt;database&gt;-journal`, the rollback journal (pages saved to undo an interrupted write); `&lt;database&gt;-wal`, the write-ahead log (changes kept outside the main file); and `&lt;database&gt;-shm`, the shared-memory index of the WAL. SQLite acts on whichever of these it finds beside the database before the lock runs any statement. Another local account that can create files in the database&#39;s directory, but not delete files of other accounts there, places such a side file beside the database and denies everyone `DELETE` on it, which a file&#39;s creator may do. `C:\Windows\Temp` (the temporary directory of services, granting `BUILTIN\Users` create but not delete) and `C:\Users\Public` are such directories.</p> <p>With a `-wal` in place, every `read_lock()` and `write_lock()` of the user running the lock (below: the lock user) raises `sqlite3.OperationalError: disk I/O error` at once, whatever `timeout` says, until that account removes its file; the lock user cannot. With a `-journal` beside a lock database that holds a table, SQLite replays the journal and deletes the file the journal names, a file of the lock user, and the acquire reports success. Affected versions are filelock 3.20.4 through 4.2.0 on Windows. The maintainers found this while reviewing the fix for the POSIX form of the defect…</p> <p><strong>Affected:</strong> PyPI: filelock</p> <p>On Windows, `ReadWriteLock` and `AsyncReadWriteLock` (the SQLite-backed reader/writer lock) connect SQLite to the lock database by its path, in every directory. SQLite derives three side files from that path: `&lt;database&gt;-journal`, the rollback journal (pages saved to undo an interrupted write); `&lt;database&gt;-wal`, the write-ahead log (changes kept outside the main file); and `&lt;database&gt;-shm`, the shared-memory index of the WAL. SQLite acts on whichever of these it finds beside the database before the lock runs any statement. Another local account that can create files in the database&#39;s directory, but not delete files of other accounts there, places such a side file beside the database and denies everyone `DELETE` on it, which a file&#39;s creator may do. `C:\Windows\Temp` (the temporary directory of services, granting `BUILTIN\Users` create but not delete) and `C:\Users\Public` are such directories.</p> <p>With a `-wal` in place, every `read_lock()` and `write_lock()` of the user running the lock (below: the lock user) raises `sqlite3.OperationalError: disk I/O error` at once, whatever `timeout` says, until that account removes its file; the lock user cannot. With a `-journal` beside a lock database that holds a table, SQLite replays the journal and deletes the file the journal names, a file of the lock user, and the acquire reports success. Affected versions are filelock 3.20.4 through 4.2.0 on Windows. The maintainers found this while reviewing the fix for the POSIX form of the defect…</p> https://db.gcve.eu/vuln/ghsa-9vhv-jxww-xfm5 https://db.gcve.eu/vuln/ubuntu-cve-2026-112913 <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 until 4.2.1, ReadWriteLock and AsyncReadWriteLock on Windows use _connect to attach SQLite to the lock database by pathname, allowing another local account that can create adjacent names to place a database-wal or database-journal side file before acquisition. An undeletable WAL file makes each read or write acquisition fail immediately with sqlite3.OperationalError regardless of timeout. Separately, when the database contains at least one table, a hot journal that grants the lock account modify rights can cause SQLite recovery to delete a file named by that journal only when the lock account has permission to delete the target. The issue requires a directory writable by another account, such as a shared Windows temporary directory, and does not affect private directories. This issue is fixed in version 4.2.1.</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 until 4.2.1, ReadWriteLock and AsyncReadWriteLock on Windows use _connect to attach SQLite to the lock database by pathname, allowing another local account that can create adjacent names to place a database-wal or database-journal side file before acquisition. An undeletable WAL file makes each read or write acquisition fail immediately with sqlite3.OperationalError regardless of timeout. Separately, when the database contains at least one table, a hot journal that grants the lock account modify rights can cause SQLite recovery to delete a file named by that journal only when the lock account has permission to delete the target. The issue requires a directory writable by another account, such as a shared Windows temporary directory, and does not affect private directories. This issue is fixed in version 4.2.1.</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-112913