ghsa

### Summary When a WebDriver is used to fetch files source:file:///etc/passwd can be used to retrieve local system files, where the more traditional file:///etc/passwd gets blocked ### Details The root cause is the payload source:file:///etc/passwdpasses the regex [here](https://github.com/dgtlmoon/changedetection.io/blob/master/changedetectionio/model/Watch.py#L19) and also passes the check [here](https://github.com/dgtlmoon/changedetection.io/blob/master/changedetectionio/processors/__init__.py#L35) where a traditional file:///etc/passwd would get blocked ### PoC [CL-ChangeDetection.io Path Travsersal-311024-181039.pdf](https://github.com/user-attachments/files/17591630/CL-ChangeDetection.io.Path.Travsersal-311024-181039.pdf) ### Impact It depends on where the webdriver is deployed but generally this is a high impact vulnerability

### Summary By default `oak` does not allow transferring of hidden files with `Context.send` API. However, this can be bypassed by encoding `/` as its URL encoded form `%2F`. ### Details 1.) Oak uses [decodeComponent](https://github.com/oakserver/oak/blob/3896fe568b25ac0b4c5afbf822ff8344c3d1712a/send.ts#L182C10-L182C25) which seems to be unexpected. This is also the reason why it is not possible to access a file that contains URL encoded characters unless the client URL encodes it first. 2.) The function [isHidden](https://github.com/oakserver/oak/blob/3896fe568b25ac0b4c5afbf822ff8344c3d1712a/send.ts#L117-L125) is flawed since it only checks if the first subpath is hidden, allowing secrets to be read from `subdir/.env`. ### PoC ```ts // server.ts import { Application } from "jsr:@oak/[email protected]"; const app = new Application(); app.use(async (context, next) => { try { await context.send({ root: './root', hidden: false, // default }); } catch { await ...

Versions of the package sinatra from 0.0.0 are vulnerable to Reliance on Untrusted Inputs in a Security Decision via the X-Forwarded-Host (XFH) header. When making a request to a method with redirect applied, it is possible to trigger an Open Redirect Attack by inserting an arbitrary address into this header. If used for caching purposes, such as with servers like Nginx, or as a reverse proxy, without handling the X-Forwarded-Host header, attackers can potentially exploit Cache Poisoning or Routing-based SSRF.

Plenti, a static site generator, has an arbitrary file deletion vulnerability in versions prior to 0.7.2. The `/postLocal` endpoint is vulnerable to an arbitrary file write deletion when a plenti user serves their website. This issue may lead to information loss. Version 0.7.2 fixes the vulnerability.

Plenti, a static site generator, has an arbitrary file write vulnerability in versions prior to 0.7.2. The `/postLocal` endpoint is vulnerable to an arbitrary file write vulnerability when a plenti user serves their website. This issue may lead to Remote Code Execution. Version 0.7.2 fixes the vulnerability.

An issue was discovered in Ollama before 0.1.46. An attacker can use two HTTP requests to upload a malformed GGUF file containing just 4 bytes starting with the GGUF custom magic header. By leveraging a custom Modelfile that includes a FROM statement pointing to the attacker-controlled blob file, the attacker can crash the application through the CreateModel route, leading to a segmentation fault (signal SIGSEGV: segmentation violation).

Glossarizer through 1.5.2 improperly tries to convert text into HTML. Even though the application itself escapes special characters (e.g., <>), the underlying library converts these encoded characters into legitimate HTML, thereby possibly causing stored XSS. Attackers can append a XSS payload to a word that has a corresponding glossary entry.

Thanks @pventuzelo for reporting. From the correspondence: > Hi, > > We (Fuzzinglabs & Lambdaclass) found that during deserialization of certain files representing a `VerifyingKey`, an excessive memory allocation is happening consuming a lot of resources and even triggering a crash with the error `fatal error: runtime: out of memory`. > > Please find the details below: > > ## Vulnerability Details > > - **Severity:** Critical -> DoS > - **Affected Component:** Deserialization > > ## Environment > > - **Compiler Version:** go version go1.22.2 linux/amd64 > - **Distro Version:** Ubuntu 24.04.1 LTS > > - **Additional Environment Details:** > - `[github.com/consensys/gnark](http://github.com/consensys/gnark) v0.11.0` > - `[github.com/consensys/gnark-crypto](http://github.com/consensys/gnark-crypto) v0.14.1-0.20240909142611-e6b99e74cec1` > > ## Steps to Reproduce > > You can download the needed files here: https://drive.google.com/drive/folders/1KQ5I3vv4bUllvqbatGappwbAkIcR2N...

Vault Community and Vault Enterprise (“Vault”) clusters using Vault’s Integrated Storage backend are vulnerable to a denial-of-service (DoS) attack through memory exhaustion through a Raft cluster join API endpoint. An attacker may send a large volume of requests to the endpoint which may cause Vault to consume excessive system memory resources, potentially leading to a crash of the underlying system and the Vault process itself. This vulnerability, CVE-2024-8185, is fixed in Vault Community 1.18.1 and Vault Enterprise 1.18.1, 1.17.8, and 1.16.12.

### Impact A community member disclosed an issue where verification signatures for requests sent to Reverb's Pusher-compatible API were not being verified. This API is used in scenarios such as broadcasting a message from a backend service or for obtaining statistical information (such as number of connections) about a given channel. The verification signature is a hash comprised of different parts of the request signed by the app's secret key. The signature is sent as part of the request and should be regenerated by Reverb. Only when both the signature in the request and the one generated by Reverb match should the request be allowed. This helps to verify the request came from a known source. > [!NOTE] > This issue only affects the Pusher-compatible API endpoints and not the WebSocket connections themselves. In order to exploit this vulnerability, the application ID which, should never be exposed, would need to be known by an attacker. The following endpoints were affected: ```...