Maru1009

O plugin Nostr Wallet Connect contém uma falha que permite que clientes maliciosos ignorem os limites de gastos. Isso é feito explorando verificações de orçamento não atômicas e a truncagem de millisatoshi. Atacantes podem enviar solicitações `pay invoice` simultâneas que passam pela verificação `budget allows spend()` antes que a função `add to budget()` seja executada. Além disso, atacantes podem pagar repetidamente quantias em millisatoshi (msat) que são arredondadas para satoshis inteiros para drenar fundos além da variável `daily limit sat`.

Uma correção incompleta para a sanitização de `Error.cause` permite a evasão do sandbox quando objetos `AggregateError` envolvidos pelo host e revisitados são capturados dentro de uma única travessia de manipulador de exceção. Atacantes podem explorar a falha de detecção de ciclo na função `handleException()` para acessar proxies de host não sanitizados incorporados no array `errors`, permitindo a execução remota de código e a divulgação de informações do processo a partir do sandbox.

Um atacante remoto e não autenticado pode causar corrupção de memória no caminho de atualização de WebSocket do servidor HTTP. O problema ocorre porque o analisador de cabeçalho HTTP/1 utiliza uma cópia limitada para mover o cabeçalho `Sec-WebSocket-Key` para um buffer de tamanho fixo sem garantir a terminação NUL quando o comprimento da entrada atinge o tamanho do buffer. Durante o processo de atualização, esse buffer é copiado para um buffer de pilha local e processado pela função `strlen()`. Se nenhum terminador NUL estiver presente, a função `strlen()` lê além do buffer da pilha, e a concatenação subsequente com a string mágica do WebSocket resulta em uma gravação fora dos limites. Isso leva a operações de leitura e gravação fora dos limites na memória da pilha, o que pode causar a falha do sistema (negação de serviço) ou potencialmente permitir a execução de código arbitrário. Este caminho está acessível quando a configuração `CONFIG HTTP SERVER WEBSOCKET` está habilitada.

O Concrete CMS não valida um token Cross-Site Request Forgery (CSRF)—um valor único usado para evitar que comandos não autorizados sejam transmitidos de um usuário em quem a aplicação web confia—antes de processar solicitações para o endpoint '/dashboard/extend/update/prepare remote upgrade/<remoteMPID>'. Um invasor que controle o pacote remoto retornado para um ID de item de marketplace conhecido pode sobrescrever o PHP do pacote no disco e forçar a execução da função `upgrade()` através de uma única navegação no navegador. Isso resulta na execução remota de código como o usuário do servidor web. Para que isso ocorra, a vítima deve possuir permissões `canInstallPackages`, o site deve estar conectado ao marketplace do Concrete e o invasor deve controlar o pacote retornado para um ID de item de marketplace já instalado no site da vítima.

O Concrete CMS não valida um token Cross-Site Request Forgery (CSRF)—um identificador único usado para evitar que comandos não autorizados sejam transmitidos de um usuário em quem a aplicação web confia—antes de processar solicitações para o endpoint '/dashboard/extend/update/do update/<pkgHandle>'. A função `do update()` em 'concrete/controllers/single page/dashboard/extend/update.php' verifica apenas a condição `canInstallPackages()` antes de executar `upgradeCoreData()` e `upgrade()` no controlador do pacote especificado. Como este endpoint é uma rota GET de alteração de estado sem imposição de token, um invasor pode enganar um administrador autenticado para disparar a atualização de um pacote por meio de navegação cross-site, desde que o administrador passe na verificação `canInstallPackages()` e o pacote alvo já esteja instalado.

