<?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>Wed, 11 Nov 2026 08:55:05 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-112908 — filelock: StrictSoftFileLock creates its claim directories without the lock mode, so another local user with a write bi…</title>
      <link>https://db.gcve.eu/vuln/cve-2026-112908</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 version 3.30.0 until version 4.2.1,  StrictSoftFileLock  and  AsyncStrictSoftFileLock  on POSIX systems create coordination and claim directories without applying the caller’s restrictive lock mode. A permissive umask or inherited default ACL can leave these directories writable by another local user, allowing that user to delete an active holder’s claims. Another authorized process can then acquire the lock while the original holder remains in its critical section. An attacker can also plant malformed claims to prevent acquisition. This issue is fixed in version 4.2.1.&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 version 3.30.0 until version 4.2.1,  StrictSoftFileLock  and  AsyncStrictSoftFileLock  on POSIX systems create coordination and claim directories without applying the caller’s restrictive lock mode. A permissive umask or inherited default ACL can leave these directories writable by another local user, allowing that user to delete an active holder’s claims. Another authorized process can then acquire the lock while the original holder remains in its critical section. An attacker can also plant malformed claims to prevent acquisition. This issue is fixed in version 4.2.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-112908</guid>
    </item>
  </channel>
</rss>
