OAuthlib contains a vulnerability in its token grant handlers where an authenticated client can supply a different client_id in the token request body, causing authorization checks to be performed under that other client identity. This affects the client_credentials and password grant flows when the application validator uses the client_id argument for authorization. The flaw allows a lower-privilege client to obtain tokens with broader scopes or grant types assigned to another client. The issue arises because OAuthlib does not require the authenticated client's client_id to match the client_id parameter in the request body during grant and scope validation.
A vulnerability in setuptools on Windows allows a crafted wheel's namespace_packages.txt to cause legacy wheel installation to create an __init__.py file outside the intended installation directory. This occurs because an absolute Windows path in namespace_packages.txt is interpreted as an absolute path, bypassing intended directory restrictions. The created __init__.py file contains fixed content and is created with the permissions of the installing process. The issue affects setuptools versions from 1.29.0 up to but not including 1.56.0_1 and is fixed in version 1.56.0_1.
A vulnerability in dnspython's dns.name.from_wire_parser() function can cause excessive CPU usage when processing maliciously crafted DNS messages. This can degrade or deny service to applications handling untrusted DNS wire format messages. The issue is fixed in dnspython version 1.56.0. No known workarounds exist.
CVE-2026-112941 is a local integrity vulnerability in filelock's SoftReadWriteLock and AsyncSoftReadWriteLock components affecting versions >=1.55.0_1 and <1.56.0_1. 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 acquisition, causing the lock user process to write lock records through the swapped symlinked directories. This leads to unintended file modifications in directories writable by the lock user, such as breaking a git repository's HEAD file. The vulnerability has low severity with no confidentiality or availability impact and is fixed in version 1.56.0_1.
The filelock ReadWriteLock and AsyncReadWriteLock use SQLite databases for locking, but on Linux and other POSIX systems, SQLite reopens the lock database by name, following symlinks and acting on side files like -journal, -wal, and -shm. This behavior allows a local unprivileged user who can create or rename files in the directory holding the lock database (if it is world- or group-writable without the sticky bit) to manipulate the lock user's files. The attacker can cause arbitrary writes, file creation or deletion, and denial of lock acquisition, all with the lock user's privileges. The vulnerability affects filelock versions 3.20.4 through 4.2.0, with the /proc/self/fd redirect introduced in 4.0.9 and side-file variants since 3.20.4. The CVSS 3.1 score is 7.1 (High). A fix is available in version 1.56.0_1.
A vulnerability in the filelock library versions 3.22.0 through 4.2.0 allows a local user with write access to a lock marker file (but not removal rights) to forge the process ID in the marker. This causes another process running as the lock owner or root to mistakenly consider the lock stale, remove the live marker, and acquire the lock concurrently, leading to two processes running the critical section simultaneously without error. The issue arises when the marker file is created with group or other write permissions under certain umask settings or explicit modes. The vulnerability has a CVSS score of 4.7 (Medium) and impacts integrity but not confidentiality or availability.
A vulnerability in filelock versions 3.30.0 through 4.2.0 allows a local user with write access to a shared directory to swap a symbolic link at the <path>.filelock directory between a check and subsequent operations. This can cause the lock user's process to create claim files in an attacker-chosen directory, potentially disrupting other locks and causing denial of service until manually resolved.
The filelock library versions 4.1.0 through 4.2.0 contain a vulnerability in the ReadWriteLock and AsyncReadWriteLock mechanisms where private .filelock-* directories are deleted recursively without verifying the directory's identity. This can be exploited by a local user who can rename directories in the shared parent directory (without the sticky bit) to cause the lock user's process to delete arbitrary directories with the lock user's permissions. The issue affects macOS since version 4.1.1 and POSIX environments without a usable /proc/self/fd, such as chroots or containers without /proc mounted. The vulnerability has a CVSS 3.1 score of 6.1 (Medium) and results in integrity and partial availability loss but no confidentiality impact.
CVE-2026-112936 affects the ReadWriteLock and AsyncReadWriteLock components of ggshield versions 1.52.1 through 1.55.x. These components resolve lock file paths following symlinks and pass them to SQLite without preventing symlink traversal. A local attacker with write access to the lock directory can exploit this to cause the victim process to create or lock files at attacker-controlled paths, potentially breaking mutual exclusion and corrupting protected resources. The issue is fixed in ggshield version 1.56.0.
A vulnerability in filelock versions 3.22.0 through 4.2.0 allows a local unprivileged user to cause two processes of the lock owner to hold the same soft file lock simultaneously. This occurs due to a race condition in the stale-lock break mechanism that relies on inode numbers and modification times, which can be manipulated on filesystems like ext4 and xfs that reuse inode numbers immediately. The flaw permits integrity violations where two holders write concurrently without detection, but does not impact confidentiality or availability.
The SoftReadWriteLock mechanism in filelock versions 4.0.0 through 4.2.0 refreshes its holder record by reopening and writing to a file without verifying the file type beyond symbolic links. This allows a local user who owns the lock's .rw directory tree to rename a FIFO (named pipe) or a hard link over the holder record file, causing the lock user's write operation to hang or overwrite private files. The FIFO variant causes the lock user's heartbeat thread to hang indefinitely, allowing multiple processes to believe they hold the lock simultaneously. The hard link variant can overwrite the first ~135 bytes of a private file if the kernel permits hard links to files not owned by the user. The vulnerability requires local access and ownership of the lock directory tree and is rated medium severity with a CVSS score of 6.1. A fix is available in filelock version 1.56.0_1.
A vulnerability in filelock's ReadWriteLock and AsyncReadWriteLock allows a local user who can place or overwrite the lock database file to cause every acquire operation to stall or hang indefinitely, ignoring timeouts and blocking flags. This happens because the lock code runs SQLite commands that load the entire schema of the database file at the lock path, and a crafted database file can cause the acquire to consume excessive memory and CPU or spin indefinitely. The impact is denial of service (availability) only, with no confidentiality or integrity compromise. Affected versions are filelock 3.20.4 through 4.2.0. The vulnerability requires the attacker to have write access to the lock database file or its directory, typically in a non-sticky shared directory or a writable database file owned by the lock user. A fix is available in filelock version 4.2.1 (1.56.0_1 in the related product).
A vulnerability in filelock versions 4.1.0 through 4.2.0 allows a local unprivileged user to exploit a race condition involving symbolic links in a shared lock directory without the sticky bit. This can lead to the creation of a hard link to another user's file, exposing metadata and enabling the attacker to manipulate the file's name. The issue arises due to the os.link call following symbolic links on CPython 3.12+ on Linux and macOS, combined with directory permissions that allow the attacker to replace lock files with symbolic links. The vulnerability has medium severity with a CVSS score of 5.3.
A symlink swap vulnerability in filelock's SoftFileLock writability check allows a local user 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 requires the attacker to have write access to the lock directory and the ability to observe the lock user's acquire outcome. Linux kernel setting fs.protected_symlinks mitigates this in sticky world-writable directories like /tmp, but not in all shared directory configurations. The issue is rated low severity with a CVSS score of 2.5.
The vulnerability affects the filelock library versions 3.30.0 through 4.2.0, specifically the StrictSoftFileLock, AsyncStrictSoftFileLock, SoftReadWriteLock, and AsyncSoftReadWriteLock classes. These classes adopt a protocol directory created by another local user without verifying ownership, allowing that user to interfere with the lock state. This can lead to multiple processes entering the same critical section simultaneously, integrity compromise by allowing unauthorized writes, and denial of service by causing lock operations to spin indefinitely or consume excessive memory. The issue requires the attacker to create the protocol directory before the legitimate user acquires the lock, typically in shared sticky directories like /tmp. The vulnerability has a CVSS 3.1 score of 6.3 (medium severity). A fix is available in version 1.56.0_1 of the affected product ggshield.
UnixFileLock, used by FileLock and AsyncFileLock on Unix systems, truncates and changes permissions of any regular file that another local user renames or hard-links onto the lock path before the lock is acquired. This can lead to unintended file truncation and permission changes, allowing the other user to read and modify the file contents thereafter. The vulnerability affects all filelock releases up to and including 4.2.0, with the chmod behavior present since version 3.10.2. Exploitation requires local access and the ability to rename or hard-link files in directories without sticky bit protections or with specific kernel settings disabled. The issue is rated medium severity with a CVSS score of 6.1 and has been fixed in filelock version 1.56.0_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 umask or default ACLs. This can allow another local user with write access to the claim 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 lax umask or permissive ACLs. The CVSS score is 5.3 (medium severity). A fix is available in version 1.56.0_1 of the affected product ggshield.
A vulnerability in filelock versions 4.1.0 through 4.2.0 allows a local user to evict a lock file held by another user by exploiting inode reuse and coarse clock timestamp manipulation on ext4 or overlayfs filesystems. This can cause two processes of the lock owner to enter a critical section simultaneously, violating integrity without affecting confidentiality or availability.
CVE-2025-50181 is a vulnerability in the osc-cli product related to urllib3's handling of redirects when retries are disabled on PoolManager instantiation. The retries parameter intended to disable redirects at the PoolManager level is ignored, causing redirects to remain enabled. This can leave applications vulnerable to SSRF or open redirect attacks if they rely on disabling redirects at this level. The vulnerability affects specific versions of osc-cli and related packages. A patch is available to fix this issue.
A Unicode normalization mismatch in setuptools' handling of MANIFEST.in exclusions can cause files intended to be excluded from source distributions to be included instead. This occurs on macOS APFS/HFS+ filesystems where filenames are stored in NFD form but MANIFEST.in patterns are typically written in NFC form, causing byte-level matching to fail. As a result, sensitive files with non-ASCII names may be unintentionally published to PyPI. The issue affects setuptools versions before 1.52.2_2 and has been assigned CVE-2026-59890 with a medium severity rating.