O Concrete CMS não valida um token Cross-Site Request Forgery (CSRF)—um identificador único usado para evitar que comandos não autorizados sejam transmitidos de um usuário em quem a aplicação web confia—antes de processar solicitações para o endpoint '/dashboard/extend/install/download/<remoteId>'. A função `download()` em 'concrete/controllers/single page/dashboard/extend/install.php' verifica apenas a permissão `canInstallPackages()` antes de buscar um pacote remoto do marketplace e salvá-lo no diretório `DIR PACKAGES` do servidor. Como este endpoint é uma rota GET de alteração de estado sem a aplicação de tokens, um invasor pode enganar um administrador autenticado para visitar uma página maliciosa e forçar o download de um pacote arbitrário do marketplace. Para que isso ocorra, o administrador deve possuir a permissão `canInstallPackages()` e o site deve estar conectado ao marketplace do Concrete.

Um problema de Cross-Site Request Forgery (CSRF) existe no método `install package()` do endpoint 'concrete/controllers/single page/dashboard/extend/install.php'. Um invasor pode forçar um administrador autenticado com permissões `canInstallPackages` a instalar um pacote, caso o invasor já tenha colocado um pacote em `DIR PACKAGES/<handle>/`. Como o processo de instalação executa o método `install()` do controlador do pacote como o usuário do servidor web, isso pode levar à execução remota de código.

Existe uma falha de bypass na validação do token Cross-Site Request Forgery (CSRF) onde a view `local available update.php` emite um token via `$token->output('do update')`, mas a função `do update()` em `concrete/controllers/single page/dashboard/system/update/update.php` não chama `$this->token->validate('do update')`. Embora o formulário seja renderizado como um formulário POST, o controlador descarta o token sem verificação. Isso permite que um invasor crie uma requisição POST cross-site para disparar uma atualização do núcleo do CMS para uma string de versão especificada pelo invasor. Para que isso ocorra, a vítima deve passar por `canUpgrade()` e uma versão de atualização válida deve estar presente em `DIR CORE UPDATES`.

Nome do Software Vulnerável e Versões Afetadas SillyTavern versões anteriores a 1.17.0 Descrição Uma vulnerabilidade de path traversal existe no endpoint da API `/api/chats/import`. Um invasor autenticado pode gravar arquivos em locais fora do diretório de chats pretendido injetando sequências de traversal no parâmetro `character name`. O parâmetro `character name` é usado sem a devida sanitização ao construir o nome do arquivo de destino. Isso permite que um invasor escape da estrutura de diretórios pretendida e grave arquivos em locais arbitrários, como `/tmp/...`, levando potencialmente a problemas de integridade e disponibilidade. Recomendações Atualize para a versão 1.17.0 ou posterior do SillyTavern.

Nome do Software Vulnerável e Versões Afetadas SillyTavern versões anteriores a 1.17.0 Descrição Uma vulnerabilidade de travessia de caminho existe nos endpoints de chat do SillyTavern. Um invasor autenticado pode ler e excluir arquivos arbitrários sob o diretório de dados do usuário, como `secrets.json` e `settings.json`, manipulando o parâmetro `avatar url` com um valor de "..". O validador de entrada para `avatar url` bloqueia inadequadamente segmentos de travessia como `..`, permitindo a construção de caminhos de arquivo maliciosos. Os endpoints vulneráveis incluem os caminhos de exportação e exclusão. Isso permite acesso direto a arquivos fora do diretório de chats pretendido. A exploração bem-sucedida pode levar à exposição de dados confidenciais do usuário e à exclusão de arquivos críticos, potencialmente interrompendo a operação da conta. Recomendações Atualize para a versão 1.17.0 ou posterior do SillyTavern.

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.

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.

Os Monitores Sintéticos do OneUptime permitem que um usuário autenticado com privilégios limitados do projeto execute comandos arbitrários no servidor/contêiner `oneuptime-probe`. A causa raiz é que código não confiável do Monitor Sintético é executado dentro do `vm` do Node, enquanto objetos `browser` e `page` do Playwright no ambiente host são expostos a ele. Um usuário malicioso pode chamar APIs do Playwright no objeto `browser` injetado e fazer com que o probe inicie um executável controlado pelo atacante. Trata-se de uma vulnerabilidade de execução remota de código no lado do servidor que não requer um escape adicional do sandbox `vm`. O probe utiliza a versão 1.58.2 do Playwright, o que permite a exploração por meio da função `BrowserType.launch()` com parâmetros controlados pelo atacante, como `executablePath` e `args`. A vulnerabilidade pode ser explorada tanto por meio de testes pontuais de monitor quanto pela execução normal de monitor agendado.

