Zwique

**Name of the Vulnerable Software and Affected Versions** The product name cannot be determined (affected versions not specified) **Description** Incorrect behavior occurs within Views when processing TCP PROXY requests. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** UltraJSON versions prior to 5.12.1 **Description** A memory leak occurs when the `ujson.dump()` function writes to a file-like object and the write operation raises an exception. The `objToJSONFile()` function allocates a Python string object but fails to call `Py DECREF(string)` on the early exit path during a write failure, causing the full size of the serialized payload to be leaked. This can lead to linear memory growth if an application serializes data to an attacker-influenced file-like object that can fail, potentially exhausting the memory of a web server. **Recommendations** Update to version 5.12.1. As a temporary workaround, replace the use of `ujson.dump(obj, file)` with `file.write(ujson.dumps(obj))` to avoid the memory leak.

**Name of the Vulnerable Software and Affected Versions** Traefik versions prior to 2.11.43 Traefik versions prior to 3.6.14 Traefik versions prior to 3.7.0-rc.2 **Description** An authentication bypass exists in the ForwardAuth middleware of Traefik, an HTTP reverse proxy and load balancer. This occurs when `trustForwardHeader` is set to `false` and the software is deployed behind a trusted upstream proxy. **Recommendations** Update to version 2.11.43. Update to version 3.6.14. Update to version 3.7.0-rc.2.

**Name of the Vulnerable Software and Affected Versions** SandboxJS versions prior to 0.8.35 **Description** SandboxJS, a JavaScript sandboxing library, has an issue where timers can bypass execution quotas. A global tick state (`currentTicks.current`) is shared between sandboxes. Timer string handlers are compiled at execution time using this global tick state instead of the scheduling sandbox's tick object. In multi-tenant or concurrent sandbox scenarios, another sandbox can overwrite `currentTicks.current` between scheduling and execution, causing the timer callback to run under a different sandbox's tick budget and bypass the original sandbox's execution quota. This can lead to CPU or resource abuse. The issue is due to the global mutable state shared across all sandbox instances. The `currentTicks.current` variable is used during timer compilation, and if modified by another sandbox, the timer can execute with an incorrect tick budget. A proof of concept demonstrates that a heavy loop can complete and bypass the quota when another sandbox runs before the timer fires. This impacts applications running multiple SandboxJS instances concurrently, such as multi-tenant interpreters, plugin engines, and server-side scripting hosts. **Recommendations** Versions prior to 0.8.35 should be updated to version 0.8.35 or later.

**Name of the Vulnerable Software and Affected Versions** OneUptime versions prior to 10.0.21 **Description** A low-privileged user can bypass authorization and tenant isolation in OneUptime by sending a forged `is-multi-tenant-query` header along with a controlled `projectid` header. The server incorrectly trusts this client-supplied header, skipping internal permission checks in `BasePermission` and disabling tenant scoping. This allows attackers to access project data belonging to other tenants, read sensitive User fields (including `password`, `resetPasswordToken`, and `webauthnChallenge`) via nested relations, leak plaintext `resetPasswordToken`, and ultimately reset the victim’s password, leading to full account takeover. The vulnerability stems from the system trusting a client-controlled header to determine whether to bypass authorization checks. The `createdByUser` relation within the Project model allows access to sensitive user data when select permission checks are bypassed. The reset token is stored in plaintext in the database and can be used to reset the victim’s password. **Recommendations** Versions prior to 10.0.21 should be updated to version 10.0.21 or later.

**Name of the Vulnerable Software and Affected Versions** SiYuan versions prior to 3.5.10 **Description** A privilege escalation issue exists in the publish service of SiYuan Note. A low-privilege publish account (RoleReader) can modify notebook content through the `/api/block/appendHeadingChildren` API endpoint. The endpoint requires only the `model.CheckAuth` role, which accepts RoleReader sessions, but does not enforce stricter checks like `CheckAdminRole` or `CheckReadonly`. This allows a publish user with read-only privileges to append new blocks to existing documents, potentially compromising the integrity of stored notes. The vulnerability stems from insufficient role-based authorization checks on write operations, which are only protected by `CheckAuth`. The vulnerable code is located in `router.go`, `api/block.go`, `model/block.go`, and `model/session.go`. The `/api/block/appendHeadingChildren` API endpoint is central to the issue. The `id` and `childrenDOM` are the vulnerable parameters used in the request. **Recommendations** Update SiYuan to version 3.5.10 or later.

