Serhiy Storchaka

Attacker-controlled CSV samples can trigger super-linear regular-expression work during dialect sniffing, leading to significant CPU consumption when applications pass unbounded input to the `csv.Sniffer.sniff()` function. Super-linear regular-expression work refers to a condition where the time taken to process a string increases disproportionately to the length of the input, potentially causing a denial of service.

The incremental HTML parser `html.parser.HTMLParser` contains an issue that allows for CPU denial-of-service when processing uncontrolled data. The root cause is improper input handling that leads to pathological parsing behavior, specifically algorithmic complexity and resource exhaustion, when markup declarations are repeatedly left unterminated. An attacker can exploit this by providing crafted HTML to any service or pipeline using `HTMLParser`, which can result in CPU core exhaustion and the degradation or complete failure of affected applications.

`bz2.BZ2Decompressor` objects can be reused following a decompression error. If an application catches the resulting `OSError` and attempts to retry using the same decompressor, specially crafted input may cause the decompressor to resume from an invalid internal state. This leads to out-of-bounds writes to a stack buffer, which can result in a process crash when processing untrusted data.

The `unicodedata.normalize()` function can consume excessive CPU time when processing specially crafted Unicode input. This occurs when the input contains long sequences of combining characters with alternating Canonical Combining Class values, affecting all normalization forms.

On Windows, the `shutil.unpack archive()` function fails to properly check for absolute paths within ZIP archives. If an archive contains a path with a drive letter (e.g., `C:`), files may be extracted outside of the intended target directory.

Name of the Vulnerable Software and Affected Versions Base64 (affected versions not specified) Description The decoding process using `base64.b64decode()` or related functions would halt upon encountering the first padded quad, even if additional data remained. This could result in the acceptance of data that might be handled differently by other implementations. Using "validate=True" enables stricter base64 data processing. Recommendations Utilize "validate=True" when calling `base64.b64decode()` or related functions to enforce stricter base64 data processing.

The 'zipfile' module does not validate the ZIP64 End of Central Directory (EOCD) Locator record offset value, leading to potential discrepancies in how ZIP archives are handled compared to other ZIP implementations. Specifically, the module incorrectly assumes the ZIP64 EOCD record's location, potentially allowing crafted ZIP archives to be processed in an unexpected manner.

The `html.parser.HTMLParser` class contains a flaw where processing certain crafted malformed inputs results in worst-case quadratic complexity. This occurs due to the use of a regular expression with inefficient computational complexity, which can lead to CPU exhaustion and an amplified denial-of-service.

An issue exists in the `tarfile` module when extracting untrusted tar archives. When using the `TarFile.extractall()` or `TarFile.extract()` functions with the `filter` parameter set to `data` or `tar`, it is possible to modify file metadata (such as last modified time) or file permissions (chmod) for files located outside the intended extraction directory. In Python 3.14 and later, the default value of the `filter` parameter changed to `data`, making users who rely on this default behavior susceptible to the issue. This can lead to arbitrary file modification on the system and potential data loss.

The issue allows the extraction filter to be ignored, enabling symlink targets to point outside the destination directory and the modification of some file metadata. This affects users who utilize the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() with the filter parameter set to "data" or "tar". For Python 3.14 and later, the default filter value changed to "data", which also affects usage relying on this new default behavior. The installation of source distributions, which are tar archives, is not significantly affected as they already allow arbitrary code execution during the build process.

An issue in the `tarfile` module allows the extraction filter to be ignored when extracting untrusted tar archives. This can enable an attacker to create symbolic links that point outside the destination directory, modify file metadata, and potentially modify files in arbitrary filesystem locations, leading to data loss or unauthorized access to protected information. The issue occurs when using the `TarFile.extractall()` or `TarFile.extract()` functions with the `filter` parameter set to `data` or `tar`. For Python versions 3.14 and later, the default value of the `filter` parameter is `data`, making usage relying on this default behavior also susceptible.

Python incorrectly handles tar archive extraction when using the filtering option. Specifically, when `TarFile.errorlevel` is set to `0` during extraction with a filter, the system fails to skip filtered members as documented, extracting them instead. This issue could allow a remote attacker to modify files in arbitrary filesystem locations, potentially leading to data loss or compromising the integrity of protected information.

An issue in the `tarfile` module allows arbitrary filesystem writes outside the extraction directory when extracting untrusted tar archives. This occurs when using the `TarFile.extractall()` or `TarFile.extract()` functions with the `filter` parameter set to `data` or `tar`. For Python 3.14 and later, the default value of `filter` changed to `data`, making usage relying on this default behavior also susceptible. An attacker could exploit this to modify files in arbitrary locations, cause data loss, or potentially achieve privilege escalation or container escape if the scripts are executed with root privileges.

When reading an HTTP response from a server, if no read amount is specified, the default behavior is to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing Out Of Memory (OOM) errors or other Denial of Service (DoS) conditions. The issue resides in the `http.client` module.

The plistlib module does not properly validate the size of plist files during loading. A malicious plist file can specify a size that causes the module to attempt to allocate an excessive amount of memory, leading to an out-of-memory (OOM) condition and potential denial-of-service (DoS) issues.

The issue allows remote attackers to obtain sensitive information, such as process memory, or cause a denial of service, resulting in memory corruption and crash, via unspecified vectors. This is due to the utf-16 decoder not updating the aligned end variable after calling the unicode decode call errorhandler function.