Filelock: SoftReadWriteLock Holder Refresh Writes Through A Hard Link And Hangs On A Named Pipe That Another Local User

"SoftReadWriteLock" and "AsyncSoftReadWriteLock", which wraps one refreshes its holder record the file under ".rw/holders/" that says a process holds or wants the lock on every poll of a waiting acquire and on every heartbeat the periodic refresh a holder runs to keep its record fresh. It does so...

Filelock ReadWriteLock: A Crafted Lock Database Makes Every Acquire Stall Or Hang Regardless Of Timeout

"ReadWriteLock" and "AsyncReadWriteLock" the SQLite-backed reader/writer lock run "PRAGMA journalmode=MEMORY" on a fresh connection for every acquire. That statement makes SQLite load the whole schema the "sqlitemaster" table, which lists every table and index with its "CREATE" text of whatever...

Filelock: Symlink Swap During SoftFileLock's Writability Check Leaks Whether A Path Exists And Is Writable By The Lock T

"raiseonnotwritablefile" is the check that "SoftFileLock" and the locks sharing its acquire path run before every attempt. It looks at the lock path with "os.lstat", so that it judges a planted symlink a file that points at another path by itself. When the node has no owner-write bit, it then cal...

Filelock: StrictSoftFileLock And SoftReadWriteLock Adopt A Protocol Directory Another User Created First, Losing Mutual

"StrictSoftFileLock", "AsyncStrictSoftFileLock", "SoftReadWriteLock" and "AsyncSoftReadWriteLock" keep their whole ownership state as files in a directory derived from the lock path ".filelock/claims", ".rw/gen,holders". When that directory already exists they adopt it after checking only that it...

Filelock: WindowsFileLock Ignores Mode: A 0o600 Lock File And The ReadWriteLock Database Inherit The Directory ACL

filelock on Windows ignores the "mode" argument. "FileLockpath, mode=0o600" creates the same file as "FileLockpath": one with no security descriptor of its own the Windows record that says who may access a file. Its access list, or ACL, is whatever the lock directory hands down to new files...

Filelock: UnixFileLock Truncates And Chmods Any Regular File Another User Renames Or Hard-links Onto The Lock Path

"UnixFileLock", the backend of "FileLock" and "AsyncFileLock" on Unix, empties whatever regular file it finds at the lock path once it holds the "flock" a kernel lock on an open file. With an explicit "mode" it also chmods that file sets its permission bits, whether or not this acquire created it...

Filelock: StrictSoftFileLock Creates Its Claim Directories Without The Lock Mode, So Another Local User With A Write Bit

"StrictSoftFileLock" and "AsyncStrictSoftFileLock" apply the caller's "mode" to the sentinel the lock file at "" and to both claim files the files whose presence says a process wants or holds the lock. They create the two directories that hold the claims, ".filelock" and ".filelock/claims", with ...

CVE-2026-112938

"StrictSoftFileLock" and "AsyncStrictSoftFileLock" check ".filelock" the coordination directory that holds the lock's state with one "lstat" call on its name. "lstat" reports what a name is without following a symbolic link a file that redirects to another path. After that check, the code reaches...

0din-litellm-shield (>=0.2.0, <=0.3.0), 0xpwn (0.1.0) +5873 more potentially affected by CVE-2026-112938 via filelock (>=3.30.3, <=4.2.0)

filelock PYPI version =3.30.3, =0.2.0, =2.3.84, =0.4.0, =0.2.0, =0.2.0, =0.3.1, =0.2.0, =0.2.0, =0.2.0, =0.1.0, =0.1.0, =0.1.0, =0.3.0, =0.4.2 - a13n-claw 0.1.0 and more Source cves: CVE-2026-112938 Source advisory: MEND:CVE-2026-112938...

CVE-2026-112910

filelock on Windows ignores the "mode" argument. "FileLockpath, mode=0o600" creates the same file as "FileLockpath": one with no security descriptor of its own the Windows record that says who may access a file. Its access list, or ACL, is whatever the lock directory hands down to new files...

