CVE-2026-68517 in Glances
Summary
by MITRE • 08/17/2026
Glances is an open-source system cross-platform monitoring tool. Prior to 4.5.6, the cors_origins guard in glances/outputs/glances_restful_api.py uses exact list equality instead of wildcard membership, allowing a multi-origin list containing the wildcard to retain cors_credentials and expose authenticated REST API data to an untrusted website visited by a previously authenticated user. This issue is fixed in 4.5.6.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in Glances prior to version 4.5.6 represents a critical misconfiguration within the Cross-Origin Resource Sharing (CORS) implementation of its RESTful API interface. Glances, widely utilized for cross-platform system monitoring and data visualization, exposes sensitive operational metrics through an HTTP-based API that supports authentication mechanisms such as Basic Auth or token-based sessions. The core flaw resides in the logic governing how allowed origins are validated against incoming requests from web browsers. Specifically, the function responsible for checking if a request origin is permitted to access resources located at different domains relied on exact list equality rather than proper wildcard membership evaluation. This architectural oversight fundamentally undermines the security model intended by CORS policies, which rely on strict validation of source origins to prevent unauthorized data exfiltration via malicious web pages.
In a correctly implemented CORS policy, if an origin is designated as trusted using a wildcard pattern or specific domain matching logic, the server should appropriately handle credentials such as cookies and HTTP authentication headers only when the requesting origin matches one of the explicitly allowed entries in a manner that respects security boundaries. However, due to the use of exact list equality checks, the presence of a wildcard character within the cors_origins configuration list did not trigger the expected broad allowance logic. Instead, the system failed to properly distinguish between specific domain restrictions and open access policies. Consequently, when an administrator configured the CORS settings with intent to allow certain origins while potentially intending broader access or misconfigured the list structure, the validation logic erroneously retained credentials for requests originating from untrusted domains if the wildcard was present in a way that bypassed strict equality checks but failed subsequent security filters. This resulted in the browser sending authenticated headers to malicious third-party websites visited by users who had previously logged into the Glances interface within their session window.
The operational impact of this vulnerability is severe, particularly for deployments where the Glances REST API is exposed on a network accessible from untrusted environments or public internet segments. An attacker can craft a simple HTML page hosted on an external domain that includes JavaScript code to make cross-origin requests to the vulnerable Glances instance. Because the browser automatically attaches stored authentication credentials (such as Basic Auth cookies) to these requests due to the misconfigured CORS policy, the malicious script receives responses containing sensitive system data. This data can include real-time CPU usage, memory consumption, disk I/O statistics, network interface details, and potentially more critical information depending on the permissions of the authenticated user account. In environments where Glances is integrated with other monitoring tools or used for security auditing, this exposure could facilitate further reconnaissance attacks, lateral movement planning by adversaries who have gained initial access to a client machine that visits the malicious site, or simply result in significant privacy and operational intelligence leaks.
This vulnerability aligns closely with CWE-942, which describes Permissive Cross-domain Policy with Untrusted Domains allowing Sensitive Information Disclosure. It also maps to MITRE ATT&CK technique T1505.003, Server Software Component: Web Shell or API Abuse, specifically in the context of abusing misconfigured web server components to exfiltrate data without direct authentication credentials at the time of exploitation. The flaw highlights a common pitfall in web application development where developers assume that including wildcard characters in configuration lists will automatically handle all edge cases regarding origin validation, neglecting the need for explicit and robust domain matching algorithms. Such oversights are particularly dangerous when combined with stateful sessions or persistent authentication tokens, as they effectively bypass same-origin policy protections intended to isolate sensitive applications from potentially hostile web content.
Mitigation strategies primarily involve upgrading to Glances version 4.5.6 or later, where the developers have corrected the logic for handling CORS origins and ensured that wildcard membership is evaluated correctly without compromising security boundaries. For organizations unable to immediately patch their systems, temporary mitigations should include restricting access to the Glances REST API through network-level controls such as firewalls or reverse proxies that enforce strict origin headers before requests reach the application layer. Additionally, administrators should review CORS configurations to ensure they do not rely on ambiguous wildcard patterns and instead explicitly list trusted domains. Implementing Content Security Policy (CSP) headers can also provide an additional layer of defense by restricting how resources are loaded and executed within browsers accessing the Glances interface. Regular security audits of web application configurations and adherence to OWASP guidelines for cross-origin resource sharing best practices are essential to prevent similar misconfigurations in other services exposed on internal or external networks.