#git

## 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...

In a hearing with the CEOs of the five most used social media platforms the Senate Judiciary Committee found common ground for the need to protect children online

By Waqas Anonymous Sudan alleges that the cyber attack they conducted has crippled the reservation system and other online assets of the targeted entity. This is a post from HackRead.com Read the original post: Anonymous Sudan Claims DDOS Attacks on UAE’s Flydubai Airline

## 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...

## Impacted Resources bref/src/Event/Http/Psr7Bridge.php:94-125 ## 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 for each which contains a file, it is extracted and saved in `/tmp` with a random filename starting with `bref_upload_`. The function implementing the logic follows: ```php private static function parseBodyAndUploadedFiles(HttpRequestEvent $event): array { $bodyString = $event->getBody(); $files = []; $parsedBody = null; $contentType = $event->getContentType(); if ($contentType !== null && $event->getMethod() === 'POST') { if (str_starts_with($contentType, 'application/x-www-form-urlencoded')) { parse_str($bodyString, $parsedBody); } else { $document = new Part("Content-type: $contentType\r\n\r\n" . $body...

## Summary [The bounds check for slices](https://github.com/vyperlang/vyper/blob/b01cd686aa567b32498fefd76bd96b0597c6f099/vyper/builtins/functions.py#L404-L457) does not account for the ability for `start + length` to overflow when the values aren't literals. If a `slice()` function uses a non-literal argument for the `start` or `length` variable, this creates the ability for an attacker to overflow the bounds check. This issue can be used to do OOB access to storage, memory or calldata addresses. It can also be used to corrupt the `length` slot of the respective array. A contract search was performed and no vulnerable contracts were found in production. tracking in issue https://github.com/vyperlang/vyper/issues/3756. ## Details Here the flow for `storage` is supposed, but it is generalizable also for the other locations. When calling `slice()` on a storage value, there are compile time bounds checks if the `start` and `length` values are literals, but of course this cannot ...

The classic builder cache system is prone to cache poisoning if the image is built `FROM scratch`. Also, changes to some instructions (most important being `HEALTHCHECK` and `ONBUILD`) would not cause a cache miss. An attacker with the knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered as a valid cache candidate for some build steps. For example, an attacker could create an image that is considered as a valid cache candidate for: ``` FROM scratch MAINTAINER Pawel ``` when in fact the malicious image used as a cache would be an image built from a different Dockerfile. In the second case, the attacker could for example substitute a different `HEALTCHECK` command. ### Impact 23.0+ users are only affected if they explicitly opted out of Buildkit (`DOCKER_BUILDKIT=0` environment variable) or are using the `/build` API endpoint (which uses the classic builder by default). All users on versions ...