CVE-2026-116578 is an open redirect vulnerability in Tornado's RedirectHandler that allows attackers to craft URLs causing redirects to arbitrary hosts via protocol-relative URLs or substitutions affecting the scheme or host. This occurs when user-controlled input is substituted into URL templates in a way that influences the redirect target's scheme or host. The issue is fixed in Tornado 6.6, which rejects such substitutions with a 400 error.
Tornado HTTP servers have a vulnerability in their header parser that causes quadratic CPU usage when processing HTTP headers with obsolete line folding (line continuation). This can lead to significant event loop blocking and degraded service availability. The issue affects all Tornado HTTP servers before version 4.6.4_3. The vulnerability is fixed in Tornado 4.6.4_3 by removing support for obsolete line folding and rejecting header lines beginning with whitespace. The impact is limited to availability; confidentiality and integrity are not affected.
Tornado HTTP servers are vulnerable to event loop blocking and excessive memory use when processing HTTP/1.1 chunked transfer encoding bodies composed of many small chunks. An attacker can send a request body with millions of 1-byte chunks, causing the server to block the event loop for extended periods and consume significantly more memory than the actual body size. This affects all Tornado HTTP servers that read request bodies without prior rejection and also impacts SimpleAsyncHTTPClient when reading responses from malicious servers. The issue is fixed in Tornado 6.6.
The npm package 'dowload_ebok_lolita_by_vladimir_nabokov_oy1gy' contains malicious code that compromises any computer on which it is installed or run. The compromise is severe enough that all secrets and keys stored on the affected machine should be rotated immediately from a different, secure computer. Removal of the package alone does not guarantee elimination of all malicious software introduced by it.
The npm package 'dowload_ebok_el_piso_mil_el_piso_mil_1_by_katharine_mcgee_h1llc' contains malicious code that compromises any computer on which it is installed or run. The compromise is severe enough that all secrets and keys stored on the affected machine should be rotated immediately from a different, trusted device. Removing the package alone may not fully eliminate the malicious presence due to potential persistent control by an attacker.
The npm package 'dowload_ebok_nur_mal_schnell_das_mammut_retten_by_knut_kruger_eva_schoffmann_davidov_ouz6t' contains malicious code that compromises any computer on which it is installed or run. The compromise is severe enough that all secrets and keys stored on the affected system should be considered exposed and require immediate rotation from a different, uncompromised machine. Removing the package alone does not guarantee removal of all malicious software introduced by it.
The npm package 'dowload_ebok_reiki_sviluppa_e_usa_lenergia_reiki_by_matt_harvey_9q55p' contains malicious code that fully compromises any computer on which it is installed or run. The compromise is severe enough that all secrets and keys stored on the affected system should be rotated immediately from a different, trusted computer. Removal of the package alone does not guarantee elimination of all malicious software introduced by its installation.
The npm package 'dowload_ebok_armageddon_by_max_hastings_kv3s4' contains malicious code that compromises any computer on which it is installed or run. Installation of this package may lead to full system compromise, including unauthorized access to secrets and keys stored on the affected machine. Immediate removal of the package and rotation of all secrets from a different, uncompromised device is strongly advised. However, removal of the package alone may not fully eliminate the malicious presence due to potential persistence mechanisms.
CVE-2026-112941 is a local integrity vulnerability in the SoftReadWriteLock implementation used by the hatch product. It allows a local user with write access to the lock's parent directory to replace the lock's directory tree with symbolic links after the first lock acquisition, causing the lock user process to write lock records into attacker-controlled locations. This results in the lock user's files being replaced or deleted, breaking functionality such as a git repository's operation. The vulnerability affects hatch versions >=1.18.1_1 and <1.18.1_2 on POSIX and Windows platforms. The CVSS score is 3.3 (low severity) due to local attack vector, low integrity impact, and no confidentiality or availability impact. A fix is available in version 1.18.1_2.
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 not removal rights) to forge the process ID in the marker. This causes another process running as the lock owner or root to incorrectly consider the lock stale, remove the live marker, and acquire the lock simultaneously. This results in two processes entering the critical section concurrently without error. The issue arises when the marker file is created with group or other write permissions, typically due to an explicit permissive mode or a lax umask in a sticky or non-removable directory.
A race condition vulnerability exists in the StrictSoftFileLock and AsyncStrictSoftFileLock implementations where a symbolic link swap attack on the <path>.filelock directory can cause claim files to be created in an attacker-controlled directory. This can lead to denial of service by causing other locks to time out until manually force-broken. The vulnerability requires local access and write permissions to rename the .filelock directory in a shared directory without the sticky bit or under specific conditions in sticky directories. The impact includes low confidentiality and integrity but high availability impact. A fix is available in version 1.18.1_2.
The ReadWriteLock and AsyncReadWriteLock classes in the hatch product resolve lock file paths by following symlinks, which allows a local attacker with write access to the lock directory to manipulate the lock behavior. This can cause the victim process to create files at unintended locations, break mutual exclusion by allowing multiple processes to hold the write lock simultaneously, and interfere with SQLite database locking. The vulnerability affects hatch versions from 1.16.4 up to but not including 1.18.1_2 and has a CVSS score of 6.1 (medium severity).
A vulnerability in filelock versions 3.22.0 through 4.2.0 allows a local user with write access to a sticky shared directory (e.g., /tmp) to cause two processes of the lock user to simultaneously hold the same soft file lock. This occurs due to inode reuse and a race condition in the stale-lock break logic, which can remove a live lock file incorrectly. The issue impacts integrity by allowing concurrent holders to write protected data without detection, but does not affect confidentiality or availability.
A vulnerability in filelock versions >=1.18.1_1 and <1.18.1_2 allows a local user who owns the lock's .rw directory tree to interfere with the SoftReadWriteLock holder refresh mechanism. This can cause the lock user's write_lock() or read_lock() calls to hang indefinitely when a named pipe (FIFO) is involved, preventing the heartbeat thread from running and leading to multiple processes believing they hold the write lock simultaneously. Additionally, on Linux systems with permissive hard-link policies, the attacker can cause the lock user to overwrite part of one of its own private files via a hard link. The vulnerability has a CVSS score of 6.1 (Medium) and requires local access with low privileges. A fix is available in version 1.18.1_2.
A vulnerability in filelock's ReadWriteLock and AsyncReadWriteLock components allows a local user with write access to the lock database file path to cause every acquire operation to stall or hang indefinitely, ignoring timeout and blocking flags. This happens because the SQLite-backed lock runs a PRAGMA journal_mode=MEMORY command on each acquire, causing SQLite to load the entire schema from the file at the lock path. A crafted lock database file can exploit this to cause high CPU usage or indefinite hangs, impacting availability but not confidentiality or integrity. The issue affects filelock versions 3.20.4 through 4.2.0 and requires that the attacker can create or overwrite the lock database file, typically in a writable non-sticky shared directory or a database file writable by multiple users. The vulnerability has a CVSS 3.1 score of 5.5 (Medium) and is patched in version 4.2.1 (noted as 1.18.1_2 in the advisory).
A symlink swap race condition in filelock's SoftFileLock writability check allows a local user with directory write permissions to leak one bit of information about whether a path exists and is writable by the lock user. This occurs because the check uses os.lstat followed by os.access, which follows symlinks, enabling a time-of-check to time-of-use (TOCTOU) symlink attack. The vulnerability affects filelock versions 3.32.6 through 4.2.0 and is mitigated on Linux by the fs.protected_symlinks kernel setting in sticky world-writable directories like /tmp. The issue is rated low severity with CVSS 2.5 due to high attack complexity and limited information leakage.
A vulnerability in the filelock library affects StrictSoftFileLock, AsyncStrictSoftFileLock, SoftReadWriteLock, and AsyncSoftReadWriteLock classes. These locks adopt ownership state directories created by other local users if those directories exist before the lock user's first acquire, allowing the other user to interfere with the lock state. This can lead to multiple writers entering critical sections simultaneously, integrity violations, and denial of service by causing lock acquisition to spin indefinitely or consume excessive memory. The vulnerability requires local access and a race condition where the attacker creates the protocol directory first in a shared sticky directory like /tmp. It affects filelock versions 3.30.0 through 4.2.0 and is rated medium severity with CVSS 6.3. A fix is available in version 1.18.1_2 of the affected product hatch.
UnixFileLock, used by FileLock and AsyncFileLock on Unix, truncates and changes permissions of any regular file that another local user renames or hard-links onto the lock path before the lock user's next acquire. This can lead to unintended file truncation and permission changes, allowing the other user to read and modify the file contents afterward. The vulnerability requires local user access and specific filesystem conditions, such as writable non-sticky directories or disabled kernel hardlink protections. It affects all filelock versions up to and including 4.2.0 and has a CVSS score of 6.1 (Medium).
The filelock library versions 3.30.0 through 4.2.0 have a vulnerability in StrictSoftFileLock and AsyncStrictSoftFileLock where claim directories are created without restrictive permissions, allowing other local users with write access to unlink claim files. This can lead to multiple holders writing concurrently without detection, causing integrity issues. The vulnerability requires specific conditions such as a permissive umask or default ACL that grants write permissions to other users on the lock directories. The CVSS score is 5.3 (Medium), reflecting local attack complexity and high integrity impact but no confidentiality loss. A fix is available in version 1.18.1_2.
Authlib versions prior to 1.9.0 contain a critical signature verification bypass vulnerability in the JsonWebSignature.deserialize_json() method. This flaw allows an attacker to submit a JSON Web Signature (JWS) object with an empty signatures array, which the method incorrectly accepts as valid without verifying any signature or requiring a cryptographic key. This results in an attacker-authored payload being accepted as authenticated, enabling a complete authentication bypass when identity or authorization claims are involved.