Vnykmshr

**Nome do Software Vulnerável e Versões Afetadas** Jupyter Server versões anteriores a 2.18.0 **Descrição** A validação do cabeçalho Origin utiliza a função `re.match()` para verificar origens recebidas em relação ao valor de configuração `allow origin pat`. Como o `re.match()` ancora apenas no início da string e não exige uma correspondência completa, um padrão destinado a um domínio confiável também corresponderá a qualquer origem que comece com esse domínio seguido de caracteres adicionais. Isso permite que um invasor que controle tal domínio ignore as restrições de Cross-Origin Resource Sharing (CORS) e faça solicitações de origem cruzada para a API do Jupyter Server a partir de um site não confiável. **Recomendações** Atualize para a versão 2.18.0. Envolva o valor de `allow origin pat` com `^` e `$` para garantir a correspondência completa da string.

**Nome do Software Vulnerável e Versões Afetadas** Argo Workflows versões anteriores a 3.7.14 Argo Workflows versões anteriores a 4.0.5 **Description** Um usuário com permissão de criação de Workflow pode burlar as restrições `templateReferencing: Strict` e `Secure`. Isso ocorre porque o sistema bloqueia apenas o campo `podSpecPatch`, permitindo que outros campos do `WorkflowSpec` sejam mesclados e aplicados aos pods. Um invasor pode usar isso para obter acesso à rede do host, alterar contas de serviço, sobrescrever contextos de segurança de pods, adicionar tolerâncias para agendar pods em nós do plano de controle ou habilitar a montagem de tokens de conta de serviço. A falha é possível quando um workflow referencia um template endurecido que depende de valores padrão para esses campos. Os campos afetados incluem `hostNetwork`, `securityContext`, `serviceAccountName`, `automountServiceAccountToken`, `tolerations`, `dnsPolicy`, `schedulerName`, `hostAliases` e `volumes`. **Recommendations** Atualize para a versão 3.7.14 ou posterior. Atualize para a versão 4.0.5 ou posterior.

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

**Nome do Software Vulnerável e Versões Afetadas** Versões do Soft Serve de 0.6.0 a 0.11.3 **Descrição** O Soft Serve, um servidor Git auto-hospedável, contém uma vulnerabilidade de falsificação de solicitação do lado do servidor (SSRF). Um usuário SSH autenticado pode manipular o servidor para fazer solicitações HTTP para endereços IP internos ou privados utilizando o comando `repo import` com uma URL `--lfs-endpoint` especialmente elaborada. A solicitação inicial é cega, mas um atacante hospedando um servidor LFS falso pode aproveitar isso para obter acesso de leitura completo a serviços internos, fornecendo URLs de download que apontam para alvos internos. A vulnerabilidade origina-se da falta de validação do endpoint controlado pelo usuário e do uso de um cliente HTTP desprotegido. O problema persiste mesmo após a correção do SSRF do webhook na versão 0.11.1, pois ela aborda apenas a funcionalidade do webhook e não o caminho de importação do LFS. A vulnerabilidade pode ser explorada através da sincronização de espelho, criando um SSRF persistente que se repete em cada sincronização agendada. O ataque envolve duas etapas: um SSRF cego para confirmar a alcançabilidade e a leitura de respostas internas via um servidor LFS falso. Isso permite aos atacantes realizar varredura de portas, descobrir serviços, roubar credenciais de nuvem, acessar APIs internas e estabelecer persistência. **Recomendações** Versões anteriores a 0.11.4 são vulneráveis. Aplique a correção sugerida: Substitua `http.DefaultClient` em `pkg/lfs/http client.go` por um cliente seguro usando `ValidateIPBeforeDial` no transporte e `http.ErrUseLastResponse` em `CheckRedirect`. Valide a URL do endpoint em `pkg/backend/repo.go` e `pkg/jobs/mirror.go` usando as mesmas verificações realizadas por `ValidateWebhookURL`.

**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'.