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

CVE-2026-112907 is an oplock-based denial-of-service vulnerability in the Python filelock library affecting soft lock classes (SoftFileLock, MarkerSoftFileLock, SoftFileLease, their async forms, and FileLock after its ENOSYS fallback) on Windows. A low-privileged local account can take a Level 1 opportunistic lock (oplock) on a soft lock's marker file and leave the break unanswered, causing every acquire() call by the lock user to block indefinitely past its configured timeout, blocking=False, and cancel_check parameters. Affected versions are filelock 3.22.0 through 4.2.0 on Windows only. The vulnerability was identified by the filelock maintainers on 2026-10-16 while reviewing a fix for a related report from Anthropic's OSS Scanner, and a patch was published on 2026-10-17. It carries a CVSS v3.1 base score of 2.5 (Low) (GitHub Advisory, Security Advisory).

The root cause is improper locking (CWE-667): the soft lock classes read their marker file using os.open(path, O_RDONLY) and break stale markers via os.rename and os.unlink by path. On Windows, these calls translate to CreateFileW, which — unlike on Unix — waits for any outstanding oplock holder to acknowledge a break before returning. Because O_NOFOLLOW and O_NONBLOCK do not exist on Windows (the code reads them with getattr(os, ..., 0) and gets 0), no non-blocking flag is passed. The deadline check (_check_give_up) is only consulted between retry attempts, not during the blocking system call, so the wait overruns timeout, blocking=False, and cancel_check entirely. The vulnerability was introduced in commit e35c3af (PR #476, 2026-02-13, first tag 3.22.0), which added stale-lock detection and began opening existing markers; prior versions never opened an existing marker file (GitHub Advisory, Fix PR).

The primary impact is a partial availability denial of service: a low-privileged local attacker can cause any thread (or the entire asyncio event loop when run_in_executor=False) attempting to acquire a soft file lock to block for approximately 10 seconds per attempt in two-account tests, or indefinitely until the oplock holder closes its handle. No process can acquire the lock while the oplock is held on a stale marker, effectively freezing any workload that depends on the lock. Confidentiality and integrity are not affected — mutual exclusion is preserved and no files other than the marker are read, written, or deleted. The impact is scoped to the local host and does not enable lateral movement or data exfiltration (GitHub Advisory, Security Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported. The vulnerability has high attack complexity (AC:H) because Windows grants a Level 1 oplock only when no other handle is open on the marker file, requiring the attacker to wait for a window where the holder has died, closed its descriptor, or left a stale marker. The CVE status is listed as "Reserved" and no EPSS score or CISA KEV catalog entry is available. A detailed reproduction script (oplock_vm.py) was included in the maintainers' advisory, demonstrating the stall, but this is a research/verification tool rather than a weaponized exploit (GitHub Advisory, Feedly).

1. Reconnaissance: Identify a Windows host running a Python application that uses filelock versions 3.22.0–4.2.0 with soft lock classes (SoftFileLock, MarkerSoftFileLock, SoftFileLease, or FileLock with ENOSYS fallback). Confirm the lock marker directory has inheritable ACL entries granting the attacker's account read access to new files.
2. Wait for an unheld marker: Monitor the lock marker file (e.g., app.lock) for a window when no process holds it open — such as after the legitimate holder has died, closed its file descriptor, or left a stale marker past its lifetime. Windows only grants a Level 1 oplock when no other handle is open.
3. Take a Level 1 oplock: From the attacker's local account, open the marker file with CreateFileW using GENERIC_READ and FILE_FLAG_OVERLAPPED, then issue DeviceIoControl(FSCTL_REQUEST_OPLOCK_LEVEL_1). Keep the overlapped request pending and never acknowledge the break notification.
4. Trigger the stall: When the legitimate lock user calls SoftFileLock.acquire(), its _read_lock_file function calls os.open(path, O_RDONLY), which internally calls CreateFileW. Windows sends a break request to the oplock holder (the attacker) and blocks the lock user's call until the attacker acknowledges or closes the handle.
5. Sustain the denial: Keep the oplock handle open and the break unanswered. The lock user's acquire() will return Timeout after ~10 seconds per attempt (in two-account tests), and stale markers cannot be broken, so no process can acquire the lock. Re-request the oplock between the lock user's attempts to maintain the stall indefinitely (GitHub Advisory, Security Advisory).

• Process Behavior: Python processes or threads blocked for 10+ seconds inside os.open on a .lock marker file; SoftFileLock.acquire() consistently returning Timeout well beyond the configured timeout value; asyncio event loops stalling when AsyncSoftFileLock(run_in_executor=False) is used.
• File System: Presence of stale .lock marker files that are not being cleaned up despite the legitimate holder process being dead; marker files remaining on disk past their expected lifetime.
• Logs: Application logs showing repeated Timeout exceptions from filelock acquire calls with elapsed times significantly exceeding the configured timeout (e.g., Timeout after 10.02 s when timeout=1 was set); Python stack traces showing threads blocked in os.open or _read_lock_file.
• Network/OS: A second local account holding an open file handle (with FILE_FLAG_OVERLAPPED) on a .lock marker file, observable via tools like Process Explorer or handle.exe from Sysinternals; DeviceIoControl calls with FSCTL_REQUEST_OPLOCK_LEVEL_1 (0x00090000) issued against lock marker files.

Upgrade filelock to version 4.2.1 or later, which fixes the issue by reading markers through handles opened with FILE_COMPLETE_IF_OPLOCKED (so an unanswered break ends the poll as contention rather than blocking) and deleting markers via FILE_DELETE_ON_CLOSE handles (Fix PR, Release 4.2.1). If immediate upgrade is not possible, apply one of these workarounds:

• Restrict the marker directory ACL: Place soft-lock markers in a directory whose ACL grants no other local accounts access to new files — for example, a directory inside the user profile, or one configured with icacls /inheritance:r /grant:r "OWNER:(OI)(CI)F" "SYSTEM:(OI)(CI)F" "Administrators:(OI)(CI)F". Note that the mode parameter does not achieve this on Windows.
• Use the default executor: Run AsyncSoftFileLock with the default executor (not run_in_executor=False) so that only a worker thread blocks rather than the entire event loop (Security Advisory).

The vulnerability was discovered internally by the filelock maintainers (gaborbernat) during a security review triggered by a report from Anthropic's OSS Scanner, though this specific finding was not among the scanner's original 36 findings. The fix was merged the same day the finding was identified (2026-10-16) and released in filelock 4.2.1 on 2026-10-17. Downstream projects such as gira-de/splat promptly updated their dependencies to 4.2.1 in response to the advisory. No significant broader media coverage or social media discussion has been observed, consistent with the vulnerability's Low severity rating (GitHub Advisory, Fix PR).