0Xbassia

Ocorre Cross-Site Scripting (XSS) Refletido quando o plugin não escapa a URL da página atual antes de exibi-la em um contexto JavaScript em uma de suas páginas de administração. Isso permite que um invasor execute scripts maliciosos no navegador de usuários com altos privilégios.

Um problema de Server-Side Request Forgery (SSRF) existe no recurso de webhooks. Isso permite que usuários da equipe façam a sondagem de hosts internos a partir do servidor Ghost. SSRF é uma falha que permite que um invasor induza a aplicação do lado do servidor a fazer requisições para um local não pretendido.

Um problema de server-side request forgery (SSRF) existe no recurso de webhooks. Isso permite que usuários com privilégios de equipe criem requisições que possibilitam ao servidor Ghost sondar e acessar recursos de rede interna.

O plugin falha ao validar adequadamente arquivos carregados, confiando no tipo de conteúdo fornecido pelo cliente e preservando o nome original do arquivo. Isso permite que atacantes não autenticados carreguem arquivos PHP arbitrários e executem código no servidor.

O plugin não realiza verificações de capacidade, propriedade ou nonce antes de atualizar os metadados dos itens de pedido do WooCommerce. Isso permite que qualquer usuário autenticado, incluindo aqueles com nível de acesso de assinante, altere os metadados personalizados de pedidos pertencentes a outros clientes. O problema decorre de uma verificação de capacidade ausente em uma função.

O plugin não verifica a senha do usuário durante o processo de autenticação. Isso permite que invasores não autenticados façam login como qualquer usuário registrado, incluindo aqueles com privilégios de administrador, fornecendo apenas o endereço de e-mail do usuário, resultando em escalonamento de privilégios.

O plugin não realiza verificações de autorização ou propriedade antes de retornar metadados de pedidos do WooCommerce e as URLs de anexos carregados por clientes. Isso permite que invasores não autenticados divulguem dados sensíveis de pedidos e anexos de outros clientes.

O plugin não verifica a senha antes de emitir uma sessão autenticada para um endereço de e-mail fornecido em uma ação não autenticada. Isso permite que invasores não autenticados façam login como qualquer usuário registrado, incluindo administradores, ou criem novas contas arbitrárias, resultando em escalonamento de privilégios.

A sanitização insuficiente de entrada e a falta de escape de saída permitem que usuários autenticados, incluindo aqueles com nível de acesso de assinante, realizem Cross-Site Scripting (XSS) Armazenado. O plugin não realiza verificações de capacidade, propriedade ou nonce antes de salvar a configuração do popup em um produto. Isso permite que um invasor armazene JavaScript que é executado no navegador de visitantes que visualizam o produto afetado.

O plugin não mantém a confidencialidade do código de login de uso único. Ele retorna o código e um token de verificação válido na resposta de uma ação não autenticada. Isso permite que invasores não autenticados façam login como qualquer usuário, incluindo administradores, desde que conheçam o número de celular registrado, ou criem contas arbitrárias.

Um endpoint de proxy de mídia não autenticado não valida o destino das requisições do lado do servidor. Isso permite que usuários anônimos forcem o site a buscar URLs arbitrárias, incluindo endereços internos e de redes privadas, e leiam o corpo da resposta. Este problema resulta em um Server-Side Request Forgery (SSRF) de leitura completa, onde o servidor é coagido a fazer requisições para um local não pretendido, e cria um proxy aberto.

Um endpoint de informações do site não autenticado não valida o destino de requisições do lado do servidor. Isso permite que usuários anônimos realizem Server-Side Request Forgery (SSRF), uma técnica onde um invasor induz uma aplicação do lado do servidor a fazer requisições para um local não pretendido. Ao utilizar um nonce de controle exposto em páginas públicas, invasores podem forçar o site a solicitar URLs internas e de redes privadas e recuperar os metadados da página analisada.

