Sermikr0

An issue exists in the webhook delivery component that fails to properly validate target addresses, enabling Server-Side Request Forgery (SSRF). SSRF is a flaw that allows an attacker to induce the server-side application to make requests to an unintended location. An authenticated user with ProjectAdmin permissions can configure a webhook policy targeting private or link-local IP ranges. When a project event occurs, the jobservice sends unauthenticated outbound HTTP POST requests to the specified target. If the target returns an error status, the response body is recorded in the webhook execution log, which is accessible to project members, potentially exposing cloud metadata or other network-restricted resources.

The terminal-server reverse proxy in `backend/open webui/routers/terminals.py` fails to properly confine the user-controlled `path` segment before forwarding it to an admin-configured terminal server. An authenticated user with terminal server access can use encoded `../` traversal sequences to escape the intended path or policy scope, allowing access to unintended files and endpoints on the terminal-server host. If the terminal server forwards requests to internal services, this can lead to Server-Side Request Forgery (SSRF), where the server is induced to make requests to internal resources. Two vectors were identified: raw path forwarding using single-encoded traversal and a bypass of the ` sanitize proxy path` function using double-encoded dots (`%252e%252e`).

Buffer Overflow vulnerability in arendst Tasmota v.15.3.0.3 and before allows a remote attacker to execute arbitrary code via the tasmota/tasmota xdrv driver/xdrv 10 scripter.ino, fetch jpg() function.

A buffer overflow allows a remote attacker to execute arbitrary code. This occurs through the `strcpy()` function within `fetch jpg()` in the `xdrv 10 scripter.ino` file, specifically affecting the `jpg task.boundary[40]` variable.

A heap buffer overflow occurs in the `fetch jpg()` function within the `xdrv 10 scripter.ino` file. This happens because the `Content-Length` from a JPEG stream is stored in a `uint16 t` variable. When values exceed 65535, an integer wrap-around occurs, leading to the allocation of a buffer smaller than the actual data being read.