ghsa

### Summary If PDF.js is used to load a malicious PDF, and PDF.js is configured with `isEvalSupported` set to `true` (which is the default value), unrestricted attacker-controlled JavaScript will be executed in the context of the hosting domain. ### Patches [This patch](https://github.com/wojtekmaj/react-pdf/commit/671e6eaa2e373e404040c13cc6b668fe39839cad) forces `isEvalSupported` to `false`, removing the attack vector. ### Workarounds Set `options.isEvalSupported` to `false`, where `options` is `Document` component prop. ### References - [GHSA-wgrm-67xf-hhpq](https://github.com/mozilla/pdf.js/security/advisories/GHSA-wgrm-67xf-hhpq) - https://github.com/mozilla/pdf.js/pull/18015 - https://github.com/mozilla/pdf.js/commit/85e64b5c16c9aaef738f421733c12911a441cec6 - https://bugzilla.mozilla.org/show_bug.cgi?id=1893645

An issue in tiagorlampert CHAOS before 1b451cf62582295b7225caf5a7b506f0bad56f6b and 24c9e109b5be34df7b2bce8368eae669c481ed5e allows a remote attacker to execute arbitrary code via the unsafe concatenation of the `filename` argument into the `buildStr` string without any sanitization or filtering.

In Eclipse Dataspace Components from version 0.2.1 to 0.6.2, in the [EDC Connector component](https://github.com/eclipse-edc/Connector), an attacker might obtain OAuth2 client secrets from the vault. In Eclipse Dataspace Components from version 0.2.1 to 0.6.2, we have identified a security vulnerability in the EDC Connector component ( https://github.com/eclipse-edc/Connector ) regarding the OAuth2-protected data sink feature. When using a custom, OAuth2-protected data sink, the OAuth2-specific data address properties are resolved by the provider data plane. Problematically, the consumer-provided clientSecretKey, which indicates the OAuth2 client secret to retrieve from a secrets vault, is resolved in the context of the provider's vault, not the consumer. This secret's value is then sent to the tokenUrl, also consumer-controlled, as part of an OAuth2 client credentials grant. The returned access token is then sent as a bearer token to the data sink URL. This feature is now disabled e...

An authenticated user could potentially access metadata for a datasource they are not authorized to view by submitting a targeted REST API request. This issue affects Apache Superset before 4.0.0. Users are recommended to upgrade to version 4.0.0, which fixes the issue.

Minder's `HandleGithubWebhook` is susceptible to a denial of service attack from an untrusted HTTP request. The vulnerability exists before the request has been validated, and as such the request is still untrusted at the point of failure. This allows an attacker with the ability to send requests to `HandleGithubWebhook` to crash the Minder controlplane and deny other users from using it. One of the first things that `HandleGithubWebhook` does is to validate the payload signature. This is done by way of the internal helper `validatePayloadSignature`: https://github.com/stacklok/minder/blob/ee66f6c0763212503c898cfefb65ce1450c7f5ac/internal/controlplane/handlers_githubwebhooks.go#L213-L218 `validatePayloadSignature` generates a reader from the incoming request by way of the internal helper `readerFromRequest`: https://github.com/stacklok/minder/blob/ee66f6c0763212503c898cfefb65ce1450c7f5ac/internal/controlplane/handlers_githubwebhooks.go#L337-L342 To create a reader from the incomin...

### Impact If pdf.js is used to load a malicious PDF, and PDF.js is configured with `isEvalSupported` set to `true` (which is the default value), unrestricted attacker-controlled JavaScript will be executed in the context of the hosting domain. ### Patches The patch removes the use of `eval`: https://github.com/mozilla/pdf.js/pull/18015 ### Workarounds Set the option `isEvalSupported` to `false`. ### References https://bugzilla.mozilla.org/show_bug.cgi?id=1893645

### Impact If using `keep_typographic_whitespace=False` (which is the default), the sanitizer normalizes unicode to the NFKC form at the end. Some unicode characters normalize to chevrons; this allows specially crafted HTML to escape sanitization. ### Patches The problem has been fixed in 2.4.2. ### Workarounds Set `keep_typographic_whitespace=True` explicitly, or normalize to NFKC yourself earlier.

The debugger in affected versions of Werkzeug can allow an attacker to execute code on a developer's machine under some circumstances. This requires the attacker to get the developer to interact with a domain and subdomain they control, and enter the debugger PIN, but if they are successful it allows access to the debugger even if it is only running on localhost. This also requires the attacker to guess a URL in the developer's application that will trigger the debugger.

The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for the previous GHSA-h5c8-rqwp-cp95 CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe.

# Summary **Local File Inclusion via Path Traversal in LiteStar Static File Serving** A Local File Inclusion (LFI) vulnerability has been discovered in the static file serving component of [LiteStar](https://github.com/litestar-org/litestar). This vulnerability allows attackers to exploit path traversal flaws, enabling unauthorized access to sensitive files outside the designated directories. Such access can lead to the disclosure of sensitive information or potentially compromise the server. ## Details The vulnerability is located in the file path handling mechanism within the static content serving function, specifically at [line 70 in `litestar/static_files/base.py`](https://github.com/litestar-org/litestar/blob/main/litestar/static_files/base.py#L70). The function fails to properly validate the destination file path derived from user input, thereby permitting directory traversal. The critical code segment is as follows: ```python commonpath([str(directory), file_info["name"], j...