{"items":[{"id":"NVI-00009074","kind":"vulnerability","title":"filelock: StrictSoftFileLock and SoftReadWriteLock adopt a protocol directory another user created first, losing mutual exclusion","revision":2,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected.","NVD lastModified does not establish freshness of every associated CPE record."],"lifecycle":"active","identifiers":["GHSA-9c4x-gm8v-wgc4","CVE-2026-112911"],"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-0a11a32b526eef50e16306bb048cfc98"],"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:09:01.000Z","value":"6.3 medium","meaning":"GitHub source severity; exploitability and local consequence require separate evidence.","source_id":"sr-a0a61bf9c0a5fcdbcac43fa9804037de"},{"kind":"CVSS","as_of":"2026-10-28T16:17:02.690Z","value":"6.3 MEDIUM (3.1)","meaning":"security-advisories@github.com severity; no combined Null risk score.","source_id":"sr-0a11a32b526eef50e16306bb048cfc98"}],"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-a0a61bf9c0a5fcdbcac43fa9804037de","url":"https://github.com/advisories/GHSA-9c4x-gm8v-wgc4","basis":"vendor_advisory","notes":"GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.","title":"GHSA-9c4x-gm8v-wgc4","publisher":"GitHub Advisory Database","observed_at":"2026-10-31T21:56:08.420Z"},{"id":"sr-0a11a32b526eef50e16306bb048cfc98","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-112911","basis":"official_catalog","notes":"This product uses data from the NVD API but is not endorsed or certified by the NVD.","title":"CVE-2026-112911","publisher":"NIST National Vulnerability Database","observed_at":"2026-11-03T09:58:44.915Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-a0a61bf9c0a5fcdbcac43fa9804037de"],"technology":"filelock","known_exclusions":[],"conditions_summary":"`StrictSoftFileLock`, `AsyncStrictSoftFileLock`, `SoftReadWriteLock` and `AsyncSoftReadWriteLock` keep their whole ownership state as files in a directory derived from the lock path (`.filelock/claims`, `.rw/{gen,holders}`). When that directory already exists they adopt it after checking only that it is a real directory, not who owns it. Another local user who can create names in the lock's directory can create the tree before the first acquire on that path by the user running the lock (below: the lock user). In `/tmp`, `/var/tmp` or another sticky shared directory any user can do that; the sticky bit is a directory flag that lets only a file's owner remove or rename it. The other user then owns the tree. They can unlink the lock user's claims while the lock user holds the lock, so a second process of the lock user, root included, enters the same critical section and neither process sees an error.\n\nAgainst `SoftReadWriteLock` the same position also admits two writers with `on_compromise` silent. It redirects the lock user's own creates and renames into a directory the other user picks (the scanner replaced a repository's `.git/HEAD` with a filelock record written with t","public_affected_ranges":[">= 3.30.0, <= 4.2.0"]}],"null_published_at":"2026-11-03T10:03:31.368Z","source_updated_at":"2026-10-28T21:09:01.000Z","source_disclosed_at":"2026-10-28T21:08:59.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"Source facts changed; compare the preserved prior revision.","null_first_observed_at":"2026-10-31T21:56:08.420Z"},{"id":"NVI-00009074","kind":"vulnerability","title":"filelock: StrictSoftFileLock and SoftReadWriteLock adopt a protocol directory another user created first, losing mutual exclusion","revision":1,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected."],"lifecycle":"active","identifiers":["GHSA-9c4x-gm8v-wgc4","CVE-2026-112911"],"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-a0a61bf9c0a5fcdbcac43fa9804037de"],"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:09:01.000Z","value":"6.3 medium","meaning":"GitHub source severity; exploitability and local consequence require separate evidence.","source_id":"sr-a0a61bf9c0a5fcdbcac43fa9804037de"}],"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-a0a61bf9c0a5fcdbcac43fa9804037de","url":"https://github.com/advisories/GHSA-9c4x-gm8v-wgc4","basis":"vendor_advisory","notes":"GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.","title":"GHSA-9c4x-gm8v-wgc4","publisher":"GitHub Advisory Database","observed_at":"2026-10-31T21:56:08.420Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-a0a61bf9c0a5fcdbcac43fa9804037de"],"technology":"filelock","known_exclusions":[],"conditions_summary":"`StrictSoftFileLock`, `AsyncStrictSoftFileLock`, `SoftReadWriteLock` and `AsyncSoftReadWriteLock` keep their whole ownership state as files in a directory derived from the lock path (`.filelock/claims`, `.rw/{gen,holders}`). When that directory already exists they adopt it after checking only that it is a real directory, not who owns it. Another local user who can create names in the lock's directory can create the tree before the first acquire on that path by the user running the lock (below: the lock user). In `/tmp`, `/var/tmp` or another sticky shared directory any user can do that; the sticky bit is a directory flag that lets only a file's owner remove or rename it. The other user then owns the tree. They can unlink the lock user's claims while the lock user holds the lock, so a second process of the lock user, root included, enters the same critical section and neither process sees an error.\n\nAgainst `SoftReadWriteLock` the same position also admits two writers with `on_compromise` silent. It redirects the lock user's own creates and renames into a directory the other user picks (the scanner replaced a repository's `.git/HEAD` with a filelock record written with 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:09:01.000Z","source_disclosed_at":"2026-10-28T21:08:59.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"}