Fewword

Backend video access fails to enforce public-only restrictions for the visitor role when `loginEnabled` is set to `true` and a visitor password is configured. While a filter exists in `VideoContext.tsx`, it is only client-side. The `roleBasedAuthMiddleware.ts` allows all visitor GET requests, and the `storageService/videos.ts` file executes `getVideos()` and `getVideoById(id)` queries without verifying the caller's role or the `visibility` status. This allows a visitor to enumerate the '/api/videos' endpoint or request '/api/videos/:id' to retrieve records where `visibility` is 0, exposing titles, `sourceUrl`, `videoPath`, subtitle paths, and `thumbnailPath`. Additionally, the `serveMountVideo()` path serves mounted video files without `visibility` checks, enabling unauthenticated media downloads via '/videos/*' and '/subtitles/*' routes. Single-user deployments with `loginEnabled` set to `false` are not affected.

In `server.ts`, the functions `registerStaticRoutes` and `registerCloudRoutes` are called before `registerApiRoutes`, where `authMiddleware` and `roleBasedAuthMiddleware` are mounted. Since Express processes middleware in the order they are registered, the routes in `staticRoutes.ts` and `cloudRoutes.ts` bypass the authentication stack even when `loginEnabled` is set to `true`. This allows unauthenticated clients to access local videos via the '/videos/*' endpoint, thumbnails via '/images/*' and '/images-small/*', avatars via '/avatars/*', subtitles via '/subtitles/*', cloud thumbnail caches via '/api/cloud/thumbnail-cache/*', and cloud signed URLs or redirects via '/cloud/videos/:filename' and '/cloud/images/:filename'. This flaw enables the unauthenticated download of hidden media when combined with hidden-video path leaks.

An issue exists where webhook destinations are validated only during registration and not during use. The `NoInternalUrlRule` function in `backend/app/Validators/Rules/NoInternalUrlRule.php` uses `gethostbyname()` to reject private and reserved IP ranges, but public hostnames are permitted. During dispatch, the `WebhookDispatchService` utilizes the stored URL via `spatie/laravel-webhook-server` without re-validating the destination. Because `backend/config/webhook-server.php` does not configure Guzzle options, redirect following is enabled by default. This allows a destination to redirect the server to a loopback, private, or cloud metadata address, or allows an attacker to change a DNS record after registration to achieve the same result. The `WebhookResponseHandlerService` stores the response body in the webhook log, which is then exposed via the `WebhookLogResource` endpoint, allowing the requester to read responses from internal services. This affects both event and organizer webhooks.

Name of the Vulnerable Software and Affected Versions: LibreNMS versions prior to 25.5.0 Description: The issue is a Stored Cross-Site Scripting (XSS) vulnerability that affects the `group name` parameter of the "http://localhost/poller/groups" form. This allows attackers to inject malicious scripts into web pages viewed by other users. Recommendations: For versions prior to 25.5.0, update to version 25.5.0 or later to resolve the issue. As a temporary workaround, consider restricting access to the "http://localhost/poller/groups" form until the update is applied. Avoid using the `group name` parameter in the affected form until the issue is resolved.

The issue is a Stored Cross-Site Scripting (XSS) vulnerability in the `name` parameter of the "http://localhost/?controller=ProjectCreationController&action=create" form. This allows attackers to inject malicious scripts into web pages viewed by other users. The default content security policy (CSP) blocks the JavaScript attack, but it can be exploited if an instance is badly configured and the software is vulnerable to CSS injection due to the `unsafe-inline` directive in the default CSP.