CVE-2026-112913: 
Python Análise e mitigação de vulnerabilidades

CVE-2026-112913 is a local denial-of-service vulnerability in the Python filelock library affecting ReadWriteLock and AsyncReadWriteLock on Windows. When these SQLite-backed locks store their database in a shared directory (such as C:\Windows\Temp or C:\Users\Public), another local account can place SQLite side files (-wal, -journal, -shm) beside the database and deny everyone DELETE permission on them, causing every lock acquisition to fail with sqlite3.OperationalError. Affected versions are filelock 3.20.4 through 4.2.0 on Windows only; the issue was discovered by the maintainers on 2026-10-16 while reviewing the POSIX fix for the related GHSA-v4x8-3wr5-3wq8, and the advisory was published on 2026-10-17. It carries a CVSS v3.1 base score of 3.3 (Low) (Github Advisory, filelock Security Advisory).

The root cause is classified as CWE-367 (Time-of-check Time-of-use / TOCTOU Race Condition). On Windows, _connect in filelock checks the database file through a handle (verifying it is a regular file, not a reparse point, and not in WAL mode), but then calls sqlite3.connect(database, ...) using the plain file path. SQLite automatically looks for side files (-wal, -journal, -shm) beside that path before executing any statement. A low-privileged local attacker who can create files in the database directory (e.g., C:\Windows\Temp, which grants BUILTIN\Users create-but-not-delete rights) can place a crafted -wal file and set its ACL to deny DELETE to everyone — including the lock user — causing PRAGMA journal_mode=MEMORY to raise SQLITE_IOERR_DELETE, which propagates as sqlite3.OperationalError: disk I/O error on every acquire call, bypassing the configured timeout. A secondary variant using a crafted -journal file can cause the lock user's process to silently delete an attacker-chosen file (Github Advisory, filelock Security Advisory).

The primary impact is a persistent denial of service against any application using ReadWriteLock or AsyncReadWriteLock with a database in a shared Windows directory: every read_lock() and write_lock() call raises an uncaught sqlite3.OperationalError immediately, regardless of the configured timeout, for as long as the attacker's side file remains. There is no confidentiality impact (the attacker learns nothing from the lock database), and in the primary scored variant there is no integrity impact (the lock's own database is unchanged and mutual exclusion between legitimate lock users is preserved). A secondary, harder-to-trigger variant (requiring a database with at least one table and a specially crafted -journal file) can cause the lock user's process to delete an attacker-chosen file that the lock user has permission to delete, introducing a limited integrity impact (Github Advisory, filelock Security Advisory).

No public exploit code or in-the-wild exploitation has been reported for CVE-2026-112913. The vulnerability requires a local account on the same Windows host with the ability to create files in the shared directory containing the lock database — a low-privilege requirement with no race condition needed, as the attacker can plant the side file days in advance. The CVE status is listed as Reserved and no EPSS score or CISA KEV catalog entry has been identified. A detailed reproducer script (win_two_accounts.py) was published as part of the advisory, demonstrating the attack on Windows 11 with CPython 3.14 and SQLite 3.53.1 (Github Advisory, filelock Security Advisory).

1. Identify target: Confirm the victim application uses filelock 3.20.4–4.2.0 on Windows and stores its ReadWriteLock or AsyncReadWriteLock database in a shared directory such as C:\Windows\Temp or C:\Users\Public.
2. Locate the database path: Determine the exact filename of the SQLite lock database (e.g., C:\Windows\Temp\myapp-lock.db).
3. Create the side file: As a low-privileged local account, create a file named <database>-wal (e.g., C:\Windows\Temp\myapp-lock.db-wal) with at least 32 bytes of content (e.g., null bytes) in the same directory.
4. Set the ACL: Use icacls to grant everyone Modify rights and explicitly deny everyone DELETE on the planted file:

   icacls C:\Windows\Temp\myapp-lock.db-wal /grant *S-1-1-0:(M)
   icacls C:\Windows\Temp\myapp-lock.db-wal /deny *S-1-1-0:(D)

5. Trigger denial of service: Any subsequent call to read_lock() or write_lock() by the victim application raises sqlite3.OperationalError: disk I/O error immediately, bypassing the configured timeout. The lock user cannot delete the file, so the DoS persists until an administrator removes it.
6. (Optional) File deletion variant: For a database that already contains at least one table, craft a 46-byte hot -journal file whose tail names a target file the lock user can delete, then grant the lock user Modify rights (but not deny DELETE). When the lock user next calls write_lock(), SQLite replays the journal and deletes the named file, while the acquire reports success (Github Advisory, filelock Security Advisory).

• File System: Unexpected files named <lockdb>-wal, <lockdb>-journal, or <lockdb>-shm appearing beside a filelock SQLite database in C:\Windows\Temp or C:\Users\Public, especially with ACLs that deny DELETE to all users.
• File System: Files in shared directories with icacls entries showing /deny *S-1-1-0:(D) (deny DELETE for Everyone) set by an account other than the database owner or SYSTEM/Administrators.
• Logs: Application logs showing repeated sqlite3.OperationalError: disk I/O error or sqlite3.OperationalError: unable to open database file on every lock acquisition attempt, with no recovery over time.
• Process: Unexpected use of icacls.exe by a low-privileged user account in C:\Windows\Temp or C:\Users\Public, particularly setting deny ACEs on files with names matching *.db-wal or *.db-journal patterns.

Upgrade filelock to version 4.2.1, which resolves this issue by reading the database directory's ACL and, where other accounts can add or remove names, connecting SQLite through a private hard link inside a directory restricted to the locking account, SYSTEM, and Administrators (filelock Release 4.2.1, Fix PR #854). If upgrading immediately is not possible, move the ReadWriteLock database out of shared directories: use %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 — C:\Windows\Temp and C:\Users\Public do not qualify. As an additional detection measure, treat repeated sqlite3.OperationalError: disk I/O error on every acquire as a signal that a foreign -wal file has been planted beside the database, which only its creator or an administrator can remove (Github Advisory).

The vulnerability was discovered internally by the filelock maintainers (gaborbernat) during a security review of a related POSIX vulnerability reported by Anthropic's OSS Scanner, and was not among the 36 findings in the original scanner report. The fix was developed and merged within approximately 24 hours of discovery (2026-10-16 to 2026-10-17), reflecting a rapid response by the maintainer. No significant broader media coverage or notable external researcher commentary has been identified beyond the advisory and associated GitHub pull request discussion (Github Advisory, Fix PR #854).