FileRise CVE-2026-104110

Requires the FileRise Pro add-on to be installed AND at least one client portal to be configured; the attacker must also know or correctly guess that portal's slug, which is the sole value needed to call /api/pro/portals/get.php with no authentication. Limiting factors: the base-edition FileRise install is not affected (Pro-only endpoint), only portal metadata (internal storage folder path, client contact email, form settings, upload-policy details) is exposed rather than file contents or credentials, and the fix in v3.24.0 simply gates the endpoint behind an authenticated session while the public publicMeta.php branding endpoint remains open.

This is a moderate-severity information disclosure (CWE-200) with a self-consistent CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N = 5.3). The network vector and PR:N correctly reflect that /api/pro/portals/get.php returned a portal's full internal record to an unauthenticated caller, and the C:L/I:N/A:N impact matches a read-only metadata leak with no integrity or availability effect - the CVSS and the description agree, with no contradictory signals. No EPSS score, KEV listing, or public exploit was provided in the input, so there is no evidence of active or opportunistic exploitation; this reads as a genuine but low-urgency issue rather than a top-priority emergency. Real-world risk is further constrained because exploitation requires the paid Pro add-on, at least one configured portal, and knowledge or a correct guess of the portal slug - reducing it from a mass-scannable flaw to a more targeted one. Overall: a legitimate confidentiality bug worth patching promptly for Pro users, but not a high-real-risk item for the broad FileRise population given its narrow preconditions and absence of exploitation signals.

An attacker who learns or guesses a valid portal slug sends an unauthenticated GET request to /api/pro/portals/get.php and receives the portal's full internal record - including the storage folder path, client contact email, form settings, and upload-policy details. This reconnaissance data could then inform follow-on social-engineering or targeting of the exposed storage path. No public exploit was identified at time of analysis, though the attack is trivial to reproduce from the description alone.