Guido Vranken

**Name of the Vulnerable Software and Affected Versions** OpenSSL (affected versions not specified) **Description** A malicious server can exploit TLS OCSP stapling by delivering a crafted response through the `status request` extension. This triggers a double-free in the client's certificate verification path when the stapled response is checked. A double-free occurs when a program attempts to free the same memory location twice, which can corrupt heap memory. This may lead to a Denial of Service, attacker-controlled code execution, or other undefined behavior. OCSP stapling is not enabled by default. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability. As a temporary workaround, consider disabling OCSP stapling to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** PuTTY versions 0.71 through 0.83 **Description** An assertion failure occurs during the ECDSA (Elliptic Curve Digital Signature Algorithm) signature verification process.

**Name of the Vulnerable Software and Affected Versions** iOS versions prior to 26.5 iPadOS versions prior to 26.5 macOS Tahoe versions prior to 26.5 tvOS versions prior to 26.5 visionOS versions prior to 26.5 watchOS versions prior to 26.5 **Description** Processing maliciously crafted web content may lead to an unexpected process crash due to improper memory handling. **Recommendations** Update iOS to version 26.5. Update iPadOS to version 26.5. Update macOS Tahoe to version 26.5. Update tvOS to version 26.5. Update visionOS to version 26.5. Update watchOS to version 26.5.

**Name of the Vulnerable Software and Affected Versions** circl versions prior to 1.6.3 **Description** The `CombinedMult` function within the `ecc/p384` package (secp384r1 curve) calculates an incorrect value for certain inputs. This issue does not affect ECDH and ECDSA signing operations that rely on this curve. The problem is resolved by implementing complete addition formulas. **Recommendations** Update to version 1.6.3 or later.

**Name of the Vulnerable Software and Affected Versions** golang.org/x/net/html (affected versions not specified) **Description** The `html.Parse` function can enter an infinite parsing loop when processing specific HTML inputs. This can result in a denial of service (DoS) if an attacker provides crafted HTML content. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** golang.org/x/net/html (affected versions not specified) **Description** The `html.Parse` function exhibits quadratic parsing complexity when handling specific inputs. This can result in a denial of service (DoS) if an attacker submits maliciously crafted HTML content. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Golang versions prior to the fixed version **Description** The issue is related to uncontrolled resource consumption in the Golang programming language. An attacker can craft an input to the Parse functions that would be processed non-linearly with respect to its length, resulting in extremely slow parsing. This could cause a denial of service. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited. **Recommendations** For Golang versions prior to the fixed version, consider disabling the `Parse` functions until a patch is available. Restrict access to the vulnerable `Parse` functions to minimize the risk of exploitation. Avoid using the `Parse` functions in the affected API endpoints until the issue is resolved. Update to a version that includes the fix for this issue, such as the version that includes the upgrade of `golang.org/x/net`.

**Name of the Vulnerable Software and Affected Versions** python-idna version 3.6 **Description** The issue arises from the `idna.encode()` function's handling of crafted input strings, which can lead to quadratic complexity and consequently, a denial of service condition. This is triggered by a crafted input that causes the `idna.encode()` function to process the input with considerable computational load, significantly increasing the processing time in a quadratic manner relative to the input size. The vulnerability may allow a remote attacker to cause a denial of service. **Recommendations** For version 3.6, consider updating to version 3.7, where the function has been refined to reject such strings without the associated resource consumption. As a temporary workaround, enforce a length limit of 253 characters on domain names prior to passing them to the `idna.encode()` function to prevent significant resource consumption.

**Name of the Vulnerable Software and Affected Versions** Go (affected versions not specified) **Description** The issue is related to the ScalarMult and ScalarBaseMult methods of the P256 Curve in the Go programming language, which may return incorrect results when called with specific unreduced scalars. This could potentially allow a remote attacker to impact the integrity of protected information. The issue does not affect usages of crypto/ecdsa or crypto/ecdh. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** No specific software or versions are mentioned in the provided descriptions. **Description** The issue concerns the multiplication of certain unreduced P-256 scalars, which can produce incorrect results. However, there are no known protocols that can be attacked due to this issue. The problem arises because the P-256 assembly does not use complete addition formulas, which can lead to incorrect results when the two inputs are equal. This was previously mitigated by always reducing the scalar, but a change in the math/big rewrite removed this reduction, assuming it was not necessary. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Go versions prior to 1.15.12 Go versions 1.16.x prior to 1.16.4 **Description** The issue allows remote attackers to cause a denial of service (panic) via a large header to `ReadRequest` or `ReadResponse`. Server, Transport, and Client can each be affected in some configurations. A malicious HTTP server or client can cause the net/http client or server to panic. `ReadRequest` and `ReadResponse` can hit an unrecoverable panic when reading a very large header. **Recommendations** For Go versions prior to 1.15.12, update to version 1.15.12 or later to resolve the issue. For Go versions 1.16.x prior to 1.16.4, update to version 1.16.4 or later to resolve the issue. As a temporary workaround, consider setting `Server.MaxHeaderBytes` to a lower value to minimize the risk of exploitation. Restrict access to the `Transport` and `Client` components to minimize the risk of exploitation. Avoid using the `ReadRequest` and `ReadResponse` functions with large headers until the issue is resolved.