O plugin não verifica as capacidades do usuário em seus manipuladores de upload de arquivos AJAX no frontend e não valida o conteúdo real dos arquivos carregados em relação ao tipo de mídia pretendido do endpoint. Isso permite que usuários não autenticados façam o upload de qualquer tipo de arquivo aceito pela biblioteca de mídia do WordPress por meio de endpoints que deveriam aceitar apenas imagens ou vídeos.

Endpoints de visualização pública compartilhada expõem valores de colunas que o proprietário da visualização havia ocultado por meio de três caminhos independentes. Primeiro, a função `groupBy` retorna valores brutos para qualquer coluna nomeada na solicitação. Segundo, matrizes de filtro e classificação operam em colunas ocultas, permitindo a extração boolean-blind (uma técnica usada para inferir dados observando a resposta da aplicação a consultas verdadeiras ou falsas). Terceiro, a lista de dados relacionados aceita IDs de colunas de link arbitrários de outras tabelas na mesma base. Isso permite que qualquer pessoa com um UUID de visualização compartilhada enumere valores de colunas ocultas, confirme valores de colunas ocultas observando a contagem de linhas ou leia registros de tabelas não relacionadas na mesma base sem autenticação.

O plugin MagicForm para WordPress não valida adequadamente os tipos de arquivos carregados por meio de uma ação AJAX não autenticada. Isso ocorre quando a lista de permissões de extensões por campo de um formulário é deixada vazia, permitindo que invasores não autenticados carreguem arquivos PHP e executem código arbitrário no servidor.

O software não filtra ` proto `, `constructor` ou `prototype` ao converter FormData em objetos usando chaves de formulário com notação de colchetes. Um invasor pode enviar um único campo de formulário HTTP com um nome começando com ` proto [...]` para mutar o `Object.prototype`, resultando em poluição de protótipo (prototype pollution) em todo o processo Node.js. Isso ocorre dentro das funções `treatInitial()` e `treatSecond()` no arquivo `index.cjs`. Este problema pode ser explorado para burlar verificações de segurança, injetar valores de configuração, interromper a renderização de templates ou causar a negação de serviço ao travar o processo do worker.

A função `parseFormData()` processa nomes de campos FormData em notação de colchetes e pontos para objetos aninhados sem filtrar chaves de propriedades reservadas. Um invasor pode usar um nome de campo FormData que comece com ` proto ` ou contenha `. proto .` no meio do caminho para fazer com que o analisador percorra o `Object.prototype` e atribua propriedades a ele. Isso resulta em poluição de protótipo (prototype pollution), onde a cadeia de protótipos de cada objeto simples no processo em execução é contaminada. O problema reside na função `handlePathPart()` em `src/index.ts`, que não rejeita chaves reservadas durante o processamento de segmentos de caminho do tipo objeto. Isso pode levar à corrupção do estado da aplicação, alteração do fluxo de controle ou negação de serviço em aplicações que processam FormData controlado por invasores, como servidores HTTP.

A poluição de protótipo ocorre quando os caminhos de propriedade contêm ` proto `, `constructor` ou `prototype`. Este problema surge quando os caminhos de propriedade são expostos como entrada do usuário, permitindo que um invasor modifique o protótipo de classes de objetos base.

A função `setPath` no `@rvf/set-get` (utilizada pelo `@rvf/core` para achatar dados de formulários recebidos em um objeto aninhado) não bloqueia as chaves ` proto `, `constructor` ou `prototype` ao percorrer um caminho. Como os nomes dos campos nos dados de formulários enviados são passados diretamente para `setPath` via `preprocessFormData` (e através de `parseFormData` ou `validate`), um invasor pode definir propriedades arbitrárias no `Object.prototype` do processo do servidor em execução. Trata-se de uma primitiva de poluição de protótipo (prototype pollution)—uma condição onde um invasor pode manipular o protótipo de objetos base para alterar o comportamento da aplicação—que é acessível por padrão, sem a necessidade de configuração especial. Qualquer endpoint que aceite um formulário via `parseFormData` ou execute um validador criado com `createValidator()` é afetado. Isso pode levar ao bypass de verificações de segurança, injeção de valores de configuração não pretendidos, falhas na renderização de templates ou a interrupção do processo do worker (DoS).