<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 31 Oct 2026 13:20:21 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-112936 — filelock: ReadWriteLock follows a symlink at the lock path into SQLite</title>
      <link>https://db.gcve.eu/vuln/cve-2026-112936</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; tox-dev filelock&lt;/p&gt;
&lt;p&gt;filelock is a platform-independent file lock for Python. From 3.20.4 until 4.0.9, ReadWriteLock and AsyncReadWriteLock versions from 3.20.4 resolve the lock path and pass it to SQLite without rejecting a final symbolic link, allowing another local user who can create names in the lock directory to redirect database creation and locking or split mutual exclusion between targets. This issue is fixed in version 4.0.9.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; tox-dev filelock&lt;/p&gt;
&lt;p&gt;filelock is a platform-independent file lock for Python. From 3.20.4 until 4.0.9, ReadWriteLock and AsyncReadWriteLock versions from 3.20.4 resolve the lock path and pass it to SQLite without rejecting a final symbolic link, allowing another local user who can create names in the lock directory to redirect database creation and locking or split mutual exclusion between targets. This issue is fixed in version 4.0.9.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-112936</guid>
    </item>
    <item>
      <title>GHSA-j8f7-rjxc-mr56 — filelock: ReadWriteLock follows a symlink at the lock path into SQLite</title>
      <link>https://db.gcve.eu/vuln/ghsa-j8f7-rjxc-mr56</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: filelock&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;`ReadWriteLock` and `AsyncReadWriteLock` resolve the lock path with `pathlib.Path.resolve()` and pass it to `sqlite3.connect()` without refusing a symlink. A local user who can create names in the lock&amp;#39;s directory, such as `/tmp` or a shared cache, can plant a symlink at the lock path and make the victim&amp;#39;s process create, lock, or write the file it points to, or break mutual exclusion between the victim&amp;#39;s own processes.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`ReadWriteLock.__init__` stores `pathlib.Path(lock_file).resolve()`, which follows a final symlink, and every connection opens that path through `sqlite3.connect()` with no `O_NOFOLLOW` or regular-file check. SQLite&amp;#39;s own VFS also resolves the final symlink in user space, so `fs.protected_symlinks` and the sticky bit do not help: the kernel never sees a symlink to refuse. The other lock classes do not follow a final symlink: `FileLock` opens with `O_NOFOLLOW`, and `SoftReadWriteLock` coordinates through `&amp;lt;path&amp;gt;.rw/`.&lt;/p&gt;
&lt;p&gt;### Proof of concept&lt;/p&gt;
&lt;p&gt;On Linux, with the victim and attacker as different users and `/shared` mode 1777 with `fs.protected_symlinks=1`:&lt;/p&gt;
&lt;p&gt;1. The attacker runs `ln -s /home/victim/private/pwned.flag /shared/app.rwlock.db`.
2. The victim constructs `ReadWriteLock(&amp;#34;/shared/app.rwlock.db&amp;#34;)`. A plain `os.open(..., O_NOFOLLOW)` on the same path fails, but the lock creates `/home/victim/private/pwned.flag`, owned by the victim, inside a directory the attacker cannot write.
3. With `/shared/cache.rwlock.db -&amp;gt; /shared/a.db`, one…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: filelock&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;`ReadWriteLock` and `AsyncReadWriteLock` resolve the lock path with `pathlib.Path.resolve()` and pass it to `sqlite3.connect()` without refusing a symlink. A local user who can create names in the lock&amp;#39;s directory, such as `/tmp` or a shared cache, can plant a symlink at the lock path and make the victim&amp;#39;s process create, lock, or write the file it points to, or break mutual exclusion between the victim&amp;#39;s own processes.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`ReadWriteLock.__init__` stores `pathlib.Path(lock_file).resolve()`, which follows a final symlink, and every connection opens that path through `sqlite3.connect()` with no `O_NOFOLLOW` or regular-file check. SQLite&amp;#39;s own VFS also resolves the final symlink in user space, so `fs.protected_symlinks` and the sticky bit do not help: the kernel never sees a symlink to refuse. The other lock classes do not follow a final symlink: `FileLock` opens with `O_NOFOLLOW`, and `SoftReadWriteLock` coordinates through `&amp;lt;path&amp;gt;.rw/`.&lt;/p&gt;
&lt;p&gt;### Proof of concept&lt;/p&gt;
&lt;p&gt;On Linux, with the victim and attacker as different users and `/shared` mode 1777 with `fs.protected_symlinks=1`:&lt;/p&gt;
&lt;p&gt;1. The attacker runs `ln -s /home/victim/private/pwned.flag /shared/app.rwlock.db`.
2. The victim constructs `ReadWriteLock(&amp;#34;/shared/app.rwlock.db&amp;#34;)`. A plain `os.open(..., O_NOFOLLOW)` on the same path fails, but the lock creates `/home/victim/private/pwned.flag`, owned by the victim, inside a directory the attacker cannot write.
3. With `/shared/cache.rwlock.db -&amp;gt; /shared/a.db`, one…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-j8f7-rjxc-mr56</guid>
    </item>
  </channel>
</rss>
