LangGraph API versions from 0.1.2 up to but not including 0.15.0 that use JavaScript or TypeScript custom authentication with namespace rewriting for Store authorization may allow authenticated users to access or modify data outside their authorized namespace. This vulnerability does not affect Python custom authentication or handlers that reject unauthorized namespaces. The issue is fixed in version 0.15.0.
filelock versions 4.1.0 through 4.2.0 contain a vulnerability in SoftReadWriteLock where a local user with write access to the lock's parent directory can replace the lock directory tree with symbolic links after the first lock acquire. This causes the lock user process to write lock records through the symbolic links, potentially corrupting files such as a git repository's HEAD file. The vulnerability requires local access and specific directory conditions but does not expose confidentiality or availability impacts. It has a low CVSS score of 3.3 and is fixed in version 4.2.1.
The filelock library versions 3.30.0 through 4.2.0 have a vulnerability in StrictSoftFileLock and AsyncStrictSoftFileLock where claim directories are created without applying the caller's restrictive mode, resulting in directories with permissions influenced by the process umask or parent directory ACLs. This can allow another local user with write access to these directories to unlink claim files, causing multiple holders to believe they hold the lock simultaneously, leading to integrity issues. The vulnerability requires a local attacker with low privileges and specific environment conditions such as a permissive umask or default ACLs. The issue is fixed in version 4.2.1.
filelock versions 3.30.0 through 4.2.0 have a vulnerability where StrictSoftFileLock and SoftReadWriteLock classes adopt a protocol directory created by another local user if it exists before the lock user's first acquire. This allows the other user to manipulate lock state files, causing integrity and availability issues such as multiple writers entering critical sections simultaneously and denial of service via spinning locks or memory exhaustion. The vulnerability requires local access and the ability to create directories in shared sticky-bit directories like /tmp before the lock user. It has no confidentiality impact but high integrity and availability impact. A fix is available in version 4.2.1.
The filelock library on Windows ignores the 'mode' argument when creating lock files, causing files intended to have restrictive permissions (0o600) to inherit the directory's ACL instead. This allows other local accounts with read or modify access to the directory to read or write the lock files and interfere with the locking mechanism. The issue affects filelock versions 3.10.0 through 4.2.0 on Windows and is confirmed by the maintainers. Unix systems are not affected. A fix is available in version 4.2.1.
filelock versions 3.20.4 through 4.2.0 contain a vulnerability in the ReadWriteLock and AsyncReadWriteLock mechanisms where a crafted SQLite lock database file can cause every acquire operation to stall or hang indefinitely, ignoring timeout and blocking settings. This is due to the lock code running PRAGMA journal_mode=MEMORY on a fresh SQLite connection for each acquire, which loads the entire schema from the file at the lock path. A local attacker who can place or overwrite this file can cause denial of service by making acquires hang or spin at 100% CPU. The impact is availability only; no confidentiality or integrity is affected. The vulnerability is fixed in filelock 4.2.1.
A vulnerability in filelock versions 3.22.0 through 4.2.0 allows a local user with write access to a lock marker file to forge the process ID (PID) recorded in the marker. This causes another process, running as the lock owner or root, to mistakenly consider the lock stale and remove the live marker, resulting in two processes concurrently holding the lock. The issue arises when the marker file is group- or other-writable due to explicit mode settings or permissive umask values in sticky or non-removable directories. The vulnerability has a medium severity with a CVSS score of 4.7 and impacts integrity but not confidentiality or availability. A fix is available in version 4.2.1.
A symlink swap vulnerability in filelock's SoftFileLock writability check allows a local user with directory write access to leak one bit of information about whether a path exists and is writable by the lock user. This occurs due to a time-of-check to time-of-use (TOCTOU) race condition involving os.lstat and os.access calls. The vulnerability affects filelock versions 3.32.6 through 4.2.0 and is mitigated by Linux kernel's protected symlinks feature in common sticky world-writable directories like /tmp. The impact is limited to leaking a single bit of path existence and writability information with high attack complexity and no integrity or availability impact. A fix is available in version 4.2.1.
The filelock library's UnixFileLock backend on Unix systems truncates and changes permissions of any regular file that another local user renames or hard-links onto the lock path. This occurs when the lock user acquires the lock and the file exists at the lock path, leading to unintended truncation and potential permission escalation. The vulnerability affects all filelock versions up to and including 4.2.0 and requires local user access with certain directory permission conditions. The issue is fixed in version 4.2.1.
The filelock library's ReadWriteLock and AsyncReadWriteLock classes follow symlinks when resolving lock file paths, allowing a local attacker with write access to the lock directory to manipulate the lock target. This can cause the victim process to create or write files it should not, break mutual exclusion by allowing multiple write locks simultaneously, or cause denial of service by locking unrelated SQLite databases. The issue affects versions from 3.20.4 up to but not including 4.0.9 and is fixed in version 4.0.9.
A race condition vulnerability in filelock versions 3.30.0 through 4.2.0 allows a local unprivileged user to swap a symbolic link at the <path>.filelock directory after an lstat check but before subsequent operations. This can cause the lock user's process to create claim files in an attacker-chosen directory, potentially disrupting other locks by causing stranded claims that lead to denial of service until manually force-broken. The vulnerability requires write access to the directory containing <path>.filelock and is mitigated by patch 4.2.1.
filelock versions 4.0.0 through 4.2.0 contain a vulnerability in SoftReadWriteLock where the holder record refresh writes through a hard link or hangs on a named pipe (FIFO) placed by another local user who owns the lock's .rw directory. This can cause the lock user's write_lock or read_lock operations to hang indefinitely and the heartbeat thread to stop without notification, allowing multiple processes to believe they hold the lock simultaneously. The issue requires local user access and specific conditions such as permissive hard-link policies or ownership of the lock directory. The vulnerability has medium severity with no confidentiality impact but can cause integrity loss and high availability impact. A fix is available in version 4.2.1.
A vulnerability in the filelock Python library versions 3.22.0 through 4.2.0 allows a local unprivileged user to cause two processes of the same user to simultaneously hold the same soft file lock. This occurs due to a race condition in the stale-lock break mechanism that relies on inode numbers and modification times, which can be exploited on filesystems like ext4 and xfs that reuse inode numbers immediately. The issue requires a sticky shared directory writable by the attacker and at least two contending processes by the lock user. The vulnerability impacts integrity by allowing concurrent holders to write protected data without detection.
LangGraph Python SDK v3 streaming client versions 0.4.0 through 0.4.5 improperly handle unencoded thread_id and assistant_id values in request paths, allowing relative path segments to redirect authenticated GET requests to other paths on the same server. This affects also langgraph versions 1.2.3 through 1.2.13 when used with vulnerable SDK versions. The vulnerability allows an attacker controlling these identifiers to cause the SDK to fetch and return data from arbitrary readable paths on the server, but does not allow modification of data. The issue is fixed in langgraph-sdk 0.4.6 and langgraph 1.2.14.
Rucio contains an authorization bypass vulnerability in its /credentials/signurl REST API endpoint. The endpoint incorrectly uses a client-supplied HTTP header (X-Rucio-Account) to determine authorization instead of the authenticated token's account. This allows any user with a valid token, even low-privilege accounts, to impersonate the root account and obtain presigned URLs for read, write, or delete operations on arbitrary cloud storage objects. This flaw enables unauthorized data access, modification, and deletion across multi-tenant environments.
The trajmetrics package version 0.5.3 on PyPI contains malicious code that scans the entire system to exfiltrate selected file types. When used as instructed in its README, it runs a background process that continuously monitors and exfiltrates files as they change, indicating clear malicious intent as an infostealer.
MLflow tracking servers running without authentication or with basic authentication are vulnerable to an arbitrary file read vulnerability via crafted model versions tagged as prompts with schemeless local paths. This allows remote attackers to read arbitrary files on the server filesystem with the privileges of the MLflow server process. The vulnerability affects MLflow versions 3.10.0 through 3.16.1 and is fixed in version 3.17.0.
MLflow's CrewAI autologging feature in versions >=2.19.0 and <3.17.0 leaks CrewAI LLM provider API keys in trace telemetry. The vulnerability arises because MLflow serializes the CrewAI Agent object's __dict__ including the LLM object, whose string representation contains the API key in plaintext. This sensitive information is unintentionally sent to MLflow's trace backend or any configured OTLP destination without explicit logging by the application. The issue affects MLflow 3.16.0 with CrewAI 1.15.18 and is fixed in MLflow 3.17.0.
MLflow versions from 3.12.0rc0 up to but not including 3.17.0 are vulnerable to unauthenticated remote code execution via a flaw in third-party scorer deserialization. The vulnerability arises because the server imports and instantiates Python classes from request-controlled module paths under allowed package prefixes, which can be exploited by uploading malicious Python modules into writable artifact directories within these allowed packages. This leads to arbitrary code execution with the privileges of the MLflow server process, which by default runs as root in the official image. The issue is critical and has a CVSS score of 9.8. A fix is available in MLflow 3.17.0.
The Model Context Protocol (MCP) Python SDK versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 have a vulnerability in server-side bearer-token authentication. The SDK does not verify that a token's audience matches the intended server, allowing tokens issued for other services by the same authorization server to be accepted. This can lead to unauthorized access. Fixed in versions 1.30.0 and 2.2.0, the fix requires enabling a new setting to validate the token audience explicitly.