Zwique

The ` unpack 2bit()` and ` unpack 4bit()` functions resize unpacked arrays based on `TensorProto.dims` without verifying if `raw data` or `int32 data` contains the declared number of elements. An attacker can exploit this by providing a malicious UINT2, INT2, UINT4, INT4, or FLOAT4E2M1 tensor. When processed via `onnx.numpy helper.to array()` or `onnx.reference.ReferenceEvaluator`, a small packed payload can trigger a disproportionately large memory allocation, leading to memory exhaustion.

An Insecure Direct Object Reference (IDOR) issue exists in the `/api/v1/responses` endpoint. This occurs because the `get flow by id or endpoint name()` function fails to verify if the authenticated user owns the flow when it is accessed via a UUID. An authenticated attacker can execute any flow belonging to another user by specifying the victim's flow ID in the `model` parameter. This can lead to the execution of unauthorized workflows, consumption of other users' resources, and access to sensitive data processed by those flows.

The functions `ujson.dumps()`, `ujson.dump()`, and `ujson.encode()` contain an issue when the `reject bytes` variable is set to `False`. In this configuration, the software may accept malformed or truncated UTF-8 byte sequences and silently rewrite them into different Unicode characters instead of rejecting them. This behavior can lead to data integrity issues and the bypass of input validation if such validation is performed before serialization. Technical examples include the replacement of invalid continuation bytes with valid ones, the completion of unterminated sequences, or reading past the end of a string.

Incorrect behavior occurs within Views when processing TCP PROXY requests.

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.

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.

The software fails to clear the `CachedTemplates` dictionary when the `TemplateContext.Reset()` function is called, which allows cached templates to persist across reused contexts. This can be exploited through request-dependent `ITemplateLoader` implementations, enabling unauthorized access to template content from previous renders without re-triggering the `TemplateLoader.Load()` function.

The software fails to apply the `LoopLimit` constraint to expensive iterations performed within built-in operators and functions, applying it only to script loop statements. This allows a single expression to cause excessive CPU or memory consumption, leading to a denial of service. This occurs in applications that render templates controlled by an attacker and rely on `LoopLimit` for safe execution.

Scriban caches TypedObjectAccessor based solely on the type, ignoring changes made to the MemberFilter. This behavior allows reused TemplateContext instances to expose members that were intended to be hidden. An attacker can bypass sandbox policies across different requests or tenants by reusing a TemplateContext after its MemberFilter has been tightened, thereby gaining access to filtered properties and fields.

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.

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.

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.

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.

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.

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

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.

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.