ghsa

Ylianst MeshCentral 1.1.16 suffers from Use of a Broken or Risky Cryptographic Algorithm.

### Impact Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626. ### Patches `runc` runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4. ### Workarounds Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability. ### References * [CVE-2024-21626](https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv) * [Vulnerability: runc process.cwd and leaked fds container breakout](https://snyk.io/blog/cve-2024-21626-runc-process-cwd-container-breakout/)

## Summary When calls to external contracts are made, we write the input buffer starting at byte 28, and allocate the return buffer to start at byte 0 (overlapping with the input buffer). When checking `RETURNDATASIZE` for dynamic types, the size is compared only to the minimum allowed size for that type, and not to the returned value's `length`. As a result, malformed return data can cause the contract to mistake data from the input buffer for returndata. This advisory is given a severity of "Low" because when the called contract returns invalid ABIv2 encoded data, the calling contract can read different invalid data (from the dirty buffer) than the called contract returned. ## Details When arguments are packed for an external call, we create a buffer of size `max(args, return_data) + 32`. The input buffer is placed in this buffer (starting at byte 28), and the return buffer is allocated to start at byte 0. The assumption is that we can reuse the memory becase we will not be able ...

# Impact There is a potential for a mutation XSS (mXSS) vulnerability in AntiSamy caused by flawed parsing of the HTML being sanitized. To be subject to this vulnerability the `preserveComments` directive must be enabled in your policy file. As a result, certain crafty inputs can result in elements in comment tags being interpreted as executable when using AntiSamy's sanitized output. # Patches Patched in AntiSamy 1.7.5 and later. This is due to parsing behavior in the [neko-htmlunit](https://github.com/HtmlUnit/htmlunit-neko) dependency, just by updating to a newer version the issue was solved. See important remediation details in the reference given below. # Workarounds If you cannot upgrade to a fixed version of the library, the following mitigation can be applied until you can upgrade: Manually edit your AntiSamy policy file (e.g., antisamy.xml) by deleting the `preserveComments` directive or setting its value to `false`, if present. As the previously mentioned policy settin...

### Vulnerability Overview A vulnerability has been identified in Central Dogma versions prior to 0.64.0, allowing for the leakage of user sessions and subsequent authentication bypass. The issue stems from a Cross-Site Scripting (XSS) attack vector that targets the RelayState of Security Assertion Markup Language (SAML). ### Impact Successful exploitation of this vulnerability enables malicious actors to leak user sessions, leading to the compromise of authentication mechanisms. This, in turn, can facilitate unauthorized access to sensitive resources. ### Patches This vulnerability is addressed and resolved in Central Dogma version 0.64.0. Users are strongly encouraged to upgrade to this version or later to mitigate the risk associated with the authentication bypass. ### Workarounds No viable workarounds are currently available for this vulnerability. It is recommended to apply the provided patch promptly. ### References - [OASIS SAML v2.0 Errata 05](https://docs.oasis-open.org/se...

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-34q3-p352-c7q8. This link is maintained to preserve external references. ## Original Description Central Dogma versions prior to 0.64.0 is vulnerable to Cross-Site Scripting (XSS), which could allow for the leakage of user sessions and subsequent authentication bypass.

Versions of the package dash-core-components before 2.13.0; all versions of the package dash-core-components; versions of the package dash before 2.15.0; all versions of the package dash-html-components; versions of the package dash-html-components before 2.0.16 are vulnerable to Cross-site Scripting (XSS) when the href of the a tag is controlled by an adversary. An authenticated attacker who stores a view that exploits this vulnerability could steal the data that's visible to another user who opens that view - not just the data already included on the page, but they could also, in theory, make additional requests and access other data accessible to this user. In some cases, they could also steal the access tokens of that user, which would allow the attacker to act as that user, including viewing other apps and resources hosted on the same server. **Note:** This is only exploitable in Dash apps that include some mechanism to store user input to be reloaded by a different user.

Before Beetl v3.15.12, the rendering template has a server-side template injection (SSTI) vulnerability. When the incoming template is controllable, it will be filtered by the DefaultNativeSecurityManager blacklist. Because blacklist filtering is not strict, the blacklist can be bypassed, leading to arbitrary code execution.

## Impacted Resources bref/src/Event/Http/Psr7Bridge.php:130-168 ## Description When Bref is used with the Event-Driven Function runtime and the handler is a `RequestHandlerInterface`, then the Lambda event is converted to a PSR7 object. During the conversion process, if the request is a MultiPart, each part is parsed and its content added in the `$files` or `$parsedBody` arrays. To do that, the following method is called with as first argument the result array (`$files` or `$parsedBody`), as second argument the part name, and as third argument the part content: ```php /** * Parse a string key like "files[id_cards][jpg][]" and do $array['files']['id_cards']['jpg'][] = $value */ private static function parseKeyAndInsertValueInArray(array &$array, string $key, mixed $value): void { if (! str_contains($key, '[')) { $array[$key] = $value; return; } $parts = explode('[', $key); // files[id_cards][jpg][] => [ 'files', 'id_cards]', 'jpg]', ']' ] $point...

## Impacted Resources bref/src/Event/Http/HttpResponse.php:61-90 ## Description When Bref is used in combination with an API Gateway with the v2 format, it does not handle multiple values headers. Precisely, if PHP generates a response with two headers having the same key but different values only the latest one is kept. ## Impact If an application relies on multiple headers with the same key being set for security reasons, then Bref would lower the application security. For example, if an application sets multiple `Content-Security-Policy` headers, then Bref would just reflect the latest one. ## PoC 1. Create a new Bref project. 2. Create an `index.php` file with the following content: ```php <?php header("Content-Security-Policy: script-src 'none'", false); header("Content-Security-Policy: img-src 'self'", false); ?> <script>alert(document.domain)</script> <img src="https://bref.sh/favicon-32x32.png"> ``` 3. Use the following `serverless.yml` to deploy the Lambda: ```yaml se...