Christopherfi-Dev

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.

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`.

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.

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.

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.

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.

A sanitização incompleta no campo de CSS Personalizado permite a injeção de CSS, pois a codificação HTML em caracteres de maior-que e aspas duplas é revertida. Superusuários podem injetar payloads de CSS maliciosos usando referências `@import` e `url()`. Isso permite a exfiltração de tokens CSRF (Cross-Site Request Forgery)—tokens exclusivos usados para evitar que comandos não autorizados sejam transmitidos de um usuário em quem a aplicação web confia—de outros superusuários via regras de seletor de atributos, o que pode levar ao sequestro de conta.