Description

filelock is a platform-independent file lock for Python. From 3.10.0 until 4.2.1, filelock on Windows ignores the mode argument for WindowsFileLock files and the ReadWriteLock SQLite database. A lock created with mode=0o600 receives the parent directory's inheritable ACL because _open_non_reparse_fd and _nt_open do not create an owner-only security descriptor. Another local account with inherited access can read holder metadata or the lock database, modify those files where the ACL permits writes, or take the byte-range lock after release and delay later acquisitions. UnixFileLock is not affected, and mutual exclusion between cooperating processes continues to hold. This issue is fixed in version 4.2.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-11-05T22:17:46.877Z",
  "pubdate": "2026-11-05T22:17:46.877Z",
  "executiveSummary": "The filelock library for Python is susceptible to an insecure file permission vulnerability on Windows platforms affecting versions 3.10.0 through 4.2.0. The vulnerability stems from the library's failure to correctly apply restricted security descriptors (ACLs) when creating lock files or the internal SQLite-based ReadWriteLock database.\nSpecifically, the mode argument is ignored, causing files to inherit default access control lists from their parent directory instead of adhering to the intended restricted (e.g., 0o600) permissions. This security misconfiguration allows other local users on the same Windows host to read sensitive lock metadata, manipulate the state of the lock database, or interfere with lock acquisition processes.\nThe risk is limited to local exploitation, requiring an attacker to have a local user account on the affected machine. Successful exploitation does not bypass mutual exclusion mechanisms for cooperating processes, but it facilitates unauthorized information disclosure and potential denial-of-service through resource contention or lock database corruption. Users are advised to upgrade to version 4.2.1 or later to remediate the underlying flaw.",
  "technicalDetails": "The vulnerability resides in the Windows-specific implementation of the filelock library, specifically within the file handling routines _open_non_reparse_fd and _nt_open. These functions are responsible for creating lock files and the ReadWriteLock SQLite database. Analysis confirms that the mode parameter, which is intended to enforce specific POSIX-like permissions (such as 0o600, owner-read/write only), is silently ignored during the file creation process.\nThe root cause is the failure of the library to explicitly define and apply a Windows security descriptor that restricts access to the file owner. Because no custom security descriptor is supplied during the creation of these file objects, the Windows kernel applies the standard inheritable ACLs from the parent directory. Consequently, any local user account that possesses inherited read or write permissions on the directory where the lock file resides automatically gains equivalent access to the lock file or database itself.\nThe attack flow proceeds as follows: First, a victim application protected by filelock initializes a lock, expecting it to be private to the user account. Because the library fails to apply an restrictive ACL, the file is created with inherited permissions that include access for the 'Users' group or other specific local accounts. Second, an attacker with local access identifies the lock file or the SQLite database file on the filesystem. Third, the attacker leverages these unauthorized permissions to read the contents of the database, which may contain sensitive holder metadata, or modifies the file to interfere with the application's synchronization logic.\nIn scenarios involving the ReadWriteLock, an attacker can corrupt the database file or manipulate its state, potentially causing the application to hang or fail during lock acquisition. Furthermore, an attacker can monitor the lock status to gain insights into process execution timing or delay subsequent acquisitions by manipulating byte-range locks once a legitimate holder releases the resource. This vulnerability is strictly local; the UnixFileLock implementation is not affected as it correctly handles file mode bits on Unix-like systems. No network exposure is required for this attack, and the primary impact involves privilege escalation in the form of unauthorized filesystem access and local service disruption."
}