O callback do GitHub App do OneUptime não valida adequadamente os valores `state` e `installation id` recebidos de um usuário, permitindo que um atacante sobrescreva a vinculação da instalação do GitHub App de outro projeto. O callback decodifica o JSON codificado em base64 do parâmetro `state` e usa diretamente o `projectId` embutido. Em seguida, atualiza o `Project.gitHubAppInstallationId` com `isRoot: true` sem verificar a autorização do chamador para o projeto de destino. Os endpoints do GitHub relacionados também não possuem autorização eficaz, permitindo que um ID de instalação válido seja usado para enumerar repositórios e criar registros `CodeRepository` em um projeto arbitrário. Os endpoints da API vulneráveis incluem: `/api/github/auth/callback`, `/api/github/repositories` e `/api/github/connect`. Os parâmetros `state` e `installation id` são vulneráveis.

Os Monitores Sintéticos do OneUptime permitem que usuários de projeto com baixos privilégios enviem código Playwright personalizado que é executado no serviço `oneuptime-probe`. Este código é executado dentro do `vm` do Node e recebe objetos Playwright do host ativos, como `browser` e `page`. Isso permite que um atacante use o objeto `browser` injetado para executar código arbitrário no host/container da sonda via `browser.browserType().launch(...)`. O problema origina-se da exposição de capacidades perigosas do host a código não confiável, em vez de depender de evasões de sandbox tradicionais. Isso pode ser explorado através do recurso `Test Monitor` ou criando um Monitor Sintético malicioso, levando à Execução Remota de Código (RCE) no lado do servidor. O `customCode` é passado para `SyntheticMonitor.execute(...)` e então executado através de `VMRunner.runCodeInNodeVM(...)`, o que cria um contexto Node `vm` e expõe objetos do host. O wrapper de proxy não bloqueia suficientemente os nomes das propriedades, permitindo que métodos legítimos do Playwright sejam chamados com a vinculação `this` real do host.

O Vito é um aplicativo web auto-hospedado utilizado para gerenciar servidores e implantar aplicações PHP. Uma falta de verificação de autorização nas ações de criação de sites nos fluxos de trabalho permite que um atacante autenticado com acesso de escrita ao fluxo de trabalho em um projeto crie e gerencie sites em servidores pertencentes a outros projetos ao fornecer um `server id` externo. O problema afeta as ações de criação de sites nos fluxos de trabalho.

O SiYuan, um sistema de gerenciamento de conhecimento pessoal, contém uma vulnerabilidade de cross-site scripting (XSS) refletido no endpoint da API de ícones dinâmicos. A vulnerabilidade ocorre quando o parâmetro `type` é definido como 8, permitindo que conteúdo controlado pelo atacante seja incorporado à saída SVG sem o devido escapamento. Como o endpoint da API ''GET /api/icon/getDynamicIcon'' não requer autenticação e retorna image/svg+xml, uma URL manipulada pode injetar manipuladores de eventos SVG/HTML executáveis, como `onerror`, e executar JavaScript dentro da origem web do SiYuan. Isso pode potencialmente levar à execução de ações de API autenticadas e à exfiltração de dados sensíveis se um usuário logado abrir o link malicioso. O problema decorre da construção insegura de saída e sanitização incompleta, especificamente a injeção direta da variável `content` em elementos SVG sem o escapamento XML/HTML adequado. O sanitizador existente apenas remove tags `<script>`, mas não aborda atributos perigosos ou elementos inseguros.

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.