Alessio Della Libera

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.