Maru1009

**Name of the Vulnerable Software and Affected Versions** Zephyr (affected versions not specified) **Description** A remote, unauthenticated attacker can cause memory corruption in the HTTP server WebSocket upgrade path. The issue occurs because the HTTP/1 header parser uses a bounded copy to move the `Sec-WebSocket-Key` header into a fixed-size buffer without guaranteeing NUL termination when the input length equals the buffer size. During the upgrade process, this buffer is copied to a local stack buffer and processed by the `strlen()` function. If no NUL terminator is present, `strlen()` reads beyond the stack buffer, and the subsequent concatenation with the WebSocket magic string results in an out-of-bounds write. This leads to out-of-bounds read and write operations on stack memory, which can cause a system crash (denial of service) or potentially allow arbitrary code execution. This path is accessible when `CONFIG HTTP SERVER WEBSOCKET` is enabled. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability. As a temporary workaround, disable the `CONFIG HTTP SERVER WEBSOCKET` configuration to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Concrete CMS versions prior to 9.5.1 **Description** Concrete CMS fails to validate a Cross-Site Request Forgery (CSRF) token—a unique identifier used to prevent unauthorized commands from being transmitted from a user the web application trusts—before processing requests to the '/dashboard/extend/update/do update/<pkgHandle>' endpoint. The `do update()` function in 'concrete/controllers/single page/dashboard/extend/update.php' only verifies the `canInstallPackages()` condition before executing `upgradeCoreData()` and `upgrade()` on the specified package controller. Since this endpoint is a state-changing GET route without token enforcement, an attacker can trick an authenticated administrator into triggering a package upgrade through cross-site navigation, provided the administrator passes the `canInstallPackages()` check and the target package is already installed. **Recommendations** Update to a version newer than 9.5.0.

**Name of the Vulnerable Software and Affected Versions** Concrete CMS versions prior to 9.5.1 **Description** A Cross-Site Request Forgery (CSRF) token validation bypass exists where the `local available update.php` view emits a token via `$token->output('do update')`, but the `do update()` function in `concrete/controllers/single page/dashboard/system/update/update.php` fails to call `$this->token->validate('do update')`. Although the form is rendered as a POST form, the controller discards the token without verification. This allows an attacker to craft a cross-site POST request to trigger a core CMS update to a version string specified by the attacker. This requires the victim to pass `canUpgrade()` and a valid update version to be present under `DIR CORE UPDATES`. **Recommendations** Update to a version newer than 9.5.0. As a temporary workaround, restrict access to the `do update()` function in `concrete/controllers/single page/dashboard/system/update/update.php` to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Concrete CMS versions prior to 9.5.1 **Description** Concrete CMS fails to validate a Cross-Site Request Forgery (CSRF) token—a unique value used to prevent unauthorized commands from being transmitted from a user the web application trusts—before processing requests to the endpoint '/dashboard/extend/update/prepare remote upgrade/<remoteMPID>'. An attacker who controls the remote package returned for a known marketplace item ID can overwrite the package PHP on disk and force the `upgrade()` function to execute via a single browser navigation. This leads to remote code execution as the web server user. For this to be possible, the victim must have `canInstallPackages` permissions, the site must be connected to the Concrete marketplace, and the attacker must control the package returned for a marketplace item ID already installed on the victim site. **Recommendations** Update to a version newer than 9.5.0.

**Name of the Vulnerable Software and Affected Versions** Concrete CMS versions prior to 9.5.1 **Description** A Cross-Site Request Forgery (CSRF) issue exists in the `install package()` method of the 'concrete/controllers/single page/dashboard/extend/install.php' endpoint. An attacker can force an authenticated administrator with `canInstallPackages` permissions to install a package if the attacker has already placed a package under `DIR PACKAGES/<handle>/`. Because the installation process executes the package controller's `install()` method as the web server user, this can lead to remote code execution. **Recommendations** Update to a version newer than 9.5.0. As a temporary workaround, restrict access to the 'concrete/controllers/single page/dashboard/extend/install.php' endpoint or disable the `install package()` function until the update is applied.

