CVE-2026-68517

Executive Summary

CVE-2026-68517 is a CORS misconfiguration vulnerability in Glances, an open-source cross-platform system monitoring tool. In versions prior to 4.5.6, the cors_origins guard in glances/outputs/glances_restful_api.py incorrectly permits a configuration that contains the wildcard element while still allowing credentialed CORS requests, which can expose authenticated RESTful API data to an untrusted website visited by a previously authenticated user. The vulnerability has a CVSS base score of 6.5, requires user interaction, and results in high confidentiality impact without direct impact to integrity or availability.

Technical Analysis

The vulnerability resides in the CORS enforcement logic of the Glances RESTful API, specifically in the cors_origins guard inside glances/outputs/glances_restful_api.py. According to the NVD description, the guard uses exact list equality instead of wildcard membership. In practice, this means that when the configured allowed-origin list contains a wildcard entry such as *, the guard does not correctly evaluate the wildcard semantics. Instead of rejecting the configuration as overly permissive or forcing the API to drop credential support, the logic can retain the cors_credentials setting.

A correct CORS implementation must not combine the wildcard Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true, because doing so tells the browser to allow any origin to send requests while including cookies or HTTP authentication. This combination effectively disables the same-origin policy for the affected API. Because the vulnerable guard fails to strip or deny wildcard members, an attacker-controlled origin can read the response data returned by the Glances RESTful API if the victim’s browser already holds valid credentials for the Glances instance.

The attack surface is the HTTP-facing Glances RESTful API. Glances is deployed as a monitoring agent and often accessible via a web interface for convenience. When deployed on a network boundary or with weak access controls, the API exposes system metrics, host information, process data, and monitoring telemetry. If browser-based authentication is in use, the attacker only needs to lure the authenticated victim to a malicious page. No API endpoints, payload details, or public exploit code are described in the available data; the mechanism is inferred from the vulnerability class and the provided CVE description. The exact comparison logic and configuration syntax beyond the cited identifiers are not publicly documented in the supplied input.

Exploitation Scenarios

No public proof-of-concept has been observed for CVE-2026-68517. The following attack chain is derived from the vulnerability description and the general CORS attack class.

1. Reconnaissance and target identification: An attacker discovers internet-exposed or internally reachable Glances instances. Fingerprinting may be performed by identifying the glances_restful_api module in HTTP responses, banners, or JavaScript files served by the Glances web interface. The attacker determines whether the version is prior to 4.5.6, indicating potential exposure.

2. Triggering the flaw: The attacker hosts a malicious website. The victim, who has previously authenticated to the Glances RESTful API in their browser, visits the malicious page. The page contains JavaScript code that issues cross-origin HTTP requests to the Glances API. Because the vulnerable cors_origins guard leaves credentialed CORS enabled in the presence of a wildcard origin entry, the browser will send the victim’s session credentials with the request.

3. Execution method at the vulnerability-class level: The malicious website performs a classic CORS-bypass request. For example, it may issue an XMLHttpRequest or fetch call using credentials: "include". The vulnerable Glances API responds with permissive CORS headers, including the wildcard origin and credentialed flag. The browser sees these headers and grants the attacker’s JavaScript read access to the response body, which contains authenticated RESTful API data.

4. Post-exploitation impact: The attacker receives system monitoring or configuration data associated with the compromised Glances deployment. This may include hostnames, network interface details, running processes, logged-in users, storage metrics, and other telemetry. This information can be used to map the internal infrastructure and support further targeted attacks. No integrity or availability impact is expected from this CVE alone.

Impact Assessment

The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, yielding a base score of 6.5. The high confidentiality component reflects full read access to the authenticated API data from an arbitrary origin. User interaction is required because the victim must visit the attacker-controlled page while authenticated. No special privileges are required beyond the victim’s existing browser session.

The business impact depends on deployment context. For externally exposed Glances instances, the blast radius can include leakage of sensitive infrastructure information across trust boundaries. For internal deployments, the attacker may chain this vulnerability with phishing or drive-by compromise to pivot into the monitoring environment. Monitoring data is frequently considered lower sensitivity, but it often reveals software versions, host roles, network topology, and active accounts, all of which aid privilege escalation and lateral movement.

At the time of writing, there is no CISA KEV listing, no confirmed public exploit, no Nuclei template, and no EPSS score from FIRST.org. Patch confidence is 0/4 from tracked patch sources, although the NVD description states that the issue is fixed in Glances 4.5.6.

Detection Guidance

Sigma Rule

The following Sigma rule detects HTTP responses containing both a wildcard Access-Control-Allow-Origin and Access-Control-Allow-Credentials, which are the permissive header combination generated by the vulnerable Glances CORS configuration.

title: Glances RESTful API CORS Wildcard Credential Exposure
id: 1f7e9a2c-8d4b-4c1e-b6f2-0a9d8e7f6c5b
status: experimental
description: >
  Detects HTTP responses containing the combination of
  Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true,
  indicative of CVE-2026-68517 in Glances prior to 4.5.6.
