Alessio Della Libera

**Name of the Vulnerable Software and Affected Versions** node-twain versions all **Description** The issue arises from improper check or handling of exceptional conditions due to the length of the source data not being checked. Creating a new `twain.TwainSDK` with a `productName` or `productFamily`, `manufacturer`, `version.info` property of length >= 34 chars leads to a buffer overflow. **Recommendations** For all versions, consider restricting the length of `productName`, `productFamily`, `manufacturer`, and `version.info` properties to less than 34 characters to minimize the risk of exploitation until a patch is available. As a temporary workaround, consider disabling the creation of new `twain.TwainSDK` instances with long property values. 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** audify versions all **Description** The issue arises from improper validation of array index when `frameSize` is provided to the `new OpusDecoder().decode` or `new OpusDecoder().decodeFloat` functions, as it is not checked for negative values. This can lead to a process crash. **Recommendations** For all versions, as a temporary workaround, consider validating the `frameSize` variable to ensure it does not contain negative values before passing it to the `new OpusDecoder().decode` or `new OpusDecoder().decodeFloat` functions. Restrict access to these functions until a proper fix is applied. 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** package images (affected versions not specified) **Description** The issue is related to providing unexpected input types to several different functions, which can lead to a process crash due to reaching an assert macro. Specifically, providing certain integer values, such as 0, to the `size` function can result in a Segmentation fault error, causing the process to crash. **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** speaker (affected versions not specified) **Description** The issue is related to a Denial of Service (DoS) condition that can occur when the `channels` property of the `Speaker` object receives unexpected input types, leading to an assert macro being reached and potentially causing a process crash. **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** node-stringbuilder versions all **Description** The issue arises from incorrect memory length calculation in the node-stringbuilder package, leading to an Out-of-bounds Read. This occurs when methods such as `ToBuffer`, `ToString`, or `CharAt` are called on a `StringBuilder` object with a non-empty string value input. Providing negative indexes can result in the return of previously allocated memory, leading to an Information Disclosure. **Recommendations** For all versions, consider disabling the `ToBuffer`, `ToString`, and `CharAt` methods on `StringBuilder` objects until a patch is available to prevent potential Information Disclosure. Restrict the use of negative indexes to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** @discordjs/opus versions all **Description** The issue is related to a Denial of Service (DoS) condition that can occur when an input object with a `toString` property is provided to several different functions. This can lead to a system or process crash. **Recommendations** As a temporary workaround, consider restricting the input to functions to prevent objects with a `toString` property from being processed until a patch is available. 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-getter versions prior to 1.7.4 go-getter/v2 branch and package are not affected Description: The go-getter library is vulnerable to argument injection when executing Git to discover remote branches. An attacker may format a Git URL in order to inject additional Git arguments to the Git call. This can be done when go-getter is performing a Git operation and tries to clone the given repository, checking the remote repository's HEAD reference of its default branch by passing arguments to the Git binary on the host it is executing on. Recommendations: For go-getter versions prior to 1.7.4, upgrade to version 1.7.4 or later to resolve the issue. As a temporary workaround, consider restricting the use of Git URLs that could be used to inject additional Git arguments until a patch is available. Consumers of the go-getter library should evaluate the risk associated with these issues in the context of their go-getter usage.

**Name of the Vulnerable Software and Affected Versions** ithewei/libhv versions all **Description** The issue arises when untrusted user input is used to build header values, allowing an attacker to inject malicious content by adding carriage return line feeds (`r `) to end the HTTP response headers. This can lead to a potential XSS vulnerability, enabling the attacker to inject additional headers or a new response body. **Recommendations** For all versions, consider validating and sanitizing user input to prevent the injection of malicious characters, such as `r `, into HTTP response headers. As a temporary workaround, restrict the use of user-inputted data in building header values until a more comprehensive fix is available.

**Name of the Vulnerable Software and Affected Versions** ithewei/libhv versions all **Description** The issue affects the ithewei/libhv package, where untrusted user input used to set request headers can lead to CRLF Injection. An attacker can inject additional headers into the request by adding carriage return line feeds (`r `) characters. **Recommendations** For all versions, consider restricting the use of untrusted user input in setting request headers until a patch is available. As a temporary workaround, validate and sanitize all user input to prevent the injection of malicious characters, such as `r `.

**Name of the Vulnerable Software and Affected Versions** ithewei/libhv versions all **Description** The issue concerns Cross-site Scripting (XSS) where filenames containing malicious payloads are not properly sanitized when rendered. This occurs when a file with such a name is served by the application. **Recommendations** For all versions, consider implementing proper sanitization of filenames to prevent XSS attacks. As a temporary workaround, restrict the ability to upload files with potentially malicious names until a proper fix is applied.

