Vnykmshr

**Name of the Vulnerable Software and Affected Versions** Jupyter Server versions prior to 2.18.0 **Description** Origin header validation uses the `re.match()` function to check incoming origins against the `allow origin pat` configuration value. Because `re.match()` only anchors at the start of the string and does not require a full match, a pattern intended for a trusted domain will also match any origin that begins with that domain followed by additional characters. This allows an attacker controlling such a domain to bypass Cross-Origin Resource Sharing (CORS) restrictions and make cross-origin requests to the Jupyter Server API from an untrusted site. **Recommendations** Update to version 2.18.0. Wrap the `allow origin pat` value with `^` and `$` to ensure a full string match.

**Name of the Vulnerable Software and Affected Versions** Argo Workflows versions prior to 3.7.14 Argo Workflows versions prior to 4.0.5 **Description** A user with create Workflow permission can bypass the `templateReferencing: Strict` and `Secure` restrictions. This occurs because the system only blocks the `podSpecPatch` field, allowing other `WorkflowSpec` fields to be merged and applied to pods. An attacker can use this to obtain host network access, switch service accounts, override pod security contexts, add tolerations to schedule pods on control-plane nodes, or enable service account token mounting. The bypass is possible when a workflow references a hardened template that relies on default values for these fields. The affected fields include `hostNetwork`, `securityContext`, `serviceAccountName`, `automountServiceAccountToken`, `tolerations`, `dnsPolicy`, `schedulerName`, `hostAliases`, and `volumes`. **Recommendations** Update to version 3.7.14 or later. Update to version 4.0.5 or later.

**Name of the Vulnerable Software and Affected Versions** dagu versions 2.0.0 through 2.3.0 **Description** Dagu suffers from a path traversal issue due to incomplete fixes for CVE-2026-27598. The initial fix addressed path traversal in the `CreateNewDAG` function, but the `locateDAG` function still allows traversal via `%2F`-encoded slashes. Specifically, the `locateDAG` function does not validate that the requested file path is within the expected directory, leading to arbitrary file read, delete, and potentially remote code execution. The issue arises because the Chi v5 router captures path segments containing encoded slashes, which are then decoded and passed to `locateDAG` without proper validation. This allows attackers to access files outside the intended DAGs directory. The `findDAGFile` function resolves the path using `filepath.Abs` and only checks for the YAML extension, without verifying containment within the base directory. Affected API endpoints include `GET /dags/{fileName}/spec`, `DELETE /dags/{fileName}`, and `POST /dags/{fileName}/start`, as well as other endpoints utilizing the `{fileName}` parameter. An authenticated user, or any user if authentication is disabled, can potentially read or delete arbitrary `.yaml`/`.yml` files on the server's filesystem. The `locateDAG` function is the core component affected. **Recommendations** Versions 2.0.0 through 2.3.0 are vulnerable. Add path containment validation to the `locateDAG` function to prevent access to files outside the intended directory. Reject file names containing path separators for all HTTP-facing callers. If the separator code path is required for internal worker communication, split `locateDAG` into a validated public method for HTTP handlers and an internal method for trusted callers only.

**Name of the Vulnerable Software and Affected Versions** OneUptime versions prior to 10.0.34 **Description** OneUptime, a service monitoring solution, contains a SQL injection issue. Specifically, the `toSortStatement`, `toSelectStatement`, and `toGroupByStatement` methods within the `StatementGenerator` component do not validate user-supplied object keys before interpolating them as ClickHouse Identifier parameters. This allows an attacker to inject arbitrary SQL code through crafted `sort`, `select`, or `groupBy` keys in API requests. The issue stems from the lack of validation when constructing SQL queries, as ClickHouse Identifier parameters are substituted directly into queries without escaping. This impacts any analytics list or aggregate endpoint backed by `BaseAnalyticsAPI.getList()` or `BaseAnalyticsAPI.getAggregate()`, including analytics queries for logs, metrics, spans, and exceptions. The vulnerable parameters are found in the request body, specifically `sort`, `select`, and `groupBy`. The vulnerable methods are `toSortStatement()`, `toSelectStatement()`, and `toGroupByStatement()`. **Recommendations** Versions prior to 10.0.34 should be updated to version 10.0.34 or later. Add the same `getTableColumn()` validation already present in `toWhereStatement` to the three unvalidated methods: `toSortStatement`, `toSelectStatement`, and `toGroupByStatement`. Specifically, within each of these methods, iterate over the keys and verify they correspond to actual model columns using `this.model.getTableColumn(key)`.

**Name of the Vulnerable Software and Affected Versions** Soft Serve versions 0.6.0 through 0.11.3 **Description** Soft Serve, a self-hostable Git server, contains a server-side request forgery (SSRF) issue. An authenticated SSH user can manipulate the server to make HTTP requests to internal or private IP addresses by utilizing the `repo import` command with a specially crafted `--lfs-endpoint` URL. The initial request is blind, but an attacker hosting a fake LFS server can leverage this to gain full read access to internal services by providing download URLs that point to internal targets. The vulnerability stems from the lack of validation of the user-controlled endpoint and the use of an unprotected HTTP client. The issue persists even after the webhook SSRF fix in version 0.11.1, as it only addresses the webhook functionality and not the LFS import path. The vulnerability can be exploited through mirror synchronization, creating persistent SSRF that repeats on every scheduled sync. The attack involves two stages: a blind SSRF to confirm reachability and reading internal responses via a fake LFS server. This allows attackers to perform port scanning, discover services, steal cloud credentials, access internal APIs, and establish persistence. **Recommendations** Versions prior to 0.11.4 are vulnerable. Apply the suggested fix: Replace `http.DefaultClient` in `pkg/lfs/http client.go` with a secure client using `ValidateIPBeforeDial` in the transport and `http.ErrUseLastResponse` in `CheckRedirect`. Validate the endpoint URL in `pkg/backend/repo.go` and `pkg/jobs/mirror.go` using the same checks `ValidateWebhookURL` performs.

**Name of the Vulnerable Software and Affected Versions** SiYuan versions 3.6.0 and earlier **Description** SiYuan, a personal knowledge management system, has an incomplete blocklist in its SanitizeSVG function. The function blocks 'data:text/html' and 'data:image/svg+xml' in 'href' attributes but fails to block 'data:text/xml' and 'data:application/xml', both of which can render SVG with JavaScript execution. The unauthenticated API endpoint ''/api/icon/getDynamicIcon'' serves user-controlled input via the `content` parameter directly into SVG markup using fmt.Sprintf without escaping, served as Content-Type: image/svg+xml. This creates a click-through XSS issue where a victim navigating to a crafted URL sees an SVG with an injected link, and clicking it triggers JavaScript through the bypassed MIME types. The attack requires direct navigation to the endpoint or embedding via the <object> or <embed> tags. The vulnerable code resides in `kernel/util/misc.go` lines 289-293, where the blocklist does not include 'text/xml' and 'application/xml'. **Recommendations** Update to version 3.6.1 or later. As an alternative, modify the data: URI check to an allowlist, permitting only safe image types in 'href', such as 'data:image/png', 'data:image/jpeg', 'data:image/gif', and 'data:image/webp'.