Fewword

O acesso ao vídeo no backend não impõe as restrições exclusivas para o público da função de visitante quando `loginEnabled` está definido como `true` e uma senha de visitante está configurada. Embora exista um filtro em `VideoContext.tsx`, ele é apenas do lado do cliente. O `roleBasedAuthMiddleware.ts` permite todas as solicitações GET de visitantes, e o arquivo `storageService/videos.ts` executa as consultas `getVideos()` e `getVideoById(id)` sem verificar a função do chamador ou o status de `visibility`. Isso permite que um visitante enumere o endpoint '/api/videos' ou solicite '/api/videos/:id' para recuperar registros onde `visibility` é 0, expondo títulos, `sourceUrl`, `videoPath`, caminhos de legendas e `thumbnailPath`. Além disso, o caminho `serveMountVideo()` fornece arquivos de vídeo montados sem verificações de `visibility`, permitindo downloads de mídia não autenticados via rotas '/videos/*' e '/subtitles/*'. Implantações de usuário único com `loginEnabled` definido como `false` não são afetadas.

No arquivo `server.ts`, as funções `registerStaticRoutes` e `registerCloudRoutes` são chamadas antes de `registerApiRoutes`, onde `authMiddleware` e `roleBasedAuthMiddleware` são montados. Como o Express processa o middleware na ordem de registro, as rotas em `staticRoutes.ts` e `cloudRoutes.ts` permanecem fora da pilha de autenticação, mesmo quando `loginEnabled` está definido como `true`. Isso permite que clientes não autenticados acessem vídeos locais através do endpoint '/videos/*', miniaturas via '/images/*' e '/images-small/*', avatares via '/avatars/*', legendas via '/subtitles/*', caches de miniaturas na nuvem via '/api/cloud/thumbnail-cache/*' e URLs assinadas ou redirecionamentos na nuvem via '/cloud/videos/:filename' e '/cloud/images/:filename'. Esta falha permite o download não autenticado de mídias ocultas quando combinada com vazamentos de caminho de vídeos ocultos.

Existe um problema onde os destinos de webhook são validados apenas durante o registro e não durante o uso. A função `NoInternalUrlRule` em `backend/app/Validators/Rules/NoInternalUrlRule.php` utiliza `gethostbyname()` para rejeitar intervalos de IP privados e reservados, mas nomes de host públicos são permitidos. Durante o despacho, o `WebhookDispatchService` utiliza a URL armazenada via `spatie/laravel-webhook-server` sem revalidar o destino. Como o arquivo `backend/config/webhook-server.php` não configura as opções do Guzzle, o seguimento de redirecionamentos permanece ativado por padrão. Isso permite que um destino redirecione o servidor para um endereço de loopback, privado ou de metadados de nuvem, ou permite que um invasor altere um registro de DNS após o registro para alcançar o mesmo resultado. O `WebhookResponseHandlerService` armazena o corpo da resposta no log do webhook, que é então exposto através do endpoint `WebhookLogResource`, permitindo que o solicitante leia respostas de serviços internos. Isso afeta tanto os webhooks de eventos quanto os de organizadores.

Nome do Software Vulnerável e Versões Afetadas: Versões do LibreNMS anteriores à 25.5.0 Descrição: O problema é uma vulnerabilidade de Cross-Site Scripting (XSS) Armazenado que afeta o parâmetro `group name` do formulário "http://localhost/poller/groups". Isso permite que atacantes injetem scripts maliciosos em páginas web visualizadas por outros usuários. Recomendações: Para versões anteriores à 25.5.0, atualize para a versão 25.5.0 ou posterior para resolver o problema. Como medida de contorno temporária, considere restringir o acesso ao formulário "http://localhost/poller/groups" até que a atualização seja aplicada. Evite usar o parâmetro `group name` no formulário afetado até que o problema seja resolvido.

O problema consiste em uma vulnerabilidade de Cross-Site Scripting (XSS) Persistente no parâmetro `name` do formulário "http://localhost/?controller=ProjectCreationController&action=create". Isso permite que atacantes injetem scripts maliciosos em páginas web visualizadas por outros usuários. A Política de Segurança de Conteúdo (CSP) padrão bloqueia o ataque JavaScript, mas este pode ser explorado se uma instância estiver mal configurada e o software estiver vulnerável à injeção de CSS devido à diretiva `unsafe-inline` na CSP padrão.