Snipe

O software falha ao verificar o valor de retorno da função `ldap start tls()` dentro da função `connectToLdap()`. Isso permite que um invasor on-path force binds LDAP em texto claro ao responder à solicitação StartTLS com um erro de protocolo, permitindo a captura de credenciais de conta de serviço e senhas de login de usuários finais.

Um problema de replay de asserção SAML existe devido a uma verificação de nonce não atômica no manipulador SAML acs. Isso permite que atacantes reutilizem asserções capturadas enviando requisições POST simultâneas para o endpoint '/saml/acs'. Ao fazer isso, eles podem obter múltiplas sessões de vítimas autenticadas que ignoram a revogação imposta pelo Provedor de Identidade (IdP).

Existe um problema na função `ApiAssetsController::store` onde texto simples é gravado em colunas de campos personalizados marcadas para criptografia quando o chamador não possui a permissão `assets.view.encrypted custom fields`. Usuários de API autenticados sem essa permissão podem criar ativos com valores de campos personalizados sensíveis que permanecem não criptografados no banco de dados, expondo-os potencialmente por meio de backups, réplicas ou acesso direto ao banco de dados.

Existe uma falha de bypass de autenticação na função `handleGoogleCallback()` dentro do `GoogleAuthController`. O sistema realiza o login de usuários cujo nome de usuário corresponda ao e-mail da conta do Google sem verificar a flag de ativação. Consequentemente, usuários desativados que possuem nomes de usuário em formato de e-mail e identidades do Google ativas podem se autenticar via Google SSO para recuperar o acesso com seus níveis de permissão anteriores, incluindo privilégios de administrador.

Um problema de server-side request forgery (SSRF) existe no recurso de teste de webhook. Isso permite que usuários super-administradores sondem endereços de rede interna, incluindo loopback e intervalos RFC1918 (espaços de endereços IP privados). Ao direcionar webhooks para hosts e portas internas e comparar as respostas 4xx versus 5xx da funcionalidade de Teste de Webhooks, um invasor pode mapear hosts ativos e portas abertas.

Quando o Suporte Completo a Múltiplas Empresas (FMCS) está habilitado, o caminho de checkout de kit predefinido não impõe o isolamento de locatário no alvo do checkout. A função `PredefinedKitCheckoutService` não chama `$item->canCheckoutTo($target)`, realizando apenas verificações de disponibilidade e de política entre ator e item. Isso permite que um não-superusuário com permissões de `assets.checkout` que pertença a pelo menos duas empresas utilize o endpoint '/kits/{kit}/checkout' para atribuir ativos, licenças, consumíveis ou acessórios de uma empresa a um usuário pertencente a uma empresa diferente, fornecendo o `user id` desse usuário.

Um redirecionamento aberto existe no endpoint de consumo de asserção SAML `POST /saml/acs` (gerenciado pela função `SamlController::acs`). O problema ocorre porque o parâmetro POST `RelayState` é gravado diretamente na chave de sessão `url.intended` apenas com a remoção de caracteres CR/LF. Posteriormente, o `LoginController` executa `redirect()->intended()`, que envia uma URL absoluta para o cabeçalho Location sem modificações. Um invasor não autenticado pode enganar um usuário de uma instância com SAML SSO habilitado para visitar um link de SSO iniciado pelo IdP manipulado, fazendo com que o navegador seja redirecionado para uma URL externa arbitrária após a autenticação bem-sucedida. Isso pode ser utilizado para facilitar ataques de phishing para coleta de credenciais. Não é necessária uma conta na instância alvo nem o comprometimento do provedor de identidade.

O software falha ao aplicar o escopo FMCS por instância nos endpoints de auditoria de ativos, dependendo apenas da filtragem na camada de consulta em vez de verificações de autorização na camada de política. Isso permite que invasores com sessões válidas e permissões `assets.audit` escrevam entradas de log de auditoria em ativos de outras empresas caso o escopo da camada de consulta seja ignorado ou refatorado.

