Snyk has a proof-of-concept or detailed explanation of how to exploit this vulnerability.
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsUpgrade filelock to version 4.2.1 or higher.
Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity via owner_is_stale in src/filelock/_soft.py and src/filelock/_identity.py, when a process owner identity comparison is performed between a lock holder whose start token was recorded without a boot ID (high 64 bits equal to zero) and a new process whose token includes a boot ID. Because the original comparison used set membership (process_start_token(pid) in {None, start_token}) rather than a boot-ID-aware equality check, a live lock holder can be incorrectly classified as stale when the reader and the owner run in different Linux time namespaces or when one side cannot read /proc/sys/kernel/random/boot_id. This allows a competing process to prematurely reclaim the lock, corrupting the mutual-exclusion guarantee and enabling unauthorized writes to the protected resource.