**Name of the Vulnerable Software and Affected Versions** crow (affected versions not specified) **Description** The issue concerns HTTP Response Splitting when untrusted user input is used to build header values. Header values are not properly sanitized against CRLF Injection in the `set header` and `add header` functions. An attacker can add the `r ` (carriage return line feeds) characters to end the HTTP response headers and inject malicious 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** drogonframework/drogon versions prior to the fixed version **Description** The issue arises when untrusted user input is used to set request headers in the `addHeader` function, allowing an attacker to inject additional headers by adding `r ` (carriage return line feeds) characters. This enables the injection of extra headers in the request sent. **Recommendations** For drogonframework/drogon, as a temporary workaround, consider disabling the `addHeader` function until a patch is available. Restrict access to untrusted user input to minimize the risk of exploitation. Avoid using untrusted user input to set request headers until the issue is resolved. 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** drogonframework/drogon (affected versions not specified) **Description** The issue arises when untrusted user input is used to build header values in the `addHeader` and `addCookie` functions, allowing an attacker to inject malicious content by adding `r ` (carriage return line feeds) characters to end the HTTP response headers. This enables HTTP Response Splitting, where an attacker can manipulate the HTTP response to inject malicious 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** semver versions prior to 7.5.2 semver versions prior to 6.3.1 on the 6.x branch semver versions prior to 5.7.2 **Description** The issue is related to the use of a regular expression with inefficient computational complexity in the semver package, which can lead to a Regular Expression Denial of Service (ReDoS) via the `new Range` function when untrusted user data is provided as a range. This can allow a remote attacker to cause a denial of service. **Recommendations** For semver versions prior to 7.5.2, update to version 7.5.2 or later. For semver versions prior to 6.3.1 on the 6.x branch, update to version 6.3.1 or later. For semver versions prior to 5.7.2, update to version 5.7.2 or later. As a temporary workaround, consider restricting the use of the `new Range` function to trusted input only until a patch is available.

**Name of the Vulnerable Software and Affected Versions** github.com/xyproto/algernon/engine (affected versions not specified) github.com/xyproto/algernon/themes (affected versions not specified) **Description** The issue is related to Cross-site Scripting (XSS) due to improper user input sanitization in the `themes.NoPage(filename, theme)` function. This can be exploited when a file or resource is not found. **Recommendations** For github.com/xyproto/algernon/engine, consider disabling the `themes.NoPage(filename, theme)` function until a patch is available. For github.com/xyproto/algernon/themes, restrict access to the `themes.NoPage(filename, theme)` function to minimize the risk of exploitation. 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** yhirose/cpp-httplib versions prior to 0.12.4 **Description** The issue is related to the incomplete fix for a previous problem, which allows an attacker to inject arbitrary HTTP headers when untrusted user input is used to set the content-type header in HTTP requests, such as .Patch, .Post, .Put, and .Delete. This can lead to logical errors and other misbehaviors. The vulnerability is due to the lack of measures to neutralize CRLF sequences. **Recommendations** For versions prior to 0.12.4, update to version 0.12.4 or later to resolve the issue. As a temporary workaround, consider validating and sanitizing user input for the content-type header to prevent CRLF injection. Restrict access to the HTTP .Patch, .Post, .Put, and .Delete requests until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** deno versions prior to 1.31.0 **Description** The issue is related to Regular Expression Denial of Service (ReDoS) due to the `upgradeWebSocket` function, which contains regexes in the form of `/s*,s*/`, used for splitting the `Connection/Upgrade` header. A specially crafted `Connection/Upgrade` header can be used to significantly slow down a web socket server. **Recommendations** For deno versions prior to 1.31.0, it is recommended that users upgrade to Deno 1.31.0. As a temporary workaround, consider restricting access to the `upgradeWebSocket` function until a patch is available. Avoid using the `Connection/Upgrade` header with specially crafted values in the affected API endpoint until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** swift-corelibs-foundation (affected versions not specified) **Description** A program using FoundationNetworking in swift-corelibs-foundation is potentially vulnerable to CRLF injection in URLRequest headers. This allows a client to insert one or several CRLF sequences into a URLRequest header value, which can be interpreted by the server as extra headers or even a second request. For example, a URLRequest to "http://example.com/" with the GET method and a header "Foo" set to "Bar Extra-Header: Added GET /other HTTP/1.1" can appear to the server as two requests. This vulnerability escalates if un-sanitized user input is placed in header values, allowing a malicious user to inject new headers or requests to an intermediary or backend server. **Recommendations** As a temporary workaround, consider sanitizing user input in header values to prevent CRLF injection. Upgrade swift-corelibs-foundation to a version that includes the patch for this issue. If un-sanitized user input is used in header values, restrict access to vulnerable modules or functions to minimize the risk of exploitation. 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** Async HTTP Client versions prior to 1.13.2 **Description** The issue is related to insufficient validation of HTTP header field values before sending them to the network, allowing attackers to inject new HTTP header fields or entirely new requests into the data stream. This can cause requests to be understood differently by the remote server than intended, potentially resulting in logical errors and other misbehaviors. Users are vulnerable if they pass untrusted data into HTTP header field values without prior sanitization, such as placing usernames from a database into HTTP header fields. **Recommendations** For versions prior to 1.13.2, update to version 1.13.2 or later to resolve the issue. As a temporary workaround, consider sanitizing all untrusted data before passing it into HTTP header field values to minimize the risk of exploitation. Restrict access to sensitive data and functions that may be affected by the injection of new HTTP header fields or requests. Avoid using untrusted data in HTTP header fields until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** NIOHTTP1 (affected versions not specified) SwiftNIO (affected versions not specified) **Description** The issue occurs when a HTTP/1.1 server accepts user-generated input from an incoming request and reflects it into a HTTP/1.1 response header. A malicious user can add newlines to their input and "inject" those newlines into the returned HTTP response, allowing them to work around security headers and HTTP/1.1 framing headers. This can lead to XSS, cache poisoning, and other flaws. **Recommendations** For NIOHTTP1, consider adding validation to the HTTPHeaders type to ensure no whitespace is incorrectly present in the HTTP headers provided by users. For SwiftNIO, consider adding a default channel handler that polices outbound headers to prevent HTTP Response Injection attacks. At the moment, there is no information about a newer version that contains a fix for this vulnerability.