Ocorre uma validação insuficiente da autorização de atribuição de empresa ao persistir registros de usuário via REST API. Nas funções `store()` e `update()` de `ApiUsersController`, os registros de usuário são salvos antes que as variáveis `company id` ou `company ids[]` sejam filtradas em relação às empresas permitidas do ator através de `Company::getIdsForCurrentUser()`. Em instalações que utilizam o Full Multiple Companies Support (FMCS), um não-superusuário com permissões `users.create` ou `users.edit` pode enviar identificadores de empresas fora de seu escopo autorizado. Se a configuração `null company is floater=1` estiver ativa, a conta pode ser persistida como um floater com visibilidade entre empresas, permitindo a criação ou realocação de contas de usuário entre limites de locatários.

O software apaga o banco de dados antes de validar o arquivo de backup enviado no endpoint de restauração. Se um superusuário enviar um arquivo zip corrompido ou inválido, isso desencadeia a perda permanente de dados, pois não há caminho de recuperação ou mecanismo de rollback.

Na função `AccountAcceptanceController::store()`, o software não verifica o valor de retorno de `Storage::put()` ao salvar PNGs de assinatura e PDFs de aceitação gerados. Em drivers de sistema de arquivos que retornam um valor falso em vez de lançar uma exceção durante falhas de gravação — como discos locais com permissões restritivas, S3 com credenciais expiradas ou backends de armazenamento que excederam a cota — o processo continua para a função `accept()`. Isso resulta na atualização dos campos `accepted at`, `signature filename` e `eula filename`, na criação de uma entrada de log de ação aceita e no envio de notificações de conclusão, apesar de os arquivos de evidência não terem sido armazenados. Isso gera artefatos de conformidade incompletos para fluxos de trabalho de recebimento de equipamentos ou reconhecimento de EULA. O problema ocorre quando um usuário autenticado conclui uma aceitação enquanto o backend de armazenamento apresenta falhas de gravação.

Existe um problema onde o sistema falha ao verificar o valor de retorno da função `Storage::delete()` dentro de `UploadedFilesController::destroy()` e `ApiUploadedFilesController::destroy()`. Isso permite que as solicitações de exclusão reportem sucesso mesmo que os arquivos permaneçam no disco. Consequentemente, embora os administradores vejam os arquivos ocultos das listagens, os arquivos físicos persistem e permanecem acessíveis a indivíduos com acesso ao sistema de arquivos ou backup.

A sanitização insuficiente do campo de texto EULA da categoria permite que usuários com permissões de baixo privilégio injetem sintaxe de imagem markdown ou tags img HTML brutas. Essas tags podem apontar para arquivos locais ou URLs remotas, que a biblioteca de auto-incorporação de e-mail resolve no lado do servidor e inclui como anexos de e-mail. Esse comportamento permite Server-Side Request Forgery (SSRF), uma técnica onde um invasor induz o servidor a fazer requisições para um local não pretendido, e a exfiltração de arquivos sensíveis, como credenciais `.env`.

Usuários autenticados com permissões `reports.view` podem acessar aceites de ativos pendentes de todas as empresas devido ao escopo inadequado das consultas de relatório. Isso permite a divulgação não autorizada de detalhes de inventário entre empresas e nomes de cessionários através da página de relatório `unaccepted assets` ou de sua exportação em CSV, pois o sistema falha ao realizar a validação de acesso por linha.

Existe um problema onde elementos de fórmula não são neutralizados na exportação de CSV do relatório de aceitação de ativos não aceitos. A função `postAssetAcceptanceReport()` no `ReportsController` constrói o CSV manualmente sem aplicar a neutralização de fórmulas ou respeitar a configuração `app.escape formulas`. Um usuário autenticado com baixos privilégios pode injetar valores começando com =, +, -, @, tab ou CR em campos de texto livre, como nome do ativo, tag, nome da empresa, categoria, modelo ou nome de exibição do cessionário. Quando um usuário com privilégios de `reports.view` solicita a exportação através do endpoint 'POST /reports/unaccepted assets' e abre o arquivo em softwares de planilha como Excel, LibreOffice Calc ou Google Sheets, o conteúdo injetado é executado como uma fórmula. Isso pode levar à exfiltração de dados através de funções como HYPERLINK ou WEBSERVICE, ou à execução de comandos DDE (Dynamic Data Exchange) em configurações legadas do Excel para Windows.

