Pavelkohout396

Um problema de SQL injection existe na interface de administração do Mautic no endpoint '/s/ajax'. O problema ocorre porque um parâmetro de requisição usado para selecionar o campo de contato para pesquisa não é devidamente validado antes de ser incluído em uma consulta ao banco de dados. Qualquer usuário autenticado, independentemente de sua função ou permissões atribuídas, pode explorar isso usando técnicas cegas—como métodos baseados em booleano ou tempo—para executar consultas SQL arbitrárias. Isso permite que o invasor leia informações sensíveis do banco de dados, incluindo contas de usuário, endereços de e-mail, hashes de senha, dados de contato e conteúdo de campanhas.

Um problema de SQL Injection existe no endpoint da API de dados do widget do painel '/api/data/{type}'. Isso ocorre porque os parâmetros de filtro de gráfico fornecidos pelo cliente não são devidamente validados antes de serem usados em consultas ao banco de dados que geram dados de gráficos do painel. Um usuário autenticado com acesso à API pode usar blind SQL injection—uma técnica usada para recuperar dados de um banco de dados fazendo perguntas de verdadeiro/falso—para ler informações arbitrárias do banco de dados, incluindo detalhes de contato, dados de marketing e hashes de senha de contas de usuário. Além disso, o SQL injetado pode ser usado para desacelerar as consultas, impactando potencialmente a disponibilidade. A modificação de dados não é possível, e a exploração requer que a API do Mautic esteja habilitada.

Um problema de path traversal existe na API de Ativos do Mautic. Um usuário da API autenticado com permissões para criar ativos pode especificar um caminho de arquivo que não é restrito ao diretório de upload de ativos. Isso permite o registro de qualquer arquivo legível pelo processo do servidor web como um ativo do Mautic. Uma vez publicado, a URL de download público fornece o conteúdo do arquivo sem autenticação, permitindo a recuperação de arquivos arbitrários do servidor, como arquivos do sistema e arquivos de configuração contendo chaves secretas, senhas de banco de dados e credenciais SMTP.

Existe um problema na Shop API pública onde as consultas de produtos, coleções e facetas combinam guardas de visibilidade obrigatórias com filtros fornecidos pelo chamador usando um `filterOperator` controlado pelo chamador. Quando o `filterOperator` é definido como OR, as guardas de visibilidade para `Product.enabled`, `Collection.isPrivate` e `Facet.isPrivate` podem ser ignoradas. Isso permite que um chamador não autenticado recupere produtos desativados e coleções ou facetas privadas ao fornecer um predicado que corresponda a essas entidades ocultas.

Existe uma falha de bypass de autorização no componente de importação Livewire (`AppLivewireImporter`), montado na rota `imports.index`. O componente verifica a permissão geral de `import` apenas no momento da montagem, enquanto as propriedades computadas `files()` e `activeFile()` consultam a tabela de importações sem restringir os resultados por proprietário ou empresa. Consequentemente, qualquer usuário autenticado que não seja superusuário e possua a permissão de importação pode visualizar todos os registros de importação na instância, incluindo nomes de arquivos originais, caminhos de arquivos, tamanhos de arquivos, tipos de importação e carimbos de data/hora de criação. Além disso, um invasor pode usar a ação Livewire `selectFile($id)` com um ID de Importação auto-incrementado para acessar o registro de outro usuário, expondo dados de visualização, como o `header row` e o `first row` do CSV. Isso pode levar à divulgação de informações sensíveis, como dados pessoais, números de série de ativos e chaves de licença, podendo ultrapassar limites de empresa ou locatário em implantações com Suporte Completo a Múltiplas Empresas (FMCS). O impacto limita-se aos dados de visualização e não afeta superusuários.

O controle de acesso insuficiente permite que usuários autenticados com as permissões `assets.edit`, `assets.checkin`, `assets.checkout` ou `assets.audit` leiam valores de campos personalizados criptografados em texto simples. Isso ocorre ao abrir formulários de ativos para elementos de listbox, textarea, markdown-textarea e seletores de data/hora, ignorando a verificação de permissão `assets.view.encrypted custom fields`.

Usuários autenticados com apenas a permissão `licenses.view` podem acessar chaves de produto porque o software falha ao aplicar corretamente a trava de autorização `viewKeys`. Isso permite que atacantes baixem todas as chaves de licença em massa via exportação de CSV ou validem chaves candidatas por meio de discrepâncias na resposta da API. O problema afeta os endpoints de exportação de CSV e de índice da API.

Existe uma falha de autorização no endpoint 'POST /hardware/history', que permite que qualquer usuário autenticado reatribua ativos arbitrários e modifique logs de auditoria. Ao enviar um arquivo CSV, um invasor pode reatribuir ativos entre diferentes empresas e injetar entradas fraudulentas no rastro de auditoria, comprometendo a integridade e a responsabilidade do inventário.