0din-litellm-shield (>=0.2.0, <=0.3.0), 0xpwn (0.1.0) +6518 more potentially affected by CVE-2026-112910 via filelock (>=3.10.0, <=4.2.0)

filelock PYPI version =3.10.0, =0.2.0, =2.3.84, =0.4.0, =0.2.0, =0.2.0, =0.3.1, =0.2.0, =0.2.0, =0.2.0, =0.1.0, =0.1.0, =0.1.0, =0.3.0, =0.4.2 - a13n-claw 0.1.0 and more Source cves: CVE-2026-112910 Source advisory: MEND:CVE-2026-112910...

CVE-2026-112908

"StrictSoftFileLock" and "AsyncStrictSoftFileLock" apply the caller's "mode" to the sentinel the lock file at "" and to both claim files the files whose presence says a process wants or holds the lock. They create the two directories that hold the claims, ".filelock" and ".filelock/claims", with ...

0din-litellm-shield (>=0.2.0, <=0.3.0), 0xpwn (0.1.0) +5873 more potentially affected by CVE-2026-112908 via filelock (>=3.30.3, <=4.2.0)

filelock PYPI version =3.30.3, =0.2.0, =2.3.84, =0.4.0, =0.2.0, =0.2.0, =0.3.1, =0.2.0, =0.2.0, =0.2.0, =0.1.0, =0.1.0, =0.1.0, =0.3.0, =0.4.2 - a13n-claw 0.1.0 and more Source cves: CVE-2026-112908 Source advisory: MEND:CVE-2026-112908...

atsfill (>=0.0.4.dev96, <=0.0.8.dev229), gam7 (7.50.0) +2 more potentially affected by CVE-2026-112941 via filelock (>=4.1.1, <=4.2.0)

filelock PYPI version =4.1.1, =0.0.4.dev96, =0.2.1, =0.2.2 Source cves: CVE-2026-112941 Source advisory: OSV:GHSA-WFHQ-Q4J2-C37M...

filelock: SoftReadWriteLock follows a lock tree swapped in after its first acquire and writes lock records into directories of the user running the lock

SoftReadWriteLock and AsyncSoftReadWriteLock, which wraps one checks once per lock object, by name, that .rw, .rw/gen and .rw/holders are real directories and not symbolic links files that redirect to another path. It then keeps only a boolean. Every later record operation resolves the full path...

EUVD-2026-105032

filelock: SoftReadWriteLock follows a lock tree swapped in after its first acquire and writes lock records into directories of the user running the lock...

GHSA-WFHQ-Q4J2-C37M filelock: SoftReadWriteLock follows a lock tree swapped in after its first acquire and writes lock records into directories of the user running the lock

SoftReadWriteLock and AsyncSoftReadWriteLock, which wraps one checks once per lock object, by name, that .rw, .rw/gen and .rw/holders are real directories and not symbolic links files that redirect to another path. It then keeps only a boolean. Every later record operation resolves the full path...

atsfill (>=0.0.4.dev96, <=0.0.8.dev229), gam7 (7.50.0) +2 more potentially affected by CVE-2026-112941 via filelock (>=4.1.1, <=4.2.0)

filelock PYPI version =4.1.1, =0.0.4.dev96, =0.2.1, =0.2.2 Source cves: CVE-2026-112941 Source advisory: GHSA-WFHQ-Q4J2-C37M...

filelock: StrictSoftFileLock creates its claim directories without the lock mode, so another local user with a write bit on them can end a live hold

StrictSoftFileLock and AsyncStrictSoftFileLock apply the caller's mode to the sentinel the lock file at and to both claim files the files whose presence says a process wants or holds the lock. They create the two directories that hold the claims, .filelock and .filelock/claims, with a bare mkdir...

Incorrect Permission Assignment for Critical Resource

Overview Affected versions of this package are vulnerable to Incorrect Permission Assignment for Critical Resource via the strict-mode lock implementation in strict.py and related soft read-write lock components, where claim directories are created with permissions that allow other local users to...