**Name of the Vulnerable Software and Affected Versions** Concrete CMS versions 9.5.0 and earlier **Description** Concrete CMS fails to validate a Cross-Site Request Forgery (CSRF) token—a unique identifier used to prevent unauthorized commands from being transmitted from a user the web application trusts—before processing requests to the '/dashboard/extend/install/download/<remoteId>' endpoint. The `download()` function in 'concrete/controllers/single page/dashboard/extend/install.php' only verifies the `canInstallPackages()` permission before retrieving a remote marketplace package and saving it to the server's `DIR PACKAGES` directory. Since this endpoint is a state-changing GET route without token enforcement, an attacker can trick an authenticated administrator into visiting a malicious page to force the download of an arbitrary marketplace package. This requires the administrator to have `canInstallPackages()` permissions and the site to be connected to the Concrete marketplace. **Recommendations** Update to a version later than 9.5.0. As a temporary workaround, restrict access to the '/dashboard/extend/install/download/<remoteId>' endpoint to minimize the risk of exploitation.

Name of the Vulnerable Software and Affected Versions SillyTavern versions prior to 1.17.0 Description A path traversal vulnerability exists in the `/api/chats/import` API endpoint. An authenticated attacker can write files to locations outside the intended chats directory by injecting traversal sequences into the `character name` parameter. The `character name` parameter is used without proper sanitization when constructing the destination filename. This allows an attacker to escape the intended directory structure and write files to arbitrary locations, such as `/tmp/...`, potentially leading to integrity and availability issues. Recommendations Upgrade to SillyTavern version 1.17.0 or later.

Name of the Vulnerable Software and Affected Versions SillyTavern versions prior to 1.17.0 Description A path traversal vulnerability exists in the chat endpoints of SillyTavern. An authenticated attacker can read and delete arbitrary files under their user data root, such as `secrets.json` and `settings.json`, by manipulating the `avatar url` parameter with a value of "..". The input validator for `avatar url` inadequately blocks traversal segments like `..`, allowing the construction of malicious file paths. The vulnerable endpoints include the export and delete paths. This allows direct access to files outside the intended chats directory. Successful exploitation can lead to the exposure of sensitive user data and the deletion of critical files, potentially disrupting account operation. Recommendations Update to SillyTavern version 1.17.0 or later.

**Name of the Vulnerable Software and Affected Versions** Kargo versions 1.4.0 through 1.6.3 Kargo versions 1.7.0-rc.1 through 1.7.8 Kargo versions 1.8.0-rc.1 through 1.8.11 Kargo versions 1.9.0-rc.1 through 1.9.4 **Description** Kargo's built-in `http` and `http-download` promotion steps allow Server-Side Request Forgery (SSRF) against link-local addresses, specifically the cloud instance metadata endpoint (169.254.169.254). These steps provide full control over request headers and methods, bypassing cloud provider header-based SSRF mitigations. An authenticated attacker with permissions to create or update Stages or craft Promotion resources can exploit this by submitting a malicious Promotion manifest. Response data can be retrieved via Promotion status fields, Git repositories, or a second http step. The issue enables the exfiltration of sensitive data, such as IAM credentials. The `http` step provides full control over request method and headers, while the `http-download` step provides control over headers only. **Recommendations** Versions 1.4.0 through 1.6.3 should be upgraded to version 1.6.4 or later. Versions 1.7.0-rc.1 through 1.7.8 should be upgraded to version 1.7.9 or later. Versions 1.8.0-rc.1 through 1.8.11 should be upgraded to version 1.8.12 or later. Versions 1.9.0-rc.1 through 1.9.4 should be upgraded to version 1.9.5 or later.

**Name of the Vulnerable Software and Affected Versions** DiceBear versions prior to 9.4.0 **Description** DiceBear is an avatar library used by designers and developers. A flaw exists in the `ensureSize()` function within the `@dicebear/converter` component, prior to version 9.4.0, where it reads the `width` and `height` attributes from input SVG files to determine the output canvas size for rasterization processes like PNG, JPEG, WebP, and AVIF conversion. An attacker can exploit this by providing a specially crafted SVG file with excessively large dimensions, such as `width="999999999"`. This manipulation can force the server to allocate an excessive amount of memory, potentially leading to a denial-of-service condition. This issue primarily impacts server-side applications that process untrusted or user-supplied SVG files using the `toPng()`, `toJpeg()`, `toWebp()`, or `toAvif()` functions of the converter. While applications that only convert self-generated DiceBear avatars are not easily exploitable, upgrading is still recommended. **Recommendations** Versions prior to 9.4.0 should be updated to version 9.4.0 or later. If an immediate upgrade is not possible, validate and sanitize the `width` and `height` attributes of any untrusted SVG input before passing it to the converter.