Name of the Vulnerable Software and Affected Versions: glibc versions prior to 2.32 Description: The issue is related to the functions cosl, sinl, sincosl, and tanl in the GNU C Library (glibc), which can cause a buffer overflow. This can lead to a denial of service by damaging the stack when calling trigonometric functions with a pseudo-zero argument. Specifically, the problem occurs when an input to an 80-bit long double function contains a non-canonical bit pattern, such as passing a 0x5d414141414141410000 value to sinl on x86 targets. Recommendations: For glibc versions prior to 2.32, update to version 2.32 or later to resolve the issue. As a temporary workaround, consider restricting the use of the vulnerable functions cosl, sinl, sincosl, and tanl until a patch is available. Avoid using non-canonical bit patterns as input to these functions to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Squid versions prior to 4.10 **Description** An issue was discovered due to incorrect buffer management, allowing a remote client to cause a buffer overflow in a Squid instance acting as a reverse proxy. This can potentially impact the confidentiality, integrity, and availability of protected information. **Recommendations** For versions prior to 4.10, update to version 4.10 or later to resolve the issue. As a temporary workaround, consider restricting access to the reverse proxy functionality until a patch is available.

**Name of the Vulnerable Software and Affected Versions** OpenWrt versions 18.06.0 through 18.06.6 OpenWrt version 19.07.0 LEDE versions 17.01.0 through 17.01.7 **Description** A bug in the fork of the opkg package manager prevents correct parsing of embedded checksums in the signed repository index, allowing a man-in-the-middle attacker to inject arbitrary package payloads, which are installed without verification. This issue is related to a problem with the code that checks the SHA-256 checksums present in the signed digital signature index of packages, allowing an attacker to create conditions under which these checksums are ignored, thus bypassing the integrity checking mechanisms of the downloaded ipk resources. **Recommendations** For OpenWrt versions 18.06.0 through 18.06.6, update to version 18.06.7. For OpenWrt version 19.07.0, update to version 19.07.1. For LEDE versions 17.01.0 through 17.01.7, no specific fix is provided, consider updating to a newer version of OpenWrt. As a temporary workaround, consider disabling the use of the opkg package manager until a patch is available. Restrict access to the package repository to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Firefox versions prior to 70 Firefox ESR versions prior to 68.2 Thunderbird versions prior to 68.2 **Description** The issue is related to a buffer overflow due to unbounded copying of user input. This could allow a remote attacker to access sensitive data, compromise its integrity, and potentially cause a denial of service. An attacker may also be able to execute arbitrary code or cause the application to crash by writing past the end of a buffer stored on the stack. **Recommendations** For Firefox versions prior to 70, update to version 70 or later to resolve the issue. For Firefox ESR versions prior to 68.2, update to version 68.2 or later to resolve the issue. For Thunderbird versions prior to 68.2, update to version 68.2 or later to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** Django versions 1.11.x through 1.11.22 Django versions 2.1.x through 2.1.10 Django versions 2.2.x through 2.2.3 **Description** The issue is related to the `django.utils.text.Truncator` class, specifically the `chars()` and `words()` methods. When these methods are passed the `html=True` argument, they can be extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. This vulnerability can be exploited to cause a denial of service. The `chars()` and `words()` methods are used to implement the `truncatechars html` and `truncatewords html` template filters. **Recommendations** For Django versions 1.11.x through 1.11.22, update to version 1.11.23 or later. For Django versions 2.1.x through 2.1.10, update to version 2.1.11 or later. For Django versions 2.2.x through 2.2.3, update to version 2.2.4 or later. As a temporary workaround, consider avoiding the use of the `html=True` argument in the `chars()` and `words()` methods until a patch is available.

**Name of the Vulnerable Software and Affected Versions** Django versions 1.11.x through 1.11.22 Django versions 2.1.x through 2.1.10 Django versions 2.2.x through 2.2.3 **Description** The issue is related to the HTMLParser function in django.utils.html.strip tags, which can be slow to evaluate large input sequences containing incomplete HTML entities. This can be exploited by a remote attacker to cause a denial of service. **Recommendations** For Django versions 1.11.x through 1.11.22, update to version 1.11.23 or later. For Django versions 2.1.x through 2.1.10, update to version 2.1.11 or later. For Django versions 2.2.x through 2.2.3, update to version 2.2.4 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Commons Imaging version 0.97-incubator **Description** The issue allows certain input files to cause the code to enter an infinite loop when parsed, potentially leading to a Denial of Service (DoS) attack. **Recommendations** For version 0.97-incubator, consider updating to a newer version to mitigate the risk of exploitation, as the issue could be used in a DoS attack. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Apache Sanselan version 0.97-incubator **Description** The issue allows certain input files to cause the code to hang when parsed, potentially leading to a denial-of-service (DoS) attack. Note that Apache Sanselan was later renamed to Apache Commons Imaging. **Recommendations** For Apache Sanselan version 0.97-incubator, consider updating to a newer version of Apache Commons Imaging to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** ZeroMQ libzmq versions 4.2.x through 4.3.0 **Description** The issue is caused by an integer overflow in the ZeroMQ libzmq library, which can be exploited by a remote attacker to execute arbitrary code. Specifically, a `v2 decoder t::size ready` integer overflow in v2 decoder.cpp allows an authenticated attacker to overwrite an arbitrary amount of bytes beyond the bounds of a buffer. This can be leveraged to run arbitrary code on the target system by injecting OS commands into a data structure located immediately after the problematic buffer. **Recommendations** For ZeroMQ libzmq versions 4.2.x through 4.3.0, update to version 4.3.1 or later to resolve the issue. As a temporary workaround, consider restricting access to the `v2 decoder t::size ready` function to minimize the risk of exploitation.