**Name of the Vulnerable Software and Affected Versions** SiYuan versions prior to 3.5.10 **Description** A path traversal flaw exists in the `/export` endpoint, allowing an attacker to read arbitrary files from the server filesystem. Exploitation involves using double-encoded traversal sequences to access sensitive files like `conf/conf.json`, which contains secrets including the API token, cookie signing key, and workspace access authentication code. Leaking these secrets could grant administrative access to the SiYuan kernel API and, in some cases, potentially lead to remote code execution (RCE). The vulnerable code resides in `serve.go` (lines 303, 315, 320, 340, 955-957) and `session.go` (lines 292-295). The vulnerability stems from trusting the output of `url.PathUnescape` and joining it without ensuring the resulting path remains within the `exportBaseDir`. The use of double-encoded traversal sequences (`%252e%252e`) bypasses dot-dot URL rejection, while `CheckAuth` grants admin access for localhost requests to `/export/*` when access auth code is set. A global CORS configuration (`Access-Control-Allow-Origin: *`) allows hostile web pages to read localhost responses. An attacker can send a GET request to `/export/%252e%252e/%252e%252e/conf/conf.json` to retrieve sensitive information. **Recommendations** Versions prior to 3.5.10 should be updated to version 3.5.10 or later.

**Name of the Vulnerable Software and Affected Versions** OliveTin versions prior to 3000.11.1 **Description** OliveTin allows access to predefined shell commands from a web interface. When JWT authentication is configured using a local RSA public key (`authJwtPubKeyPath`) or an HMAC secret (`authJwtHmacSecret`), the configured audience value (`authJwtAud`) is not enforced during token parsing. This allows authentication using JWT tokens intended for a different audience or service. The issue resides in the `jwt.go` file, specifically lines 51–59, 144–157, and 161–168. In Local Public Key Mode and HMAC Mode, the `jwt.WithAudience()` option is not provided, leading to the bypass of audience validation. An attacker possessing a valid JWT signed with the configured key, but intended for a different audience, can authenticate successfully. This enables cross-service token reuse, authentication using tokens issued for other systems, and trust boundary violation in multi-service environments. The API endpoint ''/api/WhoAmI'' is affected, and the `Authorization` header is used to pass the JWT token. The vulnerable parameters include the `aud` claim within the JWT token. This is strictly an authentication validation flaw and does not bypass ACL authorization. **Recommendations** Update OliveTin to version 3000.11.1 or later.

**Name of the Vulnerable Software and Affected Versions** OliveTin versions prior to 3000.11.1 **Description** OliveTin has an authorization issue where authenticated users with insufficient permissions (view: false) can access metadata related to actions through the dashboard and **API endpoints**. Specifically, the backend does not properly enforce view permissions when generating responses for dashboard and action binding information. This allows restricted users to retrieve details like action titles, IDs, icons, and argument metadata, even though they are not authorized to execute those actions. The vulnerable **API endpoints** include '/api/GetDashboard' and '/api/GetActionBinding'. The vulnerable parameter is `bindingId` in the '/api/GetActionBinding' endpoint. The issue stems from a failure to enforce the `IsAllowedView()` function when constructing these responses. **Recommendations** Update OliveTin to version 3000.11.1 or later.

**Name of the Vulnerable Software and Affected Versions** OliveTin versions prior to 3000.11.1 **Description** OliveTin allows access to predefined shell commands from a web interface. A flaw exists in the RestartAction functionality where a low-privileged authenticated user can execute actions they are not permitted to run. This occurs because RestartAction creates a new internal request without preserving the original caller’s authentication, causing the authentication resolver to fall back to the guest user. If the guest account has broader permissions than the authenticated user, this results in privilege escalation and unauthorized command execution. The issue stems from the construction of a new connect.Request within RestartAction, which omits the original caller’s authentication headers and cookies. This allows a user to bypass Access Control Lists (ACL) and execute arbitrary configured shell actions. The vulnerable files include service/internal/api/api.go and service/internal/auth/authcheck.go. The `StartAction` function and the `UserFromApiCall()` function are involved in the authentication process. A proof of concept demonstrates that a low-privileged user can execute commands by leveraging the RestartAction endpoint and an execution tracking ID. This can lead to arbitrary file writes, sensitive data exposure, and potential full host compromise, depending on the runtime privileges of OliveTin. **Recommendations** Update OliveTin to version 3000.11.1 or later.

**Name of the Vulnerable Software and Affected Versions** OliveTin versions prior to 3000.11.1 **Description** OliveTin does not properly invalidate server-side sessions upon user logout. Although the browser cookie is cleared during logout, the corresponding session remains valid in server storage until its natural expiry, which defaults to approximately one year. An attacker possessing a previously stolen or captured session cookie can continue to authenticate after the user has logged out, resulting in a post-logout authentication bypass. This is a session management flaw that violates expected logout semantics. The issue stems from the failure to delete the session identifier (SID) from server-side storage during the logout process. Specifically, the `api.go`, `sessions.go`, and `local.go` files, lines 392-427, 39-59, 61-80, and 32-47 respectively, are involved in the flawed session management. The vulnerability allows an attacker to replay an old SID after logout to maintain authentication. The affected **API endpoint** is `/api/Logout` and `/api/WhoAmI`. The vulnerable variable is `sid`. **Recommendations** Versions prior to 3000.11.1 should be updated to version 3000.11.1 or later to resolve the issue.