ghsa

A vulnerability exists in Keycloak's server distribution where enabling debug mode (`--debug`) insecurely defaults to binding the Java Debug Wire Protocol (JDWP) port to all network interfaces (`0.0.0.0`). This exposes the debug port to the local network, allowing an attacker on the same network segment to attach a remote debugger and achieve remote code execution within the Keycloak Java virtual machine. Red Hat evaluates this as a Moderate impact vulnerability due to the requirement of running debug mode and untrusted network. Also, for Red Hat Single Sign-On, this must as well be bound to 0.0.0.0 address, which is not recommended in production scenarios.

maxminddb prior to version 0.27 declared `Reader::open_mmap` as safe despite wrapping an inherently unsafe memmap2 operation with no extra step done to guarantee safety. This could have led to undefined behaviour if the file were to be modified on disk while the memory map was still active.

Werkzeug's `safe_join` function allows path segments with Windows device names. On Windows, there are special device names such as `CON`, `AUX`, etc that are implicitly present and readable in every directory. `send_from_directory` uses `safe_join` to safely serve files at user-specified paths under a directory. If the application is running on Windows, and the requested path ends with a special device name, the file will be opened successfully, but reading will hang indefinitely.

The affected function is unsound due to insufficient checks on public struct field.

Mattermost versions 11.0.x <= 11.0.2, 10.12.x <= 10.12.1, 10.11.x <= 10.11.4, 10.5.x <= 10.5.12 fail to validate user permissions when deleting comments in Boards, which allows an authenticated user with the editor role to delete comments created by other users.

Snipe-IT before 8.3.4 allows stored XSS, allowing a low-privileged authenticated user to inject JavaScript that executes in an administrator's session, enabling privilege escalation.

# Summary Affected versions of Better Auth allow an external request to configure `baseURL` when it isn’t defined through any other means. This can be abused to poison the router’s base path, causing all routes to return 404 for all users. This issue is only exploitable when `baseURL` is not explicitly configured (e.g., `BETTER_AUTH_URL` is missing) *and* the attacker is able to make the very first request to the server after startup. In properly configured environments or typical managed hosting platforms, this fallback behavior cannot be reached. # Details A combination of `X-Forwarded-Host` and `X-Forwarded-Proto` is implicitly trusted. This allows the first request to configure baseURL whenever it is not explicitly configured. Here's the code that reads the headers: <img width="631" height="219" alt="headers" src="https://github.com/user-attachments/assets/b3fb0078-a62f-4058-9d0b-4afbd30c4953" /> Here's the call to `getBaseURL()`, the result is assigned to `ctx.baseURL`. <i...

### Summary A DoS can occur that immediately halts the system due to the use of an unsafe function. ### Details According to **RFC 5322**, nested group structures (a group inside another group) are not allowed. Therefore, in lib/addressparser/index.js, the email address parser performs flattening when nested groups appear, since such input is likely to be abnormal. (If the address is valid, it is added as-is.) In other words, the parser flattens all nested groups and inserts them into the final group list. However, the code implemented for this flattening process can be exploited by malicious input and triggers DoS RFC 5322 uses a colon (:) to define a group, and commas (,) are used to separate members within a group. At the following location in lib/addressparser/index.js: https://github.com/nodemailer/nodemailer/blob/master/lib/addressparser/index.js#L90 there is code that performs this flattening. The issue occurs when the email address parser attempts to process the following k...

### Summary XSS vulnerability in OAuth callback server allows JavaScript injection through unsanitized error parameter. Attackers can execute arbitrary JavaScript in the user's browser during OAuth authentication. ### Details **Vulnerable Code:** `spotipy/oauth2.py` lines 1238-1274 (RequestHandler.do_GET) **The Problem:** During OAuth flow, spotipy starts a local HTTP server to receive callbacks. The server reflects the `error` URL parameter directly into HTML without sanitization. **Vulnerable code at line 1255:** ```python status = f"failed ({self.server.error})" ``` **Then embedded in HTML at line 1265:** ```python self._write(f"""<html> <body> <h1>Authentication status: {status}</h1> </body> </html>""") ``` The `error` parameter comes from URL parsing (lines 388-393) without HTML escaping, allowing script injection. **Attack Flow:** 1. User starts OAuth authentication → local server runs on `http://127.0.0.1:8080` 2. Attacker crafts malicious URL: `http://127.0.0.1:8080/?err...

## Summary The `fonttools varLib` (or `python3 -m fontTools.varLib`) script has an arbitrary file write vulnerability that leads to remote code execution when a malicious .designspace file is processed. The vulnerability affects the `main()` code path of `fontTools.varLib`, used by the fonttools varLib CLI and any code that invokes `fontTools.varLib.main()`. The vulnerability exists due to unsanitised filename handling combined with content injection. Attackers can write files to arbitrary filesystem locations via path traversal sequences, and inject malicious code (like PHP) into the output files through XML injection in labelname elements. When these files are placed in web-accessible locations and executed, this achieves remote code execution without requiring any elevated privileges. Once RCE is obtained, attackers can further escalate privileges to compromise system files (like overwriting `/etc/passwd`). Overall this allows attackers to: - Write font files to arbitrary locatio...