{"items":[{"id":"NVI-00009073","kind":"vulnerability","title":"filelock: StrictSoftFileLock follows a symbolic link swapped in at .filelock and creates claim files in a directory another local user chooses","revision":1,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected."],"lifecycle":"active","identifiers":["GHSA-m462-7rxw-wvpg","CVE-2026-112938"],"plain_summary":"GitHub lists this reviewed advisory for filelock. Published version ranges and source prerequisites are shown below; this is not an inspection of a visitor’s application.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.","source_ids":["sr-a044f05c483dc53996f9160b28632ef4"],"action_type":"investigate","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null}],"schema_version":"1.1.0","source_metrics":[{"kind":"CVSS","as_of":"2026-10-28T21:08:25.000Z","value":"5.8 medium","meaning":"GitHub source severity; exploitability and local consequence require separate evidence.","source_id":"sr-a044f05c483dc53996f9160b28632ef4"}],"why_it_matters":"Published affected context helps an owner decide what evidence to gather. This report has not examined your application.","related_sources":[{"id":"sr-a044f05c483dc53996f9160b28632ef4","url":"https://github.com/advisories/GHSA-m462-7rxw-wvpg","basis":"vendor_advisory","notes":"GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.","title":"GHSA-m462-7rxw-wvpg","publisher":"GitHub Advisory Database","observed_at":"2026-10-31T21:56:08.420Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-a044f05c483dc53996f9160b28632ef4"],"technology":"filelock","known_exclusions":[],"conditions_summary":"`StrictSoftFileLock` and `AsyncStrictSoftFileLock` check `.filelock` (the coordination directory that holds the lock's state) with one `lstat` call on its name. `lstat` reports what a name is without following a symbolic link (a file that redirects to another path). After that check, the code reaches `.filelock/claims` by pathname for every later operation (`mkdir`, scan, publish, link, unlink). `_open_directory` passes `O_NOFOLLOW` (a flag that makes an open fail when the final name is a symbolic link), but the flag covers only the final `claims` component. The kernel follows a symbolic link in any earlier component.\n\nAnother local user (the other user below) who can rename `.filelock` exchanges it for a symbolic link after the check. In a shared directory without the sticky bit (a directory flag that lets only a file's owner rename or remove it), any user with write access can do this. Where the shared directory is sticky, such as `/tmp`, only the user who created `.filelock` before the user running the lock (the lock user below) first used it can. The lock user's process (root's, if root takes the lock) then creates a `claims` directory and claim files (t","public_affected_ranges":[">= 3.30.0, <= 4.2.0"]}],"null_published_at":"2026-10-31T22:13:31.275Z","source_updated_at":"2026-10-28T21:08:25.000Z","source_disclosed_at":"2026-10-28T21:08:23.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"First indexed by Null; source disclosure date is shown separately.","null_first_observed_at":"2026-10-31T21:56:08.420Z"}],"next_cursor":null,"snapshot_revision":"42594"}