pyasn1 versions up to 0.6.4 contain a denial of service vulnerability in the decoding of binary-encoded ASN.1 REAL values with large mantissas. The decoding process is quadratic in the mantissa length, causing excessive CPU consumption when processing attacker-controlled input. This affects BER, CER, and DER decoders using the RealPayloadDecoder. The vulnerability is fixed in pyasn1 version 0.6.5. Applications using vulnerable versions should upgrade or limit input containing REAL values.
CVE-2026-119196 affects pyasn1 versions from 1.4.0 up to but not including 3.67.1_19. The vulnerability causes quadratic CPU consumption when decoding constructed BIT STRING values with many fragments, potentially leading to CPU exhaustion and denial of service. This occurs because the decoder repeatedly shifts and copies the accumulated value for each fragment. The issue affects BER and CER decoders and certain schema-driven DER decoding paths. No confidentiality or integrity impact is reported. A fix is available in version 3.67.1_19.
pyasn1 versions up to 0.6.4 have a quadratic-time denial of service vulnerability in decoding constructed OCTET STRINGs, constructed character strings, and indefinite-length ANY types. This flaw causes excessive CPU consumption when processing many small ASN.1 fragments, potentially leading to CPU exhaustion. The issue affects BER and CER decoding and certain non-conforming DER inputs. No confidentiality or integrity impact is reported. A fix is available in version 3.67.1_19.
CVE-2026-119194 is a vulnerability in the pyasn1 library used by the dvc product that causes quadratic CPU usage when decoding attacker-controlled BER, CER, or DER data without an ASN.1 schema. An attacker can craft inputs with many distinct long tag IDs that cause excessive CPU consumption, potentially leading to denial of service by exhausting CPU resources. The issue affects dvc versions from 1.4.0 up to but not including 3.67.1_19. A fix is available in version 3.67.1_19. No confidentiality or integrity impacts were observed.
OAuthlib contains a vulnerability in its token grant handlers where an authenticated low-privilege client can supply a different client_id in the token request body, causing grant and scope validation to be performed under that other client identity. This affects the client_credentials and resource owner password credentials grant flows. The issue arises because OAuthlib does not require the client_id in the request body to match the authenticated client's client_id before validating grants and scopes. As a result, a low-privilege client can obtain tokens with higher privileges assigned to another client if the application validator authorizes based on the client_id argument passed by OAuthlib.
CVE-2026-112941 is a local integrity vulnerability in filelock's SoftReadWriteLock and AsyncSoftReadWriteLock implementations. 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 symlinked path. This leads to unintended file modifications in directories the lock user can write, such as breaking a git repository's HEAD file. The vulnerability affects filelock versions 4.1.0 through 4.2.0 and is rated low severity with no confidentiality or availability impact.
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 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. This can lead to integrity violations where both processes write to the protected resource simultaneously without error.
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 to create claim files in an attacker-controlled directory, potentially disrupting other locks by causing them to time out until manually force-broken. The issue requires a race condition and specific directory permissions, and impacts availability significantly while confidentiality and integrity impacts are low.
The ReadWriteLock and AsyncReadWriteLock classes in the dvc product resolve lock file paths following symlinks and pass them to SQLite without preventing symlink traversal. This allows a local attacker with write access to the lock directory to cause the victim process to create or lock files at attacker-chosen locations, potentially breaking mutual exclusion and corrupting protected resources. The issue affects dvc versions from 3.67.0 up to but not including 3.67.1_18 and has a CVSS score of 6.1 (medium severity).
filelock versions 3.22.0 through 4.2.0 contain a flaw in the stale-lock break mechanism used by SoftFileLock and related classes. This flaw allows a local attacker with write access to the lock directory (such as /tmp) to cause two processes of the lock owner to simultaneously hold the same lock by exploiting inode reuse and race conditions. This results in a high integrity impact where concurrent holders can write protected data without detection. The vulnerability requires local access and a sticky shared directory on ext4 or xfs filesystems. The CVSS 3.1 score is 4.7 (Medium).
A vulnerability in filelock's SoftReadWriteLock and AsyncSoftReadWriteLock components allows a local user who owns the lock's .rw directory tree to cause the lock holder's refresh operation to hang or overwrite files. This occurs because the holder refresh writes to a file descriptor opened with O_NOFOLLOW, which does not prevent opening hard links or FIFOs (named pipes). On default Linux systems, a malicious local user can rename a FIFO into the holders directory, causing the lock holder's write or read lock operation to hang indefinitely, bypassing timeout and leaving heartbeat threads asleep. Additionally, if the kernel permits hard links to files not owned by the user (e.g., Linux with fs.protected_hardlinks=0), the attacker can cause the lock user to overwrite the first ~135 bytes of one of its own private files. The issue affects filelock versions >=4.0.0 and <=4.2.0 and has a CVSS score of 6.1 (medium severity).
The filelock library's ReadWriteLock and AsyncReadWriteLock use an SQLite-backed lock database that runs PRAGMA journal_mode=MEMORY on each acquire, causing SQLite to load the entire schema of the lock file. A local user able to place or overwrite the lock database file can craft a file that causes every acquire_read or acquire_write call to stall indefinitely or hang, ignoring timeout and blocking settings. This leads to a denial of service by making lock acquisition unavailable. The issue affects filelock versions 3.20.4 through 4.2.0 and requires the attacker to have local write access to the lock database path or directory. The impact is availability only, with no confidentiality or integrity compromise. A fix is available in filelock version 4.2.1 or later.
A symlink swap vulnerability exists in the SoftFileLock implementation used by filelock versions 3.32.6 through 4.2.0. The flaw allows a local user with write access to the lock directory to infer whether a path exists and is writable by the lock user by swapping a symlink target between calls in a time-of-check-to-time-of-use (TOCTOU) window. This leak yields one bit of information per lock acquire attempt. The vulnerability is mitigated on Linux by the fs.protected_symlinks kernel setting in sticky world-writable directories like /tmp, but not in other writable directory configurations. The issue has a low CVSS score of 2.5 due to high attack complexity and limited confidentiality impact. A fix is available in version 3.67.1_18.
The vulnerability affects the StrictSoftFileLock and SoftReadWriteLock classes in filelock versions 3.30.0 through 4.2.0, allowing a local attacker to pre-create the protocol directory used for lock ownership state. This enables the attacker to interfere with lock claims, potentially causing multiple processes to enter the same critical section simultaneously, leading to integrity and availability issues. The flaw requires the attacker to have local user access and to create the directory before the lock user's first acquire on that path, typically in shared sticky directories like /tmp. The vulnerability has no confidentiality impact but can cause high integrity and availability damage, such as allowing concurrent writers or causing lock acquisition to spin indefinitely. A fix is available in version 3.67.1_18.
UnixFileLock, used by FileLock and AsyncFileLock on Unix systems, truncates and can change permissions of any regular file that another local user renames or hard-links onto the lock path. This occurs when the lock user next acquires the lock, potentially 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. Exploitation requires local access and specific directory permissions or kernel settings. The issue is patched in version 3.67.1_18.
A vulnerability in the filelock library's StrictSoftFileLock and AsyncStrictSoftFileLock classes allows a local user to remove lock claim files due to improper directory permissions. The directories holding claim files are created with default permissions filtered by umask or ACLs, potentially allowing other local users with write access to unlink claim files. This can lead to multiple processes incorrectly believing they hold the lock simultaneously, causing integrity issues in protected data. The issue affects filelock versions from 3.30.0 up to and including 4.2.0 and is mitigated by updating to version 3.67.1_18 or later.
GitPython's Submodule.move() API does not properly validate intermediate symbolic links in the destination path, allowing an attacker-controlled symlink to redirect the move operation outside the parent repository worktree. This can cause the submodule checkout to be moved to an attacker-selected external directory, corrupting the parent repository's index and configuration. The vulnerability requires an attacker-controlled Git repository with a symlink submodule path and the application to explicitly call Submodule.move() with a path under that symlink. No code execution or confidentiality impact is demonstrated.
GitPython versions up to 3.1.62 contain a vulnerability in the Head.checkout() method that allows an attacker controlling a cloned repository's default branch name to cause arbitrary file reads. This occurs because the branch name is passed as a positional argument to git checkout without proper sanitization, enabling injection of git options like --pathspec-from-file to read sensitive files such as /etc/passwd. The issue is an incomplete fix of prior advisories and affects all published releases through 3.1.62.
GitPython's Remote.pull() method improperly forwards its positional refspec argument directly to the underlying git pull command without properly filtering unsafe options. This allows an attacker controlling the refspec to inject a --upload-pack option that executes arbitrary commands on the system with the privileges of the calling process. The vulnerability affects scenarios where the remote uses a local-path or SSH transport, as these run the upload-pack program locally. The flaw is fixed in version 3.67.1_18.
GitPython contains vulnerabilities in three wrapper methods that omit critical checks for unsafe protocols and options, allowing potential remote code execution (RCE) and argument injection. The ls_remote method forwards URLs without protocol checks, enabling RCE if the victim's git transport policy permits the 'ext' protocol. The merge_base and IndexFile.move methods forward caller-supplied arguments without guarding against unsafe options, creating latent injection risks. These issues are verified on the main branch post the latest release and affect versions from 1.4.0 up to but excluding 3.67.1_18.