logsource:
  category: webserver
  product: generic
detection:
  selection_headers:
    http.response.headers.access-control-allow-origin: "*"
    http.response.headers.access-control-allow-credentials: "true"
  selection_glances:
    http.response.body|contains:
      - "glances"
      - "glances_restful_api"
  condition: selection_headers and selection_glances
level: high
falsepositives:
  - Legitimate monitoring dashboards intentionally using wildcard CORS without credentials
  - Misconfigured internal applications sharing the same header pattern

YARA Rule

The following YARA rule scans Glances source files for the presence of the vulnerable CORS guard identifiers.

rule CVE_2026_68517_Glances_CORS_Wildcard {
    meta:
        author = "Valters IT Cyber Threat Intelligence"
        description = "Detects vulnerable Glances RESTful API source code with permissive CORS wildcard handling"
        date = "2026-01-01"
        cve = "CVE-2026-68517"
    strings:
        $a = "glances_restful_api.py" ascii nocase
        $b = "cors_origins" ascii nocase
        $c = "cors_credentials" ascii nocase
    condition:
        filesize < 2MB and 2 of them
}

Suricata IDS Rule

The following Suricata rule inspects HTTP response traffic for the permissive CORS header combination associated with vulnerable Glances deployments.

alert http any any -> any any (
    msg:"CVE-2026-68517 - Glances RESTful API permissive CORS with credentials";
    flow:to_client,established;
    content:"Access-Control-Allow-Origin|3a 20|*|0d 0a|";
    http_header;
    content:"Access-Control-Allow-Credentials|3a 20|true";
    http_header;
    reference:cve,2026-68517;
    classtype:attempted-user;
    sid:20261717;
    rev:1;
)

Elastic Detection

The following Elastic EQL query searches for HTTP network events that contain both permissive CORS headers.

network where network.protocol == "http"
    and http.response.headers.access-control-allow-origin == "*"
    and http.response.headers.access-control-allow-credentials == "true"

Splunk SPL Query

The following Splunk search identifies HTTP proxy or web server logs containing the vulnerable CORS response headers.

(index=proxy OR index=webserver)
    "Access-Control-Allow-Origin: *"
    "Access-Control-Allow-Credentials: true"
| stats count min(_time) max(_time) by src_ip, dest_ip, dest_port, http_referrer
| sort - count

Wazuh OSSEC Rule

The following Wazuh rule uses regex matching on web server access log fields to detect the permissive CORS header combination.

<group name="web,glances,">
  <rule id="120685" level="12">
    <decoded>
      <regex>Access-Control-Allow-Origin: \*</regex>
      <regex>Access-Control-Allow-Credentials: true</regex>
    </decoded>
    <description>Glances RESTful API CORS wildcard exposure (CVE-2026-68517)</description>
    <mitre>
      <id>T1189</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

The tracked patch confidence is 0/4, meaning no patch evidence has been indexed from advisory feeds, vendor changelogs, or package registries at the time of writing. The NVD description states that the issue is fixed in Glances 4.5.6, but defenders should verify the availability of the fixed release from the upstream project before applying it.

Immediate mitigations:

• Ensure the Glances cors_origins configuration does not include a wildcard entry. If wildcard entries are mandatory for an operational reason, confirm that cors_credentials is disabled; the two settings must never be combined.
• Restrict network access to the Glances RESTful API using host-based firewall rules, network policy, or a reverse proxy allowlist of trusted origins.
• Place Glances behind an authentication-proxying reverse proxy and enforce additional access controls such as VPN or IP allowlisting.
• Monitor HTTP logs for responses containing Access-Control-Allow-Origin: * together with Access-Control-Allow-Credentials: true.

Patch and upgrade steps:

• Upgrade Glances to version 4.5.6 or later. Because the upstream advisory is not present in the current tracked patch sources, validate the downloaded release and compare checksums against upstream release artifacts.
• After upgrading, retest the CORS behavior by issuing cross-origin requests from an untrusted origin and verify that credentialed responses are no longer served.
• Review the Glances RESTful API configuration for any remaining wildcard CORS entries and remove them.

Long-term hardening:

• Run Glances only on trusted internal networks and never expose it directly to the internet without a WAF or reverse proxy.
• Use strong, centralized authentication for monitoring platforms, and consider MFA for all browser-based access.
• Establish a process for regular CORS configuration reviews as part of application security checks.
• Integrate the detection rules above into SIEM, IDS, and endpoint monitoring pipelines to identify early indicators of CORS-based data theft.

References

1. NVD Entry for CVE-2026-68517: https://nvd.nist.gov/vuln/detail/CVE-2026-68517
2. CWE-942 — Permissive Cross-domain Policy with Untrusted Domains: https://cwe.mitre.org/data/definitions/942.html
3. MITRE ATT&CK Technique T1189 — Drive-by Compromise: https://attack.mitre.org/techniques/T1189/
4. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — no current KEV entry exists for CVE-2026-68517

No public exploit code, Nuclei template, or threat actor campaign referencing CVE-2026-68517 was identified in the available data.