CVE-2026-22701: 
Python vulnerability analysis and mitigation

CVE-2026-22701 is a Time-of-Check Time-of-Use (TOCTOU) symlink vulnerability in the SoftFileLock implementation of the Python filelock package. It affects all versions of filelock prior to 3.20.3 and was disclosed on January 9, 2026, by researcher George Tsigourakos (@tsigouris007). The vulnerability carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory). Downstream products from IBM (Watson Discovery, Watson Speech Services, Maximo Application Suite, Cloud Pak for Business Automation, Instana, Guardium, watsonx Orchestrate, and others) and Microsoft Azure Linux 3 are also affected (IBM Watson Discovery, Microsoft MSRC).

The vulnerability is rooted in a race condition (CWE-362, CWE-367) combined with improper symlink resolution (CWE-59) in src/filelock/_soft.py (lines 17–27). Within the _acquire() method, a permission check (raise_on_not_writable_file()) is performed before the lock file is created via os.open(); during this narrow race window, a local attacker with symlink creation privileges can place a symlink at the expected lock file path (e.g., ln -s /tmp/important.txt /tmp/app.lock). When os.open() subsequently executes without the O_NOFOLLOW flag, it follows the symlink, causing the lock to operate on an unintended target file or fail entirely. The fix adds the O_NOFOLLOW flag conditionally to os.open(), preventing symlink following on platforms that support it (most modern Unix/Linux systems); platforms lacking O_NOFOLLOW (e.g., GraalPy) retain a documented residual risk (GitHub Advisory, Patch Commit).

Successful exploitation can cause silent lock acquisition failures, allowing multiple processes to simultaneously believe they hold an exclusive lock and leading to resource serialization failures. An attacker can also redirect lock operations to an attacker-controlled file, resulting in low-integrity impact on unintended files. The primary availability impact is denial of service — the attacker can persistently prevent lock file creation by maintaining a symlink at the lock path. There is no confidentiality impact. Applications using filelock.SoftFileLock directly, or those falling back to it on systems without fcntl support, are at risk (GitHub Advisory).

No public proof-of-concept exploit code is known, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.013% (0th percentile), reflecting a very low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires local filesystem access, symlink creation privileges (standard for unprivileged Unix users), and precise timing to win the race window, making opportunistic exploitation difficult.

1. Identify target application: Confirm the target application uses filelock.SoftFileLock (or a FileLock fallback on a system without fcntl) with a known or predictable lock file path (e.g., /tmp/app.lock).
2. Gain local access: Obtain a local unprivileged account on the target system with read access to the lock file directory and standard symlink creation permissions.
3. Monitor lock acquisition timing: Use filesystem event monitoring tools (e.g., inotifywait on Linux) to detect when the target application begins a lock acquisition cycle — specifically, when raise_on_not_writable_file() completes its permission check.
4. Create the symlink during the race window: Immediately after the permission check and before os.open() executes, run ln -s /tmp/important.txt /tmp/app.lock to place a symlink at the lock file path pointing to an attacker-chosen target.
5. Trigger the impact: If the symlink is in place when os.open() runs (without O_NOFOLLOW), the lock either operates on the unintended target file (integrity impact) or raises an OSError, causing the lock acquisition to fail (denial of service). Repeat to maintain persistent disruption (GitHub Advisory).

• File System: Unexpected symbolic links present at known lock file paths (e.g., /tmp/*.lock pointing to unrelated files); lock files owned by a different user than the application service account.
• Logs: Application-level errors indicating repeated lock acquisition failures or OSError/EEXIST exceptions originating from filelock/_soft.py; unusual inotify or filesystem audit events on lock file directories.
• Process: Unexpected ln or symlink-creation commands executed by low-privileged local users in directories containing application lock files; multiple application processes simultaneously accessing a resource that should be exclusively locked.

Upgrade filelock to version 3.20.3 or later, which adds the O_NOFOLLOW flag to os.open() in SoftFileLock._acquire() to prevent symlink following on supported platforms (GitHub Advisory, Patch Commit). IBM has released product-specific fixes for affected offerings including Watson Discovery, Watson Speech Services, Maximo Application Suite, Cloud Pak for Business Automation, Instana, Guardium, and watsonx Orchestrate (IBM Watson Discovery, IBM Watson Speech). For deployments that cannot upgrade immediately: restrict lock file directory permissions (chmod 700 /path/to/lock/directory) to prevent untrusted users from creating symlinks; switch to UnixFileLock or WindowsFileLock instead of SoftFileLock in security-sensitive contexts; and isolate untrusted processes from lock file paths.

The vulnerability was reported by George Tsigourakos (@tsigouris007) and patched by maintainer gaborbernat on January 9, 2026, with the advisory published the same day (GitHub Advisory). IBM issued multiple security bulletins across its product portfolio acknowledging the impact and providing remediation guidance (IBM Watson Discovery). Microsoft also acknowledged the vulnerability in Azure Linux 3 via the MSRC advisory portal (Microsoft MSRC). Coverage has appeared in Linux security news outlets and scanner vendors (Tenable Nessus, Qualys) have added detection plugins.