CVE-2026-112908: 
Python Analyse et atténuation de la vulnérabilité

CVE-2026-112908 is an incorrect permission assignment vulnerability in the Python filelock library affecting the StrictSoftFileLock and AsyncStrictSoftFileLock classes. The flaw causes claim directories (.filelock and .filelock/claims) to be created without the caller's specified mode, leaving them world-writable under certain umask or ACL configurations, which allows another local user to unlink the holder's claim files and break a live lock hold. Affected versions are filelock >= 3.30.0 and <= 4.2.0 (pip package). The vulnerability was reported by Anthropic's OSS Scanner on October 15, 2026, and a fix was published on October 17, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Security Advisory).

The root cause is CWE-732 (Incorrect Permission Assignment for Critical Resource): StrictSoftFileLock._acquire calls a bare mkdir() without a mode argument when creating the .filelock and .filelock/claims directories, resulting in permissions of 0o777 filtered only by the process umask or a parent directory's default ACL. While the sentinel lock file and claim files themselves are created with the caller's restrictive mode (e.g., 0o600), the directories holding those claims lack the sticky bit and may be world-writable. Because removing a file requires write permission on its directory (not the file itself), a local attacker with write access to the claims directory can unlink the holder's 0600 claim files. Three conditions trigger this: umask 000 in a sticky directory like /tmp, umask 002 with the attacker in the directory's group, or a default ACL on the lock's parent granting group write. After the claims are removed, the next contender finds the directory empty and acquires the lock concurrently with the original holder, which silently reports is_locked == True and releases with exit status 0. The vulnerable code was introduced in commit 650c17c (PR #659, 2026-07-14) and is present in every release from 3.30.0 through 4.2.0 (GitHub Advisory, Fix PR #839).

Successful exploitation breaks the mutual exclusion guarantee of StrictSoftFileLock, allowing two processes to simultaneously hold the same lock and concurrently write to the resource the lock protects — with neither process receiving any error or signal. The integrity impact is high because concurrent writes to shared data can result in corruption, race conditions, or inconsistent state in any application relying on StrictSoftFileLock for critical section protection. Additionally, the attacker can plant a malformed claim file (e.g., held-v1-<32 zeros>.claim) to cause a denial-of-service condition where subsequent acquire() calls raise SoftFileLockProtocolError until the file is manually removed. Confidentiality is not impacted, as the 0600 claim files remain unreadable by the attacker (Security Advisory).

No public exploit kit or weaponized exploit is known, but a detailed proof-of-concept reproducer script was included in the official security advisory, demonstrating the attack with two local accounts (victim uid 1000, attacker uid 1001) on Linux 6.1 with CPython 3.14.8. The vulnerability requires a local account on the same host, a lax umask (000 or 002) or a permissive default ACL on the lock's parent directory, and a contender process of the holder's account to request the lock after the claims are removed — making it high complexity. There is no evidence of in-the-wild exploitation, no CISA KEV catalog listing, and no EPSS score data available at this time (GitHub Advisory, Security Advisory).

1. Identify a target: Confirm the target host runs a Python application using filelock >= 3.30.0, <= 4.2.0 with StrictSoftFileLock or AsyncStrictSoftFileLock, and that the lock is placed in a directory where the attacker has write access (e.g., /tmp with umask 000, or a group-shared directory with umask 002).
2. Verify directory permissions: While the victim process holds the lock, inspect the .filelock and .filelock/claims directories (e.g., ls -la /tmp/<lockname>.filelock/) to confirm they are 0777 (world-writable) and lack the sticky bit.
3. Unlink the claim files: As the attacker account, list and remove the holder's claim files from the claims directory:

   for f in /tmp/<lockname>.filelock/claims/*; do rm "$f"; done

   The 0600 claim files can be unlinked because the directory is world-writable and not sticky.
4. Trigger a second acquisition: Wait for or trigger another process of the victim's account to call acquire() on the same lock path. Since the claims directory is now empty, the contender's doorway scan finds no claims and publishes its own, entering the critical section alongside the original holder.
5. Achieve concurrent access: Both processes now hold the lock simultaneously. The attacker can also plant a malformed claim file (held-v1-<32 zeros>.claim) to cause a persistent denial-of-service on subsequent acquire() calls (GitHub Advisory, Security Advisory).

• File System: Presence of .filelock and .filelock/claims directories with permissions 0777 (or 0775/0770 under group umask) and no sticky bit set, owned by the lock holder but writable by other users or groups.
• File System: Unexpected absence of held-v1-*.claim and intent-v1-*.claim files inside .filelock/claims/ while the application reports is_locked == True.
• File System: Presence of a malformed claim file named held-v1-<32 zeros>.claim (all-zero UUID) in the claims directory, which is a sign of a denial-of-service attempt.
• Logs: Application logs showing SoftFileLockProtocolError with "malformed claim record" errors on acquire() calls, indicating a planted malformed claim.
• Logs: Application logs or audit logs (auditd) showing unlink system calls on *.claim files by a user account different from the lock owner.
• Process: Two or more processes of the same account simultaneously executing code that should be protected by a StrictSoftFileLock critical section, observable via process monitoring or application-level logging of concurrent operations.

Upgrade filelock to version 4.2.1, which fixes the issue by creating .filelock and .filelock/claims directories with the lock's mode plus search bits (e.g., mode=0o600 yields 0o700 directories) and sets the sticky bit on both, ensuring only the claim publisher can remove its own claims (filelock 4.2.1 Release, Fix PR #839). If immediate upgrade is not possible, apply these workarounds: (1) run processes that use strict locks with umask 022 or 077; (2) avoid placing a default ACL granting group write on the lock's parent directory; (3) keep strict locks in directories that other users cannot write to. For existing .filelock trees already created with wide permissions, tighten them manually while no process holds the lock: find -maxdepth 1 -type d -name '*.filelock' -exec chmod -R go-w {} + (Security Advisory).

The vulnerability was discovered and reported by Anthropic's automated OSS Scanner (finding ANT-2026-AD6SUOON) on October 15, 2026, and the maintainer (gaborbernat) opened a fix PR within approximately two hours of receiving the report. The advisory was initially drafted as part of GHSA-9c4x-gm8v-wgc4 and then split into its own advisory. No significant broader community or social media discussion has been identified beyond the GitHub advisory and associated pull request (Security Advisory, Fix PR #839).