**Name of the Vulnerable Software and Affected Versions** OneUptime versions prior to 10.0.21 **Description** OneUptime Synthetic Monitors allow a low-privileged authenticated project user to execute arbitrary commands on the `oneuptime-probe` server/container. The root cause is that untrusted Synthetic Monitor code is executed inside Node's `vm` while live host-realm Playwright `browser` and `page` objects are exposed to it. A malicious user can call Playwright APIs on the injected `browser` object and cause the probe to spawn an attacker-controlled executable. This is a server-side remote code execution issue that does not require a separate `vm` sandbox escape. The probe pins Playwright version 1.58.2, which allows the exploitation through the `BrowserType.launch()` function with attacker-controlled parameters like `executablePath` and `args`. The vulnerability is reachable through both one-shot monitor testing and normal scheduled monitor execution. **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** OneUptime versions prior to 10.0.19 **Description** OneUptime’s GitHub App callback does not properly validate the `state` and `installation id` values received from a user, allowing an attacker to overwrite another project's GitHub App installation binding. The callback decodes base64 JSON from the `state` parameter and uses the embedded `projectId` directly. It then updates the `Project.gitHubAppInstallationId` with `isRoot: true` without verifying the caller's authorization for the target project. Related GitHub endpoints also lack effective authorization, enabling a valid installation ID to be used to enumerate repositories and create `CodeRepository` records in an arbitrary project. The vulnerable API endpoints include: `/api/github/auth/callback`, `/api/github/repositories`, and `/api/github/connect`. The `state` and `installation id` parameters are vulnerable. **Recommendations** Versions prior to 10.0.19 should be updated to version 10.0.19 or later.

**Name of the Vulnerable Software and Affected Versions** OneUptime versions prior to 10.0.20 **Description** OneUptime Synthetic Monitors allow low-privileged project users to submit custom Playwright code that is executed on the `oneuptime-probe` service. This code runs within Node's `vm` and is provided with live host Playwright objects, such as `browser` and `page`. This allows an attacker to use the injected `browser` object to execute arbitrary code on the probe host/container via `browser.browserType().launch(...)`. The issue stems from exposing dangerous host capabilities to untrusted code, rather than relying on traditional sandbox escapes. This can be exploited through the `Test Monitor` feature or by creating a malicious Synthetic Monitor, leading to server-side Remote Code Execution (RCE). The `customCode` is passed into `SyntheticMonitor.execute(...)` and then executed through `VMRunner.runCodeInNodeVM(...)`, which creates a Node `vm` context and exposes host objects. The proxy wrapper does not sufficiently block property names, allowing legitimate Playwright methods to be called with the real host `this` binding. **Recommendations** Versions prior to 10.0.20 should be updated to version 10.0.20 or later.

**Name of the Vulnerable Software and Affected Versions** Vito versions prior to 3.20.3 **Description** Vito is a self-hosted web application used for managing servers and deploying PHP applications. A missing authorization check in workflow site-creation actions allows an authenticated attacker with workflow write access in one project to create and manage sites on servers belonging to other projects by providing a foreign `server id`. The issue affects the workflow site-creation actions. **Recommendations** Update to version 3.20.3 or later.

Name of the Vulnerable Software and Affected Versions: SiYuan versions prior to 3.5.9 Description: SiYuan, a personal knowledge management system, contains an unauthenticated reflected cross-site scripting (XSS) vulnerability in the dynamic icon API endpoint 'GET /api/icon/getDynamicIcon' when `type=8`. Attacker-controlled content is embedded into SVG output without proper escaping. Because the endpoint is unauthenticated and returns `image/svg+xml`, a crafted URL can inject executable SVG/HTML event handlers (e.g., `onerror`) and execute JavaScript within the SiYuan web origin. This can potentially lead to authenticated API actions and data exfiltration from logged-in users who open the malicious link. The vulnerability is due to unsafe output construction and incomplete sanitization, specifically the lack of escaping when inserting user-controlled content into SVG output. The API endpoint does not require authentication, and the response is served as `image/svg+xml`, allowing browsers to interpret the payload as an active document. Recommendations: Upgrade to SiYuan version 3.5.9 or later.

**Name of the Vulnerable Software and Affected Versions** Lodash versions prior to 4.18.0 **Description** Lodash versions 4.17.23 and earlier are susceptible to prototype pollution through the ` .unset` and ` .omit` functions. The initial fix did not fully address the issue, as an attacker can bypass the check by using array-wrapped path segments. This allows for the deletion of properties from built-in prototypes like Object.prototype, Number.prototype, and String.prototype. The issue allows deletion of prototype properties but does not permit overwriting their original behavior. **Recommendations** Upgrade to version 4.18.0 or later.