Zwique

As funções ` unpack 2bit()` e ` unpack 4bit()` redimensionam arrays descompactados com base em `TensorProto.dims` sem verificar se `raw data` ou `int32 data` codificam o número declarado de elementos. Um invasor pode explorar isso fornecendo um tensor UINT2, INT2, UINT4, INT4 ou FLOAT4E2M1 malicioso. Quando processados via `onnx.numpy helper.to array()` ou `onnx.reference.ReferenceEvaluator`, um payload compactado pequeno pode expandir-se em uma alocação desproporcionalmente grande, exaurindo a memória.

Um problema de Referência Direta a Objeto Insegura (IDOR) existe no endpoint `/api/v1/responses`. Isso ocorre porque a função `get flow by id or endpoint name()` não verifica se o usuário autenticado é o proprietário do fluxo quando este é acessado via UUID. Um invasor autenticado pode executar qualquer fluxo pertencente a outro usuário ao especificar o ID do fluxo da vítima no parâmetro `model`. Isso pode levar à execução de fluxos de trabalho não autorizados, consumo de recursos de outros usuários e acesso a dados sensíveis processados por esses fluxos.

As funções `ujson.dumps()`, `ujson.dump()` e `ujson.encode()` possuem um problema quando a variável `reject bytes` é definida como `False`. Nesta configuração, o software pode aceitar sequências de bytes UTF-8 malformadas ou truncadas, reescrevendo-as silenciosamente em diferentes caracteres Unicode em vez de rejeitá-las. Esse comportamento pode levar a problemas de integridade de dados e à evasão de validação de entrada, caso tal validação ocorra antes da serialização. Exemplos técnicos incluem a substituição de bytes de continuação inválidos por válidos, a conclusão de sequências não terminadas ou a leitura além do final de uma string.

Ocorre um comportamento incorreto no Views ao processar solicitações TCP PROXY.

Ocorre um vazamento de memória quando a função `ujson.dump()` escreve em um objeto do tipo arquivo e a operação de escrita gera uma exceção. A função `objToJSONFile()` aloca um objeto de string Python, mas falha ao chamar `Py DECREF(string)` no caminho de saída antecipada durante uma falha de escrita, fazendo com que o tamanho total do payload serializado seja vazado. Isso pode levar ao crescimento linear da memória se um aplicativo serializar dados para um objeto do tipo arquivo influenciado por um invasor que possa falhar, potencialmente esgotando a memória de um servidor web.

Existe uma falha de bypass de autenticação no middleware ForwardAuth do Traefik, um proxy reverso HTTP e balanceador de carga. Isso ocorre quando `trustForwardHeader` está configurado como `false` e o software está implantado atrás de um proxy upstream confiável.

O software falha ao limpar o dicionário `CachedTemplates` quando a função `TemplateContext.Reset()` é chamada, permitindo que modelos em cache persistam entre contextos reutilizados. Isso pode ser explorado por meio de implementações `ITemplateLoader` dependentes de requisição, permitindo o acesso não autorizado ao conteúdo de modelos de renderizações anteriores sem disparar a função `TemplateLoader.Load()` novamente.

O software falha ao aplicar a restrição `LoopLimit` a iterações dispendiosas realizadas dentro de operadores e funções integradas, aplicando-a apenas a instruções de loop de script. Isso permite que uma única expressão cause consumo excessivo de CPU ou memória, resultando em negação de serviço. Isso ocorre em aplicações que renderizam templates controlados por um invasor e dependem do `LoopLimit` para a execução segura.

O Scriban armazena o TypedObjectAccessor em cache baseando-se apenas no tipo, ignorando alterações feitas no MemberFilter. Esse comportamento permite que instâncias reutilizadas de TemplateContext exponham membros que deveriam estar ocultos. Um invasor pode ignorar políticas de sandbox entre diferentes requisições ou inquilinos ao reutilizar um TemplateContext após o seu MemberFilter ter sido restringido, obtendo assim acesso a propriedades e campos filtrados.

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.