Um problema de cross-site scripting armazenado existe onde a função `convertOldInternalLinks()` em `FaqHelper` chama `html entity decode()` em conteúdo de FAQ sanitizado. Este processo reverte a proteção de codificação de entidades, permitindo que usuários autenticados com privilégios de edição de FAQ injetem payloads de JavaScript. Esses payloads são executados nos navegadores de todos os usuários que visualizam as páginas de FAQ afetadas.

Existe uma falha de bypass de autorização no processo de criação de perguntas. A função `isAddingQuestionsAllowed()` concede acesso a todos os usuários quando a configuração `main.enableAskQuestions` está ativa, ignorando a configuração `records.allowQuestionsForGuests`. Isso permite que usuários não autenticados enviem perguntas através do endpoint de API 'question/create', ignorando as restrições para convidados para injetar spam na fila de moderação do administrador.

Existe uma falha de bypass de autenticação na função `AuthLdap::create()`. Quando a autenticação LDAP está habilitada, um bind LDAP bem-sucedido aciona a função `User::setStatus('active')` incondicionalmente. Esta ação sobrescreve a coluna `account status` de uma conta local existente, alterando-a de 'blocked' para 'active'. Consequentemente, usuários com contas locais administrativamente bloqueadas podem restaurar o acesso e fazer login via LDAP. Esta transição de estado não é registrada nos logs, impedindo que os administradores detectem a anulação do bloqueio.

Existe uma falha de bypass de autenticação de dois fatores (2FA) porque os tokens remember-me são emitidos antes da conclusão do processo de verificação 2FA. Um invasor com credenciais válidas pode obter um cookie remember-me para pular o desafio 2FA e reproduzir esse cookie para obter acesso autenticado total ao sistema sem fornecer a verificação de segundo fator.

Um problema de Cross-Site Scripting (XSS) armazenado existe no componente de seleção de projetos. A aplicação falha ao sanitizar nomes de projetos retornados via AJAX antes de injetá-los no Document Object Model (DOM) como campos de opção. Um usuário autenticado com permissões de criação de projetos pode armazenar um payload de script malicioso no nome de um projeto. Quando um usuário administrativo abre um editor de entidade contendo o seletor de projetos, o script é executado em sua sessão de navegador, podendo levar ao sequestro de sessão, coordenação de estado não autorizada ou acesso não autorizado a dados organizacionais.

Existe uma falha de bypass de autorização nos endpoints da API v2 (utilizando API Platform). Funções configuradas com restrições de escopo de proprietário, como `viewown` ou `editown`, não são aplicadas corretamente. Isso permite que usuários autenticados da API com baixos privilégios ignorem os controles de lógica de propriedade para acessar ou modificar recursos de outros usuários, incluindo relatórios, contatos e empresas, ignorando as fronteiras estruturais de locatário e privilégios.

OpenEMR is an electronic health records and medical practice management application. A flaw exists where an authenticated, non-administrator user can view reminder messages belonging to other users. This is achieved by manipulating the `sentTo[]` or `sentBy[]` parameters in a GET request to the dated reminders log. The issue allows access to patient names and the content of free-text messages.

OpenEMR is an electronic health records and medical practice management application. A DOM-based stored cross-site scripting issue exists in the jQuery SearchHighlight plugin (`library/js/SearchHighlight.js`). An authenticated user with encounter form write access can inject arbitrary JavaScript that executes in another clinician's browser session when using the search/find feature on the Custom Report page. The plugin reverses server-side HTML entity encoding by reading decoded text from DOM text nodes, concatenating it into a raw HTML string, and passing it to jQuery's `$()` constructor for HTML parsing.

OpenEMR is a free and open source electronic health records and medical practice management application. A stored cross-site scripting (XSS) issue exists in the patient portal payment flow. This allows a patient portal user to inject arbitrary JavaScript code that will be executed in the browser of a staff member reviewing the payment submission. The malicious payload is stored in `portal/lib/paylib.php` and rendered without proper sanitization in `portal/portal payment.php`.

OpenEMR is an electronic health records and medical practice management application. A flaw exists where an authorization bypass in the optional FaxSMS module (`oe-module-faxsms`) allows authenticated users to invoke controller methods, including `getNotificationLog()`, without proper access control checks. The `AppDispatch` constructor bypasses ACL enforcement, potentially exposing patient appointment data (PHI).

OpenEMR is a free and open source electronic health records and medical practice management application. The application is susceptible to a stored cross-site scripting (XSS) issue. This occurs due to unescaped `portal login username` within the portal credential print view. A patient portal user can inject an XSS payload as their login username, which then executes in a clinic staff member's browser when the "Create Portal Login" page is accessed for that patient. This allows for a transition from the patient session context to the staff/admin session context.

OpenEMR is an electronic health records and medical practice management application. Prior to version 8.0.0.1, sensitivity checks for group encounters were not functioning correctly. The code was only checking the `form encounter` table for sensitivity information, while group encounters actually store this information in the `form groups encounter` table. This resulted in sensitivity restrictions not being applied to group encounters, potentially allowing unauthorized users to view sensitive information, such as mental health records.