Multiple security vulnerabilities have been identified and fixed in Apache Tomcat as packaged for Red Hat Enterprise Linux 9.2. These include security constraint bypass, access control bypass due to an off-by-one error, improper input validation allowing HTTP/2 no-authority bypass of strict SNI validation, improper authentication due to principal lookup failure, authentication bypass via replay attack in DIGEST authenticator, unauthorized resource access via FORM authentication bypass, and denial of service via HTTP/2 allocation leak. Red Hat has released updated Tomcat packages addressing these issues.
Multiple vulnerabilities in aiohttp versions >=3.25.2_3 and <3.25.2_5 can lead to excessive or unbounded memory and CPU usage triggered by attacker-controlled requests. This resource exhaustion can degrade service availability or cause denial of service. A fix is available in version 3.25.2_5.
A vulnerability in the dnspython library'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 2.9.0. No known workarounds exist.
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 permissions in the directory containing the lock database to manipulate these files, causing the lock user to write arbitrary data into their own files, create or unlink files, or cause lock acquisition failures. The vulnerability affects filelock versions from 3.20.4 through 4.2.0, with the fixed version being 3.25.2_5. The CVSS 3.1 score is 7.1 (High), reflecting local attack complexity but high integrity and availability impact. The issue requires a writable directory without the sticky bit and is mitigated by kernel protections and directory permissions.
A vulnerability in filelock versions 3.22.0 through 3.25.2_5 allows a local user with write access to a lock marker file (but without permission to remove it) to forge the process ID recorded in the marker. This causes another process that checks the marker to incorrectly consider the lock stale and remove the live marker, resulting in two processes simultaneously holding the lock and potentially corrupting the protected resource. The issue arises when the marker file is created or modified with group or other write permissions, such as with an explicit permissive mode or a lax umask in a sticky or non-removable directory. The vulnerability has a CVSS 3.1 score of 4.7 (Medium) and requires local access with low privileges and high attack complexity.
A vulnerability in filelock versions >=3.30.0 and <=4.2.0 allows a local user with write access to a shared directory to exploit a race condition involving symbolic links in the lock coordination directory (<path>.filelock). By swapping this directory with a symbolic link between a check and subsequent operations, the attacker can cause the lock user's process to create claim files in an attacker-chosen directory. This can lead to denial of service by causing stranded claims that block other processes from acquiring the lock until manually force-broken.
The ReadWriteLock and AsyncReadWriteLock classes in lexicon versions >=3.23.2_4 and <3.25.2_5 resolve lock file paths by following symlinks and then open them with 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 unintended locations, potentially breaking mutual exclusion and corrupting protected resources. The issue affects Linux, macOS, and Windows 11. A fix is available in lexicon version 3.25.2_5.
A flaw 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 owner to simultaneously hold the same lock. This occurs due to inode reuse on filesystems like ext4 and xfs, enabling a stale-lock break to remove a live lock file incorrectly. The vulnerability leads to a high integrity impact as concurrent holders can write protected data without detection.
A vulnerability in filelock versions 4.0.0 through 4.2.0 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 process to hang when writing to a named pipe (FIFO) or overwrite part of its own private file via a hard link under certain kernel configurations. The issue leads to a denial of service by stalling lock acquisition and heartbeat threads, allowing multiple processes to believe they hold the write lock simultaneously. The vulnerability requires local access and specific filesystem conditions, such as permissive hard-link policies or ownership of the lock directory in a sticky or writable directory. A fix is available in version 3.25.2_5.
A vulnerability in the filelock Python package'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 statement that loads the entire schema of the database file, and a crafted database file can cause the acquire to consume excessive CPU and memory or never return. The impact is denial of service (availability) only, with no confidentiality or integrity compromise. Versions 3.20.4 through 4.2.0 are affected.
On Windows, the filelock library's ReadWriteLock and AsyncReadWriteLock use SQLite side files for locking. A local user who can create files but not delete others' files in the lock directory can place a specially crafted side file (e.g., -wal or -journal) beside the database. This causes the lock user to encounter disk I/O errors or unexpected file deletions during lock acquisition, resulting in partial denial of service. The issue affects filelock versions 3.20.4 through 4.2.0 on Windows. A fix is available in version 3.25.2_5.
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 because the check uses os.lstat followed by os.access, which follows symlinks, enabling a time-of-check to time-of-use (TOCTOU) race condition. 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 impact is limited to leaking a single bit of information per lock acquire attempt, with no integrity or availability impact. The vulnerability requires local access, the ability to create entries in the lock directory, and a race condition timing that is complex to achieve.
The vulnerability involves the StrictSoftFileLock and SoftReadWriteLock classes adopting a protocol directory created by another local user before the lock user's first acquire operation. This allows the other user to interfere with the lock state by unlinking claims or redirecting lock operations, potentially causing multiple writers to enter a critical section simultaneously and causing denial of service by spinning or memory exhaustion. The issue affects filelock versions 3.30.0 through 4.2.0 and requires the attacker to create the directory first in a shared sticky directory like /tmp. The CVSS 3.1 score is 6.3 (Medium).
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. 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 introduced since version 3.10.2. Exploitation requires local access and the ability to rename or hard-link files in certain directory conditions. The issue is patched in version 3.25.2_5.
The filelock library versions 3.30.0 through 4.2.0 have a vulnerability in the StrictSoftFileLock and AsyncStrictSoftFileLock classes 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. The issue arises when the environment's umask or default ACLs permit write access to these directories. The vulnerability impacts integrity by allowing concurrent writes protected by the lock, with no confidentiality or significant availability impact.
On Windows, certain soft lock implementations in filelock (versions 3.22.0 through 4.2.0) can be blocked indefinitely due to Windows opportunistic locks (oplocks) on the lock marker file. Another local user with read access can take a Level 1 oplock on a stale marker file and never release it, causing SoftFileLock.acquire() calls to hang past their timeout. This results in partial availability impact without compromising confidentiality or integrity. The issue is fixed in filelock version 3.25.2_5.
AIOHTTP's pure Python HTTP parser is vulnerable to an HTTP request smuggling attack when used instead of the default C parser. This affects applications using the Python parser, such as those with the AIOHTTP_NO_EXTENSIONS environment or non-standard wheel installations. The vulnerability is fixed in version 3.25.2_5.
A vulnerability in AIOHTTP allows a subdomain to remove the Host-Only flag from an existing cookie set for a parent domain. This could reduce cookie security protections for users accessing untrusted subdomains. The impact is limited because most use cases do not reflect these cookies back to the browser.
CVE-2026-111748 is a vulnerability in aiohttp where an attacker can spoof the Request.scheme attribute by sending an absolute-form HTTP request. This can mislead applications relying on this attribute for security decisions, such as determining whether a connection is encrypted. The issue affects versions >=3.25.2_3 and <3.25.2_5. A fix is available in version 3.25.2_5. A workaround is to use a WAF rule to block absolute-form requests, which are typically only legitimate for proxy usage.