KEVWire

Security intelligence, with context.

Response snapshot Oct 29, 2026, 02:31 UTC

Back to the wire
Permalink
VulnerabilityCVE-2026-112908

filelock: StrictSoftFileLock creates its claim directories without the lock mode, so another local user with a write bit on them can end a live hold

StrictSoftFileLock and AsyncStrictSoftFileLock apply the caller's mode to the sentinel (the lock file at ) and to both claim files (the files whose presence says a process wants or holds the lock). They create the two directories that hold the claims, .filelock and .

At a glance

Exploited
Not known
Severity
5.3 Medium (CVSS 3.1)
Chance of exploitation
Not estimated
Sources
1 source

What to do

GitHub lists first patched versions: filelock: 4.2.1. Confirm the affected range and upgrade guidance in the exact advisory.

Read GitHub-reviewed advisory GHSA-6627-m3xw-93mp (opens a new tab)

What happened

StrictSoftFileLock and AsyncStrictSoftFileLock apply the caller's mode to the sentinel (the lock file at ) and to both claim files (the files whose presence says a process wants or holds the lock). They create the two directories that hold the claims, .filelock and .filelock/claims, with a bare mkdir().

That gives 0o777 filtered through the umask (a per-process mask that removes permission bits from new files and directories) or, under a parent with a default ACL (an access control list on a directory that sets the permissions of entries created inside it), through that ACL.

A hold consists of two claim names in that directory, which has no sticky bit (a directory flag that lets only a file's owner remove it). When the environment leaves another local user (the other user below) a write bit on the directory, that user can unlink the holder's 0600 claims.

Three settings do this: umask 000 in a sticky directory such as /tmp, umask 002 with the other user in the directory's group, or a default ACL on the lock's parent that grants the group write (the kernel then ignores the umask). After the unlink, the next contender of the holder's account finds the directory empty and enters. The first holder keeps reporting is_locked == True and later releases with no error.

Continue reading

Affected versions: filelock >= 3.30.0 and .claim makes the next acquire() raise SoftFileLockProtocolError` ("malformed claim record") until someone removes it. Classification from the review: security, conditional on a lax umask or a permissive default ACL. The scanner rated it high (CWE-732).

Scope and preconditions

- The holder passes a restrictive mode such as 0o600. Without one, the umask decides the permissions by documented design (the "File permissions and mode" section of docs/concepts.rst defines mode only for the lock file). Umask 000 with the default mode gives the same two-holder result but is outside this finding. - The holder's environment leaves the other user a write bit on new directories.

The scanner measured three ways, with mode=0o600 and the other user a member of group team:

| lock's parent directory | holder's umask | .filelock and claims/ | who can unlink the claims | |---|---|---|---| | 1777, like /tmp | 000 | 0777 | any other local user | | root:team, 3775 (setgid, so new entries inherit the group, and sticky) | 002 | 2775 | any member of team | | root:team, 1770, default ACL group:team:rwx (setfacl -d -m g:team:rwx) | 077 | 0770 | any member of team | | root:team, 3775, no ACL | 022 | 2755 | no one; the second process times out |

The default-ACL row is the strongest. A holder with a private umask and mode=0o600 still gets group-writable claim directories. The lock file in that row is 0600, because its mode reaches os.open and masks the inherited ACL. - A contender that may enter asks for the lock: another process of the holder's account, or root. Nothing needs planting beforehand.

The holder creates and owns the whole tree, so the existing-directory branch of _ensure_protocol_directory (the subject of GHSA-9c4x-gm8v-wgc4) plays no part. - Directories that an affected release already created keep their mode. A 0777 .filelock from an earlier run stays writable by other users after an upgrade, because filelock does not remove these directories. Upgraders should chmod or remove existing .

filelock trees (see Workarounds). - The other lock classes do not have this gap in the same setting. With umask 000 and mode=0o600, FileLock and SoftFileLock create one 0600 file and nothing else, and SoftReadWriteLock creates its directories 0700 under any umask. Platform: POSIX permission semantics; demonstrated on Linux.

filelock's checks against another local user hold only when no other user can replace the lock's directory or any of its ancestors. That is the case when each ancestor belongs to the lock's user or root and is either not writable by others or sticky. A user who can rename entries in a non-sticky directory above the lock controls every name below it. No file-based lock can defend against that.

Affected code

At the scanned commit b831496, the bare mkdir() sits in [_ensure_protocol_directory](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_strict.py#L996-L998). [StrictSoftFileLock._acquire](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_strict.py#L127-L133) calls it for both levels without a mode. It then passes self.

_open_mode() to the sentinel and, through [_attempt_doorway](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_strict.py#L179-L181), to both claim files. The doorway (the acquire step that scans existing claims and publishes the caller's own) proceeds when the claim scan is empty. [_unlink_owner_path_result](https://github.

com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_strict.py#L896-L900) counts a missing claim name as removed on release.

Introduced

The bare mkdir() arrived with the claim directories in 650c17c79c54 ("feat(strict): replace shared markers with owner claims", #659, 2026-07-14), first released in 3.30.0. We checked this against the git tags. Every release since 3.30.0 has it.

Mechanism

A process with umask 000 that takes StrictSoftFileLock("/tmp/ /x.lock", mode=0o600) leaves this on disk while it holds the lock, every entry owned by the holder:

0600 x.lock
0777 x.lock.filelock
0777 x.lock.filelock/claims
0600 x.lock.filelock/claims/held-v1- .claim
0600 x.lock.filelock/claims/intent-v1- .claim

Removing a name needs write permission on the directory, and these directories are not sticky. Another local user who cannot read either claim can therefore unlink both. Renaming claims/ away inside the 0777 .filelock has the same eff

Affected package ranges reported by GitHub: filelock: >= 3.30.0, <= 4.2.0

Scores and how they were measured

CVSS base severity

5.3

Version 3.1As of

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L

Measurement source (opens a new tab)

How bad it is if exploited. Not a prediction of exploitation or proof you are exposed.

EPSS probability

Not available

A model's estimate of exploitation in the next 30 days, not certainty or your own risk.

Related technology

Sources

  1. Primary source

    GitHub-reviewed advisory GHSA-6627-m3xw-93mp (opens a new tab)

    The public advisory supplies the description, affected package/version ranges, and any listed CVSS metric. GitHub review is not local review.

    Published Checked

  2. Primary source

    GitHub public advisory API page (opens a new tab)

    The API page supplied GHSA-6627-m3xw-93mp, its actual identifiers, source dates, and structured metrics.

    Published Date not suppliedChecked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, October 28). filelock: StrictSoftFileLock creates its claim directories without the lock mode, so another local user with a write bit on them can end a live hold (CVE-2026-112908). https://kevwire.com/record/CVE-2026-112908

MLA

"filelock: StrictSoftFileLock creates its claim directories without the lock mode, so another local user with a write bit on them can end a live hold (CVE-2026-112908)." KEVWire, 28 Oct. 2026, kevwire.com/record/CVE-2026-112908.

Chicago

KEVWire. "filelock: StrictSoftFileLock creates its claim directories without the lock mode, so another local user with a write bit on them can end a live hold (CVE-2026-112908)." Last modified October 28, 2026. https://kevwire.com/record/CVE-2026-112908.

Evidence summary (plain text)

filelock: StrictSoftFileLock creates its claim directories without the lock mode, so another local user with a write bit on them can end a live hold (Oct 28, 2026).
StrictSoftFileLock and AsyncStrictSoftFileLock apply the caller's mode to the sentinel (the lock file at  ) and to both claim files (the files whose presence says a process wants or holds the lock). They create the two directories that hold the claims,  .filelock and  .filelock/claims, with a bare mkdir(). That gives 0o777 filtered through the umask (a per-process mask that removes permission bits from new files and directories) or, under a parent with a default ACL (an access control list on a directory that sets the permissions of entries created inside it), through that ACL.
CVSS 5.3 (version 3.1; evidence as of Oct 28, 2026; https://github.com/advisories/GHSA-6627-m3xw-93mp).
Sources:
GitHub-reviewed advisory GHSA-6627-m3xw-93mp: https://github.com/advisories/GHSA-6627-m3xw-93mp
GitHub public advisory API page: https://api.github.com/advisories?type=reviewed&per_page=100&sort=updated&direction=desc
Record ID: CVE-2026-112908.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Oct 29, 2026, 02:00 UTC. Ingestion is not an independent editorial investigation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are coming as part of KEVWire Premium: join the waitlist. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail