An unauthenticated remote denial of service vulnerability exists in the Twisted HTTP/2 server (CVE-2023-44487). A remote client can send a sequence of HTTP/2 frames that cause the server to render requests fully before processing stream resets, allowing CPU exhaustion via rapid stream resets on a single connection. This bypasses the concurrent-stream limit and leads to unbounded request processing. The vulnerability affects Twisted web HTTP/2 server version 26.4.0 and later. There is no impact on confidentiality or integrity, and no code execution is possible.
A vulnerability in twisted.names.dns.DNSDatagramProtocol allows DNS response spoofing due to missing source address validation. The protocol accepts DNS responses based solely on matching transaction IDs without verifying the source address, enabling off-path attackers to inject forged DNS answers if they can send UDP packets with the correct transaction ID. The standard twisted.names.client.Resolver mitigates this risk by using per-query random source ports, increasing entropy, but the underlying missing source validation remains a security gap.
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 lock's initial acquire, causing the lock user process to write lock records through the symlinked paths. This results in the lock user's process deleting or replacing files in directories it can write, such as a private git repository, disrupting its operation. The vulnerability requires specific conditions involving sticky directories or writable parent directories and affects filelock versions 4.1.0 through 4.2.0. The CVSS score is low (3.3) due to local attack vector, low integrity impact, and no confidentiality or availability impact. A fix is available in version 2.19.0_2.
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 without permission to remove it) to forge the process ID recorded in the marker. This causes the lock to be incorrectly judged 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 concurrently entering a critical section without error notification. The issue requires specific filesystem permissions and directory configurations, such as group or other write bits on the marker and a sticky or non-removable directory. The vulnerability is fixed in version 2.19.0_2.
A vulnerability in filelock versions 3.30.0 through 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. By swapping the .filelock directory with a symbolic link between an lstat check and subsequent operations, the attacker can cause the lock user to create claim files in a directory chosen by the attacker. 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 the scrapy product resolve lock file paths by following symlinks, which allows a local attacker with write access to the lock directory to manipulate the victim process into creating or locking files at unintended locations. This can lead to breaking mutual exclusion between victim processes, causing resource corruption or denial of service. The vulnerability affects scrapy versions from 2.14.2 up to but not including 2.19.0_1 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 unprivileged user to cause two processes of the lock owner to simultaneously hold the same soft file lock. This occurs due to a stale-lock break mechanism that incorrectly removes a live lock file when inode numbers are reused by the filesystem (e.g., ext4, xfs). The flaw requires a sticky shared directory where the attacker can create files and a race condition between lock contenders. The integrity of the lock is compromised, allowing concurrent holders to write protected data without detection.
CVE-2026-112934 is a medium-severity vulnerability in filelock versions >=2.19.0_1 and <2.19.0_2 where the SoftReadWriteLock holder refresh mechanism can be manipulated by a different local user who owns the lock's .rw directory tree. This can cause the lock user's write operations to hang indefinitely on named pipes (FIFOs) or overwrite part of a private file via hard links if the kernel permits such links. The vulnerability allows a local attacker with low privileges to cause denial of service by stalling lock acquisition and heartbeat threads, resulting in two processes simultaneously believing they hold the write lock. There is no confidentiality impact, and integrity impact is limited to the overwritten bytes of the lock record itself. A fix is available in version 2.19.0_2.
A vulnerability in filelock's ReadWriteLock and AsyncReadWriteLock components allows a local user who can place or overwrite the SQLite lock database file to cause every acquire operation to stall or hang indefinitely, ignoring timeout and blocking settings. 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 and requires the attacker to have write access to the lock file path or directory. The vulnerability is rated medium severity with a CVSS score of 5.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) leak. 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 common sticky world-writable directories like /tmp. The impact is limited to leaking a single bit per acquire attempt, with no integrity or availability impact. The vulnerability requires local access, the ability to create entries in the lock directory, and high timing precision to exploit.
A vulnerability in filelock's StrictSoftFileLock and SoftReadWriteLock classes allows a local unprivileged user to pre-create the lock protocol directory in a shared sticky directory (e.g., /tmp). This causes the lock implementation to adopt a directory owned by the attacker, enabling them to interfere with lock claims and cause multiple processes to enter critical sections simultaneously. The flaw affects filelock versions 3.30.0 through 4.2.0 and can lead to integrity and availability impacts, such as concurrent writes and denial of service via spinning or memory exhaustion. The vulnerability requires the attacker to race the legitimate user by creating the directory first on a new or cleaned lock path. A fix is available in version 2.19.0_2 of the affected product scrapy.
The UnixFileLock component in the FileLock and AsyncFileLock implementations 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 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 specific directory permissions or kernel settings. The issue is fixed in filelock version 2.19.0_2.
The filelock library versions from 3.30.0 up to 4.2.0 have a vulnerability in StrictSoftFileLock and AsyncStrictSoftFileLock where claim directories are created without applying the intended restrictive mode, allowing other local users with write permissions on these directories to unlink claim files. This can lead to multiple holders simultaneously writing protected data without detection. The vulnerability requires a local attacker with write access to the lock's claim directories, which depends on the environment's umask or default ACL settings. The issue is fixed in version 2.19.0_2 of the affected product.
A vulnerability in Octodns using dnspython allows a malicious DNS message to cause excessive CPU usage during DNS name decompression. This can degrade or deny service to applications processing untrusted DNS wire format messages. The issue is fixed in dnspython version 2.9.0. No workarounds are currently known.