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

CVE-2026-112910 is an incorrect permission assignment vulnerability in the Python filelock library on Windows, where the WindowsFileLock class ignores the mode argument when creating lock files. When a caller specifies FileLock(path, mode=0o600), the resulting file is created with no security descriptor of its own — its ACL is inherited from the parent directory — making it indistinguishable from a lock file created without any mode restriction. The same flaw affects the ReadWriteLock SQLite database, which filelock internally requests with 0o600. Affected versions are filelock 3.10.0 through 4.2.0 on Windows only; Unix is not affected. The vulnerability carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, tox-dev Advisory).

The root cause is CWE-732 (Incorrect Permission Assignment for Critical Resource). In _open_non_reparse_fd, the mode argument is reduced to a single read_only bit, which is always False for any accepted mode (since _check_mode requires owner read+write). The internal _nt_open function populates an OBJECT_ATTRIBUTES structure for NtCreateFile but leaves the SecurityDescriptor field NULL. Per Windows/NTFS semantics, a NULL security descriptor causes the new file to inherit the parent directory's ACL rather than applying any explicit access restriction. Consequently, FileLock(path, mode=0o600) and FileLock(path) produce identical NtCreateFile call sequences and identical file ACLs. The bug was introduced in commit d0061e4 (PR #192, 2023-03-15) when multiuser support and the mode parameter were added, and has been present since version 3.10.0 (GitHub Advisory, Fix PR #835).

In a directory whose inheritable ACL grants other local accounts read or modify access to new files (e.g., a service data directory readable by the Users group, or any directory with (OI)(CI) inheritable entries), a low-privileged local account can open the lock file or ReadWriteLock database that was intended to be owner-only. With read access, the attacker can acquire the byte-range lock whenever the owner releases it, causing the owner's subsequent acquire() calls to wait indefinitely or time out (availability impact), and can read holder metadata written by an on_acquired hook into a preserve_lock_file=True file (confidentiality impact). Where the directory grants modify access, the attacker can also write to both the lock file and the ReadWriteLock database, corrupting lock state (integrity impact). The scope is limited to the lock file and database themselves; mutual exclusion between cooperating processes and data protected by the lock are not directly compromised (tox-dev Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported. The vulnerability was discovered and reported privately by Anthropic's automated OSS Scanner on October 15, 2026, and confirmed by the maintainers on Windows 11 with two local accounts before public disclosure. Exploitation requires a local logon on the same Windows host and a low-privileged account — no race condition or elevated privileges are needed. The CVE status is listed as Reserved and there is no CISA KEV catalog entry. No EPSS score is currently available (GitHub Advisory, tox-dev Advisory).

1. Identify a vulnerable deployment: Confirm the target Windows system runs a Python application using filelock versions 3.10.0–4.2.0, and that lock files or ReadWriteLock databases are stored in a directory whose ACL grants inheritable read or modify access to other local accounts (e.g., a service data directory with (OI)(CI) entries for Users).
2. Obtain a local account: Log in or obtain a shell as any low-privileged local account on the same host (no elevation required).
3. Locate the lock file or database: Identify the path of the lock file (e.g., app.lock) or ReadWriteLock SQLite database. These files inherit the directory ACL and are accessible despite lock.mode reporting 0o600.
4. Open the lock file: Use any standard file open call (e.g., Python's open(), CreateFile via ctypes, or a tool like handle.exe) to open the lock file for read (or read/write if the directory grants modify access).
5. Acquire the byte-range lock: Call LockFileEx on the opened handle to take the byte-range lock once the owner releases it, preventing the owner's subsequent acquire() from succeeding (causing timeouts or indefinite blocking).
6. Read holder metadata: If the owner uses preserve_lock_file=True with an on_acquired hook that writes metadata, read the lock file contents to obtain that metadata.
7. Optionally corrupt lock state: If the directory grants modify access, write arbitrary data to the lock file or ReadWriteLock database to corrupt the lock's internal state (GitHub Advisory, tox-dev Advisory).

• File System: Lock files (e.g., *.lock) or ReadWriteLock SQLite databases in shared directories showing only inherited ACL entries ((I)) when inspected with icacls, even when the application was configured with mode=0o600; presence of ReadWriteLock database files (e.g., *.db) in directories accessible to non-owner accounts.
• Logs: Application logs showing repeated Timeout exceptions or unexpectedly long acquire() waits on FileLock or ReadWriteLock objects, potentially indicating another process is holding the byte-range lock.
• Process: Unexpected processes from non-owner accounts holding open handles to lock files or SQLite databases (detectable via handle.exe or Process Monitor on Windows); unusual file read/write activity on lock files by processes not belonging to the owning service or user account.

Patch: Upgrade filelock to version 4.2.1 or later, which fixes the issue by using ConvertStringSecurityDescriptorToSecurityDescriptorW to build an owner-only DACL (granting access to the owner, SYSTEM, and Administrators only) when mode has no group or other bits (e.g., 0o600), and passes this descriptor in the NtCreateFile call (filelock 4.2.1 Release, Fix PR #835).

Workarounds (if patching immediately is not possible):

• Store lock files and ReadWriteLock databases in a directory whose ACL already excludes other accounts, such as inside the user profile or a directory with inheritance disabled and only the owner, SYSTEM, and Administrators granted access.
• After creating a lock file with preserve_lock_file=True or a ReadWriteLock database, manually set its ACL: icacls <file> /inheritance:r /grant:r "<owner>:F" "SYSTEM:F" "Administrators:F".
• Do not store confidential information in lock files via on_acquired hooks on Windows (tox-dev Advisory).

The vulnerability was reported privately by Anthropic's automated OSS Scanner on October 15, 2026, and the maintainers (gaborbernat) confirmed it on Windows 11 with two local accounts before publishing the advisory on October 17, 2026. The maintainers characterized it as a long-standing gap rather than a regression, noting the Windows backend had never applied more than the read-only attribute from the mode since version 3.10.0. The fix was merged the same day the advisory was published. Downstream projects such as gira-de/splat and verifywise-ai/verifywise promptly updated their dependencies to 4.2.1 following disclosure (tox-dev Advisory, Fix PR #835).