Countly Server EUVD-2026-102917

Exploitable only on Countly deployments configured to use the local filesystem backend of countlyFs (api/utils/countlyFs.js); installs using the GridFS/database backend are not reachable through these routes. No authentication, user interaction, or special privileges are required (CVSS PR:N/UI:N) - the affected public routes (/appimages/*, /memberimages/*, */screenshots/*, /star-rating/images/*, and /dashboards/images/screenshots/*) accept unauthenticated requests. The primary limiting factor is the storage-backend configuration; the impact is limited to disclosure of readable files (no write/integrity or availability effect), and only files readable by the Countly server process can be exfiltrated.

This is a genuine, actionable medium-to-high priority for affected deployments, though not an emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, base 7.5) is internally consistent with the description: an unauthenticated, network-reachable path traversal yielding arbitrary readable-file disclosure (confidentiality High; no integrity or availability impact). The key tempering signal is NOT in the CVSS vector but in the description - exploitation only works 'on deployments using the local filesystem backend' of countlyFs, so environments using the GridFS/database backend are not reachable via these routes, meaning the real-world exploitable population is a subset of installs. No EPSS score, CISA KEV listing, or public POC was provided, so exploitation status is 'no public exploit identified at time of analysis'; however, the fix commits are public and the diff clearly shows the missing containment check, which lowers the effort for an attacker to reverse-engineer a working traversal. There is no conflict between the signals - CVSS, CWE-22, and the source diff all agree this is a real unauthenticated arbitrary-file-read. The main uncertainty is deployment-backend configuration, which determines whether a given instance is actually vulnerable.

An unauthenticated attacker sends a crafted HTTP request to a public image or screenshot route such as /appimages/ or /dashboards/images/screenshots/, embedding directory-traversal sequences in the wildcard portion of the path. Because the routes concatenate the attacker-controlled path without containment validation, the request resolves outside the intended asset directory and countlyFs reads an arbitrary server-side file (for example configuration files or credentials), returning its contents in the response. No public exploit is identified at time of analysis, but the public fix commits reveal the vulnerable concatenation and make the flaw straightforward to reproduce against local-filesystem-backend deployments.