Existe uma condição de corrida (race condition) nos caminhos de checkout de ativos. As funções `ApiAssetsController::checkout()` e `AssetsAssetCheckoutController::store()` chamam `Asset::availableForCheckout()` fora do caminho de mutação e, posteriormente, invocam `Asset::checkOut()` sem implementar um bloqueio de linha (row lock) ou re-verificar a disponibilidade. Consequentemente, duas solicitações de checkout simultâneas para o mesmo ativo disponível podem ser processadas como bem-sucedidas. Isso resulta em linhas de histórico de checkout duplicadas, um `checkout counter` duplicado e dois eventos `CheckoutableCheckedOut` para um ativo de atribuição única, corrompendo a trilha de auditoria e os relatórios de utilização/reconciliação. O valor final de `assigned to` permanece singular, mantendo a atribuição visível intacta. A exploração requer uma sessão autenticada com a permissão `assets.checkout` ou privilégios de superusuário, combinada com um tempo de concorrência preciso.

Existe um problema na função `SettingsController::downloadLocationScopingReport` onde o relatório de incompatibilidade de escopo de localização FMCS é transmitido através do endpoint '/admin/settings/location-scoping-report.csv' usando uma chamada `fputcsv()` simples. Este processo não aplica o `LeagueCsvEscapeFormula`, ignorando a configuração `app.escape formulas`. Um usuário autenticado com permissões de criação ou edição pode injetar fórmulas de planilha em campos de texto livre, como nome do item, tag do ativo, serial, nome da empresa do item ou local, e nome do local. Se um superusuário baixar este relatório e abri-lo em softwares como Excel, LibreOffice Calc ou Google Sheets com a avaliação de fórmulas habilitada, células que começam com `=`, `+`, `-`, `@`, tab ou CR serão executadas. Isso pode levar à exfiltração de dados via funções `HYPERLINK` ou `WEBSERVICE`, ou execução de comandos DDE legados no Windows Excel.

Existe uma falha de bypass de autorização em componentes Livewire que aplicam a autorização apenas no nível da rota, e não nos métodos de ciclo de vida do componente. Um invasor autenticado pode repetir snapshots de componentes assinados através do endpoint 'POST /livewire/update' para invocar métodos protegidos. Isso permite a escalada de privilégios, possibilitando a criação de clientes OAuth, a emissão de tokens de acesso pessoal e o acesso a dados administrativos sensíveis.

Quando o Suporte Completo a Múltiplas Empresas (FMCS) está habilitado, certos endpoints de aceitação de relatórios não são corretamente delimitados. Um usuário autenticado com a permissão `reports.view` pode enviar e-mails de lembrete de aceitação ou excluir permanentemente qualquer registro de aceitação pendente em toda a instalação, independentemente da empresa proprietária. Isso ocorre porque a função `currentUserCanAccessAcceptance()` no `ReportsController` permite incorretamente o acesso para usuários do tipo pivot-only (usuários associados a empresas via tabela pivot cujo `company id` é NULL), e versões anteriores a 8.6.3 carecem totalmente dessa proteção. Os endpoints afetados são `POST /reports/unaccepted assets/sent reminder` (via `sentAssetAcceptanceReminder()`) e `DELETE /reports/unaccepted assets/{acceptanceId}/delete` (via `deleteAssetAcceptance()`). A exclusão é destrutiva e remove a trilha de auditoria de aceitação, enquanto o e-mail de lembrete pode expor nomes de itens e metadados de atribuição entre empresas. Os IDs de aceitação são inteiros sequenciais e podem ser enumerados.

Existe um problema onde a aplicação não verifica o valor de retorno das operações de gravação de armazenamento na função `ImageUploadRequest::handleImages()`. Devido ao modo de disco padrão do framework Laravel não lançar exceções em caso de falha, uma chamada `Storage::disk('public')->put(...)` malsucedida faz com que a aplicação exclua a imagem anterior através de `deleteExistingImage()` e atualize a referência no banco de dados para um novo nome de arquivo que nunca foi efetivamente gravado no disco. Da mesma forma, uma falha em `Storage::delete()` dentro de `deleteExistingImage()` pode anular o campo de imagem no banco de dados, deixando o arquivo órfão no disco. Esta condição ocorre quando um usuário autenticado faz o upload de uma imagem durante uma falha no backend de armazenamento, como erros de rede do S3, problemas de permissão do sistema de arquivos ou exaustão de cota, resultando em perda irrecuperável de dados e inconsistência no banco de dados. Isso afeta múltiplos modelos, incluindo ativos, usuários, empresas, fabricantes, locais, categorias, fornecedores e departamentos.