CVE-2026-44977 in Server
Summary
by MITRE • 10/16/2026
countly-server is the server-side part of Countly, a product analytics solution. Prior to 24.05.50 and 25.03.44, plugins/star-rating/api/api.js allows a non-global application administrator to use uploadFeedbackFile to store attacker-controlled active content while trusting the supplied MIME type. plugins/star-rating/frontend/app.js publicly serves the stored content from feedback/preview/ with the attacker-influenced Content-Type, so a global administrator who opens the preview executes the payload in the Countly origin and exposes authenticated session capabilities, including auth_token and csrf_token values. This issue is fixed in versions 24.05.50 and 25.03.44.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified within the server-side component of Countly, specifically affecting versions prior to 24.05.50 and 25.03.44, represents a critical security flaw rooted in improper validation of file uploads and subsequent content serving mechanisms. The core technical issue resides in the plugins/star-rating/api/api.js module, which exposes an endpoint for uploading feedback files via the uploadFeedbackFile function. This API endpoint fails to enforce strict MIME type verification against the actual file contents or extension, instead trusting the Content-Type header supplied by the client during the upload request. Consequently, a non-global application administrator can bypass intended restrictions and store attacker-controlled active content, such as malicious JavaScript payloads, on the server under the guise of legitimate feedback media files. This lack of input validation allows for the injection of executable code into the storage system without triggering standard security checks that would typically reject mismatched or dangerous file types.
The operational impact is significantly amplified by how Countly serves this stored content through the plugins/star-rating/frontend/app.js module. The application publicly serves these uploaded files from the feedback/preview/ directory and, critically, it reflects the attacker-influenced Content-Type header in its HTTP responses rather than determining the correct type server-side or enforcing a safe default like text/plain for preview purposes. When a global administrator accesses this preview endpoint to view the uploaded file, the browser interprets the response based on the malicious Content-Type header and executes the embedded script within the context of the Countly origin. This scenario constitutes a classic Stored Cross-Site Scripting (XSS) vulnerability where the persistence layer is compromised by untrusted input that is later rendered in a privileged administrative interface without proper sanitization or encoding.
The exploitation of this flaw allows an attacker with lower-level privileges to achieve high-impact outcomes against higher-privileged users, specifically global administrators who are responsible for managing the entire Countly instance. By executing arbitrary JavaScript in the context of the application origin, the attacker gains access to sensitive authenticated session capabilities. This includes the ability to steal critical authentication tokens such as auth_token and csrf_token values stored in cookies or local storage. With these credentials, an attacker can hijack administrative sessions, impersonate global administrators, and potentially take full control over the analytics platform. This escalation of privilege undermines the principle of least privilege and compromises the integrity and confidentiality of all data processed by the Countly instance, including sensitive customer behavior metrics and personal identifiable information collected through the application.
From a classification perspective, this vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS). The specific mechanism involves stored XSS where malicious scripts are permanently stored on target servers via vulnerable input fields or upload features and subsequently executed in the browsers of other users. Furthermore, this attack vector maps to MITRE ATT&CK technique T1059.007, which covers JavaScript execution under client-side scripting. The exploitation path also reflects CWE-434, an unrestricted upload of file with dangerous type, as the root cause lies in the failure to validate and restrict uploaded files based on their actual content or safe extensions rather than relying solely on client-supplied metadata.
To mitigate this vulnerability, organizations must immediately upgrade Countly-server to version 24.05.50 or later, where these issues have been addressed through enhanced input validation and secure output encoding practices. In the interim, if upgrading is not immediately feasible, administrators should restrict access to the feedback preview endpoints to prevent exposure of potentially malicious content. Implementing a Web Application Firewall (WAF) with rules designed to detect and block XSS payloads in HTTP responses or uploads can provide an additional layer of defense. Additionally, enforcing strict Content Security Policy headers that limit script execution sources and disabling inline scripts where possible can reduce the impact if such vulnerabilities are present. Regular security audits focusing on file upload mechanisms and ensuring that MIME types are validated against actual file signatures rather than client-supplied headers are essential best practices to prevent similar incidents in other web applications.