Um usuário com privilégios baixos pode contornar a autorização e o isolamento entre inquilinos no OneUptime enviando um cabeçalho `is-multi-tenant-query` falsificado junto com um cabeçalho `projectid` controlado. O servidor confia incorretamente neste cabeçalho fornecido pelo cliente, ignorando as verificações internas de permissão em `BasePermission` e desativando o escopo de inquilino. Isso permite que atacantes acessem dados de projetos pertencentes a outros inquilinos, leiam campos sensíveis do Usuário (incluindo `password`, `resetPasswordToken` e `webauthnChallenge`) por meio de relações aninhadas, vazem o `resetPasswordToken` em texto plano e, por fim, redefinam a senha da vítima, levando à tomada total da conta. A vulnerabilidade decorre do sistema confiar em um cabeçalho controlado pelo cliente para determinar se deve contornar as verificações de autorização. A relação `createdByUser` dentro do modelo Project permite acesso a dados sensíveis do usuário quando as verificações de permissão de seleção são contornadas. O token de redefinição é armazenado em texto plano no banco de dados e pode ser usado para redefinir a senha da vítima.

Existe uma vulnerabilidade de elevação de privilégio no serviço de publicação do SiYuan Note. Uma conta de publicação com baixo privilégio (RoleReader) pode modificar o conteúdo do caderno por meio do endpoint da API `/api/block/appendHeadingChildren`. O endpoint requer apenas a função `model.CheckAuth`, que aceita sessões RoleReader, mas não aplica verificações mais rigorosas, como `CheckAdminRole` ou `CheckReadonly`. Isso permite que um usuário de publicação com privilégios somente leitura adicione novos blocos a documentos existentes, potencialmente comprometendo a integridade das notas armazenadas. A vulnerabilidade decorre de verificações insuficientes de autorização baseadas em funções em operações de escrita, que são protegidas apenas por `CheckAuth`. O código vulnerável está localizado em `router.go`, `api/block.go`, `model/block.go` e `model/session.go`. O endpoint da API `/api/block/appendHeadingChildren` é central para o problema. Os parâmetros `id` e `childrenDOM` são os vulneráveis utilizados na solicitação.

Existe uma vulnerabilidade de travessia de caminho no endpoint `/export`, permitindo que um atacante leia arquivos arbitrários do sistema de arquivos do servidor. A exploração envolve o uso de sequências de travessia duplamente codificadas para acessar arquivos sensíveis como `conf/conf.json`, que contém segredos, incluindo o token da API, a chave de assinatura de cookies e o código de autenticação de acesso ao workspace. O vazamento desses segredos poderia conceder acesso administrativo à API do kernel do SiYuan e, em alguns casos, possivelmente levar à execução remota de código (RCE). O código vulnerável está localizado em `serve.go` (linhas 303, 315, 320, 340, 955-957) e `session.go` (linhas 292-295). A vulnerabilidade decorre da confiança na saída de `url.PathUnescape` e da junção sem garantir que o caminho resultante permaneça dentro do `exportBaseDir`. O uso de sequências de travessia duplamente codificadas (`%252e%252e`) contorna a rejeição de URL com pontos duplos, enquanto o `CheckAuth` concede acesso administrativo para requisições do localhost ao `/export/*` quando o código de autenticação de acesso está configurado. Uma configuração CORS global (`Access-Control-Allow-Origin: *`) permite que páginas web maliciosas leiam respostas do localhost. Um atacante pode enviar uma requisição GET para `/export/%252e%252e/%252e%252e/conf/conf.json` para recuperar informações sensíveis.

O OliveTin permite o acesso a comandos shell predefinidos por meio de uma interface web. Existe uma falha na funcionalidade RestartAction onde um usuário autenticado com baixos privilégios pode executar ações que não tem permissão para executar. Isso ocorre porque o RestartAction cria uma nova solicitação interna sem preservar a autenticação do chamador original, fazendo com que o resolvedor de autenticação recorra ao usuário convidado. Se a conta convidado tiver permissões mais amplas do que o usuário autenticado, isso resulta em escalonamento de privilégios e execução não autorizada de comandos. O problema decorre da construção de um novo connect.Request dentro do RestartAction, que omite os cabeçalhos de autenticação e cookies do chamador original. Isso permite que um usuário contorne Listas de Controle de Acesso (ACL) e execute ações shell configuradas arbitrárias. Os arquivos vulneráveis incluem service/internal/api/api.go e service/internal/auth/authcheck.go. A função `StartAction` e a função `UserFromApiCall()` estão envolvidas no processo de autenticação. Uma prova de conceito demonstra que um usuário com baixos privilégios pode executar comandos utilizando o endpoint RestartAction e um ID de rastreamento de execução. Isso pode levar à gravação arbitrária de arquivos, exposição de dados sensíveis e potencial comprometimento total do host, dependendo dos privilégios de tempo de execução do OliveTin.

O OliveTin não invalida corretamente as sessões do lado do servidor após o logout do usuário. Embora o cookie do navegador seja limpo durante o logout, a sessão correspondente permanece válida no armazenamento do servidor até sua expiração natural, que por padrão é de aproximadamente um ano. Um atacante que possua um cookie de sessão previamente roubado ou capturado pode continuar a se autenticar após o usuário ter feito logout, resultando em um bypass de autenticação pós-logout. Esta é uma falha de gerenciamento de sessão que viola a semântica de logout esperada. O problema decorre da falha em excluir o identificador de sessão (SID) do armazenamento do lado do servidor durante o processo de logout. Especificamente, os arquivos `api.go`, `sessions.go` e `local.go`, linhas 392-427, 39-59, 61-80 e 32-47, respectivamente, estão envolvidos no gerenciamento de sessão defeituoso. A vulnerabilidade permite que um atacante faça replay de um SID antigo após o logout para manter a autenticação. Os **endpoints da API** afetados são `/api/Logout` e `/api/WhoAmI`. A variável vulnerável é `sid`.

O OliveTin permite o acesso a comandos shell predefinidos a partir de uma interface web. Quando a autenticação JWT é configurada usando uma chave pública RSA local (`authJwtPubKeyPath`) ou um segredo HMAC (`authJwtHmacSecret`), o valor de audiência configurado (`authJwtAud`) não é imposto durante a análise do token. Isso permite a autenticação utilizando tokens JWT destinados a uma audiência ou serviço diferente. O problema reside no arquivo `jwt.go`, especificamente nas linhas 51–59, 144–157 e 161–168. No Modo de Chave Pública Local e no Modo HMAC, a opção `jwt.WithAudience()` não é fornecida, levando ao bypass da validação de audiência. Um atacante que possua um JWT válido assinado com a chave configurada, mas destinado a uma audiência diferente, pode autenticar-se com sucesso. Isso permite a reutilização de tokens entre serviços, autenticação usando tokens emitidos para outros sistemas e violação de limite de confiança em ambientes de múltiplos serviços. O endpoint da API `'/api/WhoAmI'` é afetado, e o cabeçalho `Authorization` é usado para passar o token JWT. Os parâmetros vulneráveis incluem a claim `aud` dentro do token JWT. Esta é estritamente uma falha de validação de autenticação e não contorna a autorização ACL.

O OliveTin possui um problema de autorização no qual usuários autenticados com permissões insuficientes (view: false) podem acessar metadados relacionados a ações através do dashboard e **endpoints da API**. Especificamente, o backend não impõe corretamente as permissões de visualização ao gerar respostas para informações do dashboard e de vinculação de ações. Isso permite que usuários restritos recuperem detalhes como títulos de ações, IDs, ícones e metadados de argumentos, mesmo que não estejam autorizados a executar essas ações. Os **endpoints da API** vulneráveis incluem '/api/GetDashboard' e '/api/GetActionBinding'. O parâmetro vulnerável é `bindingId` no endpoint '/api/GetActionBinding'. O problema decorre de uma falha ao impor a função `IsAllowedView()` ao construir essas respostas.