CVE-2026-112913: 
Python vulnerability analysis and mitigation

CVE-2026-112913 is a local availability vulnerability in the filelock Python library affecting the ReadWriteLock and AsyncReadWriteLock classes on Windows. When the SQLite-backed lock database resides in a shared directory (e.g., C:\Windows\Temp), a separate local user account can place SQLite side files (e.g., -wal or -journal) beside the database and deny DELETE permissions on them, causing every lock acquisition attempt to raise an unhandled sqlite3.OperationalError. Affected versions are filelock 3.20.4 through 4.2.0 on Windows only; the patched version is 4.2.1. It carries a CVSS v3.1 base score of 3.3 (Low) (GitHub Advisory).

The root cause is classified as CWE-367 (Time-of-Check Time-of-Use / TOCTOU Race Condition). On Windows, _connect opens the lock database via _open_non_reparse_fd and validates the file handle (checking it is a regular file, not a reparse point, and not in WAL mode), but then calls sqlite3.connect(database) by path — without inspecting the SQLite side files (-wal, -journal, -shm) that SQLite automatically processes from the same directory. An adversary with file-creation rights in the database directory (e.g., C:\Windows\Temp, which grants BUILTIN\Users create-but-not-delete-child rights) can pre-place a -wal file and deny DELETE on it; when SQLite attempts to remove the leftover WAL on its first PRAGMA journal_mode=MEMORY statement, it raises SQLITE_IOERR_DELETE, surfacing as sqlite3.OperationalError: disk I/O error. Because _do_acquire_inner only converts "database is locked" errors into Timeout, this exception bypasses all timeout handling and propagates immediately on every acquire call. A secondary "deletion variant" exists: a crafted -journal beside a non-empty database causes SQLite to replay the journal and delete a file of the attacker's choosing that the lock user has write access to (GitHub Advisory).

The primary impact is a partial denial of availability: every read_lock() and write_lock() call on the affected ReadWriteLock raises an uncaught sqlite3.OperationalError immediately, regardless of the configured timeout, for as long as the adversary's side file remains in place. Callers that catch Timeout or OSError will not handle this exception, potentially crashing dependent services or workflows. There is no confidentiality impact (the attacker learns nothing from the lock database), and in the primary variant there is no integrity impact; however, the deletion variant can cause the lock user's process to delete an attacker-chosen file that the lock user has permission to delete, representing a limited integrity impact. The lock database's own contents and mutual exclusion guarantees between legitimate lock users remain intact (GitHub Advisory).

No public exploit code or in-the-wild exploitation has been reported. The vulnerability requires a local account on the same Windows host with file-creation rights in the target directory — a low-privilege, low-complexity precondition. There is no race condition to win; the adversary can plant the side file days before the lock user runs. The vulnerability was discovered internally by the filelock maintainers while reviewing the fix for the related POSIX vulnerability (GHSA-v4x8-3wr5-3wq8) and is not listed in the CISA Known Exploited Vulnerabilities catalog. No EPSS score data is currently available (GitHub Advisory).

1. Identify target: Confirm the victim application uses filelock 3.20.4–4.2.0 on Windows and stores its ReadWriteLock database in a shared directory such as C:\Windows\Temp or C:\Users\Public.
2. Obtain local access: Log in or execute code as any ordinary local user account (BUILTIN\Users) that has file-creation rights in the target directory.
3. Plant the side file: Create a 32-byte (or larger) file named <lockdb>-wal (e.g., mylock.db-wal) beside the lock database in the shared directory.
4. Set ACL to deny DELETE: Use icacls or equivalent to grant everyone Modify rights and explicitly deny everyone DELETE on the planted file: icacls mylock.db-wal /grant *S-1-1-0:(M) /deny *S-1-1-0:(D). The file's creator may set both permissions.
5. Trigger lock failure: When the victim process calls ReadWriteLock(...).write_lock() or read_lock(), SQLite detects the non-WAL database with a leftover -wal file, attempts to delete it, fails with SQLITE_IOERR_DELETE, and raises sqlite3.OperationalError: disk I/O error — bypassing all timeout handling.
6. Sustain denial: The lock user cannot delete the adversary's file; the denial persists until an administrator removes the side file or the adversary withdraws it (GitHub Advisory).

• File System: Unexpected files named <lockdb>-wal, <lockdb>-journal, or <lockdb>-shm appearing beside a ReadWriteLock database in C:\Windows\Temp or C:\Users\Public, owned by a user account other than the lock user or SYSTEM.
• File System: ACL entries on the above side files showing an explicit DENY for DELETE ((D)) for Everyone (*S-1-1-0) or BUILTIN\Users, detectable via icacls <filename>.
• Logs / Application Errors: Repeated sqlite3.OperationalError: disk I/O error or sqlite3.OperationalError: unable to open database file exceptions in application logs originating from filelock's _do_acquire_inner or _connect code paths.
• Process: Application processes that use ReadWriteLock hanging, crashing, or logging unhandled exceptions on every lock acquisition attempt, with no recovery despite configured timeouts (GitHub Advisory).

Upgrade filelock to version 4.2.1, which contains the fix introduced in PR #854. As an immediate workaround, move the ReadWriteLock database to a directory that other local accounts cannot write to, such as %LOCALAPPDATA%, the per-user temporary directory (%TEMP% of a user session), or a directory with inheritance removed and access restricted to the owner, SYSTEM, and Administrators only — C:\Windows\Temp and C:\Users\Public are explicitly unsafe. Additionally, applications can treat sqlite3.OperationalError: disk I/O error on every acquire as a signal of a foreign -wal file beside the database, which only its creator or an administrator can remove (GitHub Advisory).

The vulnerability was discovered by the filelock maintainers themselves (credited to gaborbernat) during an internal review of the POSIX-side fix for GHSA-v4x8-3wr5-3wq8, which was originally reported by Anthropic's OSS Scanner on 15 October 2026. The advisory notes that the Windows side-file effect was not among the 36 findings submitted by the scanner, highlighting the value of maintainer-led security reviews. No broader media coverage or notable community commentary has been identified at this time (GitHub Advisory).