FileRise CVE-2026-69194

Requires an authenticated administrator (PR:H) to first store a crafted branding.footerHtml value through the Admin Panel; only then does the unauthenticated public site configuration API return that raw HTML to clients. Exploitation is strongly LIMITED because the official FileRise frontend already sanitizes the footer via a tag allowlist (a, b, strong, em, i, span, small, br) with safe-link handling before rendering, so the bundled web client is not exploitable. Realistic impact is confined to alternate/third-party clients or future render paths that consume the public config API and render footerHtml without their own sanitization, and a victim must load such a client (UI:R). Affected deployments are FileRise versions prior to 3.21.0.

This is a defense-in-depth / low-priority issue rather than an urgent threat, despite being network-reachable. The provided CVSS:3.1 vector (AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N) scores 4.8 (Medium), and the high-privilege requirement (PR:H) is the dominant limiting factor: an administrator must first store the malicious branding.footerHtml value, so an attacker cannot act purely from the unauthenticated side despite the vulnerable endpoint being the unauthenticated public config API. Critically, the vendor advisory and description both state the FileRise frontend ALREADY sanitizes this value via a tag allowlist before rendering, so the standard web client is not exploitable - the fix (commit 613fdb2) adds server-side sanitization as a second layer primarily to protect alternate/custom API clients and future render paths. No EPSS score is provided in the input, so exploitation probability cannot be quantified; there is no CISA KEV listing and no public POC, so there is no public exploit identified at time of analysis. The signals are internally consistent (low severity, high privilege, existing client-side mitigation all point the same way); the main caveat is that the CVSS vector encodes the raw stored-XSS primitive and does NOT account for the compensating frontend sanitization, so real-world risk is lower than even the 4.8 score suggests.

A malicious or compromised administrator saves active HTML/JavaScript into the FileRise footer branding field, which is then returned verbatim by the unauthenticated public site configuration API. A separate or custom client that consumes this API and renders the footer HTML without its own sanitization would execute the attacker's script in a viewer's browser. No public exploit code is identified, and the official FileRise web frontend is not affected because it sanitizes the value before rendering.