The filelock library's ReadWriteLock and AsyncReadWriteLock use an SQLite-backed lock database that runs PRAGMA journal_mode=MEMORY on every acquire, causing SQLite to load the entire schema of the lock file. A local unprivileged user who can create or overwrite the lock database file can craft a malicious database that causes every acquire_read or acquire_write call to stall indefinitely, ignoring timeout and blocking flags. This results in a denial of service affecting availability only, with no confidentiality or integrity impact. The issue affects filelock versions 3.20.4 through 4.2.0. A fix is available in version 4.7.0_1.
Certain file locking classes in the filelock library (StrictSoftFileLock, AsyncStrictSoftFileLock, SoftReadWriteLock, AsyncSoftReadWriteLock) adopt ownership of a protocol directory if it already exists, without verifying ownership. This allows a local unprivileged user to pre-create the directory in a shared sticky directory (e.g., /tmp), causing the lock user's process to unknowingly share the lock state. This can lead to multiple processes entering the same critical section simultaneously, integrity violations by allowing two writers, and denial of service by causing lock acquisition to spin indefinitely or consume excessive memory. The vulnerability affects filelock versions 3.30.0 through 4.2.0 and is fixed in version 4.7.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 proper restrictive permissions. This allows another local user with write access to the directory to unlink claim files, causing multiple holders to believe they hold the lock simultaneously. This results in a high integrity impact due to concurrent writes without coordination. The vulnerability requires a specific environment with a permissive umask or default ACL allowing write access to the lock claim directories. The issue is fixed in version 4.7.0_1.
A vulnerability in virtualenv allows attacker-controlled prompt text to be interpreted as executable syntax in the bash activation prompt under older bash compatibility modes (4.2 and lower) and certain POSIX shell scenarios. This occurs when an attacker influences the prompt value passed to virtualenv, and a user activates the environment with the crafted prompt. The issue affects the POSIX activation scripts and certain shells like dash when PS1 is exported, leading to command execution upon prompt display. The vulnerability was introduced in virtualenv 20.0.0b1 and 21.14.7 and fixed in versions 2022.8.7_1 and 2026.10.20.
The filelock ReadWriteLock and AsyncReadWriteLock components 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 attacker with write access to the directory containing the lock database (if it is world- or group-writable without the sticky bit) to plant symlinks or side files that cause the lock user to overwrite or unlink files with their privileges, or cause lock acquisition failures. This vulnerability affects filelock versions 3.20.4 through 4.2.0 and is fixed in version 2026.10.20. The CVSS 3.1 score is 7.1 (High), reflecting local low-privilege attack with high integrity and availability impact but no confidentiality loss.
A vulnerability in filelock versions 3.22.0 through 4.2.0 allows a local user with write access to a lock marker file (but without permission to remove it) to forge the process ID in the marker. This causes the lock to be incorrectly considered stale, enabling another process running as the lock owner or root to remove the live marker and acquire the lock simultaneously. This results in two processes entering the critical section concurrently without error, potentially causing integrity issues. The vulnerability requires specific conditions related to file permissions and directory sticky bits and has a CVSS score of 4.7 (Medium).
Authlib versions up to 1.7.2 accept an empty HMAC key for JWS/JWT HS256/HS384/HS512 signature verification, allowing attackers to forge tokens that pass signature checks. This occurs because empty keys produce deterministic digests that anyone can reproduce, enabling token forgery and authentication bypass in OAuth 2.0 and OIDC implementations using Authlib. The vulnerability is confirmed in the v1.7.2 release and remains in the current main branch. A fix is available in version 0.23.1_2.
Authlib versions from 0.13 through 1.7.2 contain a vulnerability in the is_secure_transport() function where the loopback exemption for HTTP URLs can be bypassed by including a userinfo component in the URL. This causes the function to incorrectly treat certain cleartext HTTP URLs with non-loopback hosts as secure, violating OAuth 2.0 / OIDC TLS requirements. The flaw affects validation of redirect URIs and authorization server metadata endpoints, potentially allowing an attacker to register or use insecure URLs that bypass TLS enforcement. The severity is low and a fix is available in version 0.23.1_1.
GitPython versions >=1.3.0 have three wrapper methods that omit critical unsafe protocol and option checks, leading to potential command injection and remote code execution (RCE). The ls_remote method forwards URLs without checking for unsafe protocols, allowing RCE if the victim's git transport policy permits the 'ext' transport. The merge_base and IndexFile.move methods forward caller arguments without checking for unsafe options, creating latent injection surfaces. These issues are verified on the main branch as of 2026-09-21 and remain unpatched in the latest release 3.1.62. The vulnerability is rated high severity with a CVSS score of 7.5.