Common Weakness Enumeration

CWE-312

Allowed

Cleartext Storage of Sensitive Information

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

1134 vulnerabilities reference this CWE, most recent first.

GHSA-G4G7-V7Q6-4XW8

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

In Bitcoin Core 0.18.0, bitcoin-qt stores wallet.dat data unencrypted in memory. Upon a crash, it may dump a core file. If a user were to mishandle a core file, an attacker can reconstruct the user's wallet.dat file, including their private keys, via a grep "6231 0500" command.

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-2019-15947"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312",
      "CWE-326"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-05T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Bitcoin Core 0.18.0, bitcoin-qt stores wallet.dat data unencrypted in memory. Upon a crash, it may dump a core file. If a user were to mishandle a core file, an attacker can reconstruct the user\u0027s wallet.dat file, including their private keys, via a grep \"6231 0500\" command.",
  "id": "GHSA-g4g7-v7q6-4xw8",
  "modified": "2022-05-24T16:55:31Z",
  "published": "2022-05-24T16:55:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15947"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bitcoin/bitcoin/issues/16824"
    },
    {
      "type": "WEB",
      "url": "https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2019-15947"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/oxagast/50a121b2df32186e0c48411859d5861b"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202009-18"
    }
  ],
  "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-G596-F5RR-4QJP

Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2024-10-09 15:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

KEYS: trusted: dcp: fix leak of blob encryption key

Trusted keys unseal the key blob on load, but keep the sealed payload in the blob field so that every subsequent read (export) will simply convert this field to hex and send it to userspace.

With DCP-based trusted keys, we decrypt the blob encryption key (BEK) in the Kernel due hardware limitations and then decrypt the blob payload. BEK decryption is done in-place which means that the trusted key blob field is modified and it consequently holds the BEK in plain text. Every subsequent read of that key thus send the plain text BEK instead of the encrypted BEK to userspace.

This issue only occurs when importing a trusted DCP-based key and then exporting it again. This should rarely happen as the common use cases are to either create a new trusted key and export it, or import a key blob and then just use it without exporting it again.

Fix this by performing BEK decryption and encryption in a dedicated buffer. Further always wipe the plain text BEK buffer to prevent leaking the key via uninitialized memory.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-45004"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-04T20:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: dcp: fix leak of blob encryption key\n\nTrusted keys unseal the key blob on load, but keep the sealed payload in\nthe blob field so that every subsequent read (export) will simply\nconvert this field to hex and send it to userspace.\n\nWith DCP-based trusted keys, we decrypt the blob encryption key (BEK)\nin the Kernel due hardware limitations and then decrypt the blob payload.\nBEK decryption is done in-place which means that the trusted key blob\nfield is modified and it consequently holds the BEK in plain text.\nEvery subsequent read of that key thus send the plain text BEK instead\nof the encrypted BEK to userspace.\n\nThis issue only occurs when importing a trusted DCP-based key and\nthen exporting it again. This should rarely happen as the common use cases\nare to either create a new trusted key and export it, or import a key\nblob and then just use it without exporting it again.\n\nFix this by performing BEK decryption and encryption in a dedicated\nbuffer. Further always wipe the plain text BEK buffer to prevent leaking\nthe key via uninitialized memory.",
  "id": "GHSA-g596-f5rr-4qjp",
  "modified": "2024-10-09T15:32:18Z",
  "published": "2024-09-04T21:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45004"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0e28bf61a5f9ab30be3f3b4eafb8d097e39446bb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9e3b266afcfe4294e84496f50f006f029d3100db"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G5Q2-63R8-XRQ9

Vulnerability from github – Published: 2022-11-04 12:00 – Updated: 2022-11-04 19:01
VLAI
Details

"IBM Cognos Analytics 11.2.1, 11.2.0, 11.1.7 stores user credentials in plain clear text which can be read by an authenticated user. IBM X-Force ID: 229963."

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-2022-34339"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-03T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "\"IBM Cognos Analytics 11.2.1, 11.2.0, 11.1.7 stores user credentials in plain clear text which can be read by an authenticated user. IBM X-Force ID: 229963.\"",
  "id": "GHSA-g5q2-63r8-xrq9",
  "modified": "2022-11-04T19:01:16Z",
  "published": "2022-11-04T12:00:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34339"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6828527"
    }
  ],
  "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-G5WH-4VXR-QMJG

Vulnerability from github – Published: 2024-07-26 12:35 – Updated: 2024-08-05 21:31
VLAI
Details

This vulnerability exists in SyroTech SY-GPON-1110-WDONT Router due to storing of default username and password credentials in plaintext within the router's firmware/ database. An attacker with physical access could exploit this by extracting the firmware and reverse engineer the binary data to access the plaintext default credentials on the vulnerable system.

Successful exploitation of this vulnerability could allow the attacker to gain unauthorized access to the targeted system.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-41690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-26T12:15:03Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability exists in SyroTech SY-GPON-1110-WDONT Router due to storing of default username and password credentials in plaintext within the router\u0027s firmware/ database. An attacker with physical access could exploit this by extracting the firmware and reverse engineer the binary data to access the plaintext default credentials on the vulnerable system.\n\nSuccessful exploitation of this vulnerability could allow the attacker to gain unauthorized access to the targeted system.",
  "id": "GHSA-g5wh-4vxr-qmjg",
  "modified": "2024-08-05T21:31:19Z",
  "published": "2024-07-26T12:35:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41690"
    },
    {
      "type": "WEB",
      "url": "https://cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES01\u0026VLCODE=CIVN-2024-0225"
    },
    {
      "type": "WEB",
      "url": "https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES01\u0026VLCODE=CIVN-2024-0225"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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-G5XV-MHGM-V5F6

Vulnerability from github – Published: 2026-09-22 20:36 – Updated: 2026-09-22 20:36
VLAI
Summary
MCP Atlassian: OAuth fallback token storage writes plaintext access and refresh tokens with group-readable permissions
Details

Summary

When OAuth tokens are saved, MCP Atlassian always writes a plaintext fallback copy under ~/.mcp-atlassian/oauth-<client_id>.json. The fallback file is created with the process default umask rather than restrictive permissions. In this environment the file was created as mode 0664, exposing access and refresh tokens to same-group local users and any process that can read the home directory.

Details

OAuthConfig._save_tokens() stores OAuth token data in keyring, but it also unconditionally maintains a plaintext file fallback for backwards compatibility in src/mcp_atlassian/utils/oauth.py:350-386. If keyring saving fails it also falls back to the same file path in src/mcp_atlassian/utils/oauth.py:387-391.

The fallback writer creates ~/.mcp-atlassian and then writes oauth-<client_id>.json with a normal open(token_path, "w") call in src/mcp_atlassian/utils/oauth.py:392-420. No mode=0o600, os.open(..., 0o600), chmod, or owner-only directory permission is applied. The file contains both access_token and refresh_token (src/mcp_atlassian/utils/oauth.py:360-367) and is later loaded from the same plaintext path in src/mcp_atlassian/utils/oauth.py:450-470.

The security policy warns that OAuth client credentials and secrets should not be exposed (SECURITY.md:39-44), but the current implementation creates a persistent plaintext token copy even when keyring succeeds.

PoC

The following safe local proof uses a temporary HOME and mocked keyring writes. It creates and deletes only temporary files.

uv run python - <<'PY'
import json, os, shutil, stat, tempfile
from pathlib import Path
from unittest.mock import patch
from mcp_atlassian.utils.oauth import OAuthConfig

home = tempfile.mkdtemp(prefix='mcp-atlassian-oauth-poc-')
old_home = os.environ.get('HOME')
os.environ['HOME'] = home
try:
    cfg = OAuthConfig(client_id='poc-client', client_secret='client-secret', redirect_uri='http://localhost/callback', scope='offline_access', cloud_id='cloud-id')
    cfg.access_token = 'poc-access-token'
    cfg.refresh_token = 'poc-refresh-token'
    cfg.expires_at = 2000000000
    with patch('keyring.set_password', return_value=None):
        cfg._save_tokens()
    token_file = Path(home) / '.mcp-atlassian' / 'oauth-poc-client.json'
    mode = stat.S_IMODE(token_file.stat().st_mode)
    data = json.loads(token_file.read_text())
    print(json.dumps({
        'token_file_exists': token_file.exists(),
        'token_file_mode_octal': oct(mode),
        'contains_access_token': data.get('access_token') == 'poc-access-token',
        'contains_refresh_token': data.get('refresh_token') == 'poc-refresh-token',
        'token_file_path': str(token_file),
    }, indent=2, sort_keys=True))
finally:
    if old_home is not None:
        os.environ['HOME'] = old_home
    else:
        os.environ.pop('HOME', None)
    shutil.rmtree(home)
PY

Observed output from this environment:

{
  "contains_access_token": true,
  "contains_refresh_token": true,
  "token_file_exists": true,
  "token_file_mode_octal": "0o664",
  "token_file_path": "/tmp/mcp-atlassian-oauth-poc-9m9wvktp/.mcp-atlassian/oauth-poc-client.json"
}

The proof confirms that a plaintext file containing both access and refresh tokens is created and is not owner-only.

Impact

A local user, container sidecar, compromised dependency, backup job, or other process with filesystem read access to the account's home directory can recover OAuth access and refresh tokens. Refresh tokens can allow continued Atlassian API access until revoked or expired, depending on the OAuth app and token policy. In shared hosts, Kubernetes volumes, developer workstations, and CI runners, this can lead to persistent Atlassian account compromise.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77250"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:36:34Z",
    "nvd_published_at": "2026-09-22T18:17:17Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWhen OAuth tokens are saved, MCP Atlassian always writes a plaintext fallback copy under `~/.mcp-atlassian/oauth-\u003cclient_id\u003e.json`. The fallback file is created with the process default umask rather than restrictive permissions. In this environment the file was created as mode `0664`, exposing access and refresh tokens to same-group local users and any process that can read the home directory.\n\n### Details\n\n`OAuthConfig._save_tokens()` stores OAuth token data in keyring, but it also unconditionally maintains a plaintext file fallback for backwards compatibility in `src/mcp_atlassian/utils/oauth.py:350-386`. If keyring saving fails it also falls back to the same file path in `src/mcp_atlassian/utils/oauth.py:387-391`.\n\nThe fallback writer creates `~/.mcp-atlassian` and then writes `oauth-\u003cclient_id\u003e.json` with a normal `open(token_path, \"w\")` call in `src/mcp_atlassian/utils/oauth.py:392-420`. No `mode=0o600`, `os.open(..., 0o600)`, `chmod`, or owner-only directory permission is applied. The file contains both `access_token` and `refresh_token` (`src/mcp_atlassian/utils/oauth.py:360-367`) and is later loaded from the same plaintext path in `src/mcp_atlassian/utils/oauth.py:450-470`.\n\nThe security policy warns that OAuth client credentials and secrets should not be exposed (`SECURITY.md:39-44`), but the current implementation creates a persistent plaintext token copy even when keyring succeeds.\n\n### PoC\n\nThe following safe local proof uses a temporary `HOME` and mocked keyring writes. It creates and deletes only temporary files.\n\n```bash\nuv run python - \u003c\u003c\u0027PY\u0027\nimport json, os, shutil, stat, tempfile\nfrom pathlib import Path\nfrom unittest.mock import patch\nfrom mcp_atlassian.utils.oauth import OAuthConfig\n\nhome = tempfile.mkdtemp(prefix=\u0027mcp-atlassian-oauth-poc-\u0027)\nold_home = os.environ.get(\u0027HOME\u0027)\nos.environ[\u0027HOME\u0027] = home\ntry:\n    cfg = OAuthConfig(client_id=\u0027poc-client\u0027, client_secret=\u0027client-secret\u0027, redirect_uri=\u0027http://localhost/callback\u0027, scope=\u0027offline_access\u0027, cloud_id=\u0027cloud-id\u0027)\n    cfg.access_token = \u0027poc-access-token\u0027\n    cfg.refresh_token = \u0027poc-refresh-token\u0027\n    cfg.expires_at = 2000000000\n    with patch(\u0027keyring.set_password\u0027, return_value=None):\n        cfg._save_tokens()\n    token_file = Path(home) / \u0027.mcp-atlassian\u0027 / \u0027oauth-poc-client.json\u0027\n    mode = stat.S_IMODE(token_file.stat().st_mode)\n    data = json.loads(token_file.read_text())\n    print(json.dumps({\n        \u0027token_file_exists\u0027: token_file.exists(),\n        \u0027token_file_mode_octal\u0027: oct(mode),\n        \u0027contains_access_token\u0027: data.get(\u0027access_token\u0027) == \u0027poc-access-token\u0027,\n        \u0027contains_refresh_token\u0027: data.get(\u0027refresh_token\u0027) == \u0027poc-refresh-token\u0027,\n        \u0027token_file_path\u0027: str(token_file),\n    }, indent=2, sort_keys=True))\nfinally:\n    if old_home is not None:\n        os.environ[\u0027HOME\u0027] = old_home\n    else:\n        os.environ.pop(\u0027HOME\u0027, None)\n    shutil.rmtree(home)\nPY\n```\n\nObserved output from this environment:\n\n```json\n{\n  \"contains_access_token\": true,\n  \"contains_refresh_token\": true,\n  \"token_file_exists\": true,\n  \"token_file_mode_octal\": \"0o664\",\n  \"token_file_path\": \"/tmp/mcp-atlassian-oauth-poc-9m9wvktp/.mcp-atlassian/oauth-poc-client.json\"\n}\n```\n\nThe proof confirms that a plaintext file containing both access and refresh tokens is created and is not owner-only.\n\n### Impact\n\nA local user, container sidecar, compromised dependency, backup job, or other process with filesystem read access to the account\u0027s home directory can recover OAuth access and refresh tokens. Refresh tokens can allow continued Atlassian API access until revoked or expired, depending on the OAuth app and token policy. In shared hosts, Kubernetes volumes, developer workstations, and CI runners, this can lead to persistent Atlassian account compromise.",
  "id": "GHSA-g5xv-mhgm-v5f6",
  "modified": "2026-09-22T20:36:34Z",
  "published": "2026-09-22T20:36:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-g5xv-mhgm-v5f6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77250"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sooperset/mcp-atlassian"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MCP Atlassian: OAuth fallback token storage writes plaintext access and refresh tokens with group-readable permissions"
}

GHSA-G644-679Q-JJCF

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

In JetBrains PyCharm 2019.2.5 and 2019.3 on Windows, Apple Notarization Service credentials were included. This is fixed in 2019.2.6 and 2019.3.3.

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-2020-11694"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312",
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-10T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In JetBrains PyCharm 2019.2.5 and 2019.3 on Windows, Apple Notarization Service credentials were included. This is fixed in 2019.2.6 and 2019.3.3.",
  "id": "GHSA-g644-679q-jjcf",
  "modified": "2022-05-24T17:13:59Z",
  "published": "2022-05-24T17:13:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11694"
    },
    {
      "type": "WEB",
      "url": "https://blog.jetbrains.com/blog/2020/04/22/jetbrains-security-bulletin-q1-2020"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/rubyroobs/5d273895512df5b86d5e7e1a703c8028"
    },
    {
      "type": "WEB",
      "url": "https://twitter.com/_ruby/status/1234457530790600704"
    }
  ],
  "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-G65G-FMCP-4W68

Vulnerability from github – Published: 2025-04-02 15:31 – Updated: 2025-04-02 22:46
VLAI
Summary
Jenkins monitor-remote-job Plugin Stores Passwords Unencrypted
Details

Jenkins monitor-remote-job Plugin 1.0 stores passwords unencrypted in job config.xml files on the Jenkins controller as part of its configuration.

These passwords can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system.

As of publication of this advisory, there is no fix.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.ukiuni.monitor-remote-job-plugin:monitor-remote-job"
      },
      "versions": [
        "1.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-31725"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-02T22:46:28Z",
    "nvd_published_at": "2025-04-02T15:16:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins monitor-remote-job Plugin 1.0 stores passwords unencrypted in job `config.xml` files on the Jenkins controller as part of its configuration.\n\nThese passwords can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system.\n\nAs of publication of this advisory, there is no fix.",
  "id": "GHSA-g65g-fmcp-4w68",
  "modified": "2025-04-02T22:46:28Z",
  "published": "2025-04-02T15:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31725"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/monitor-remote-job-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2025-04-02/#SECURITY-3539"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins monitor-remote-job Plugin Stores Passwords Unencrypted"
}

GHSA-G73W-WV28-QW49

Vulnerability from github – Published: 2023-01-01 09:30 – Updated: 2023-01-09 15:30
VLAI
Details

An issue was discovered in WeCube Platform 3.2.2. Cleartext passwords are displayed in the configuration for terminal plugins.

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-2022-37785"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-01T08:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in WeCube Platform 3.2.2. Cleartext passwords are displayed in the configuration for terminal plugins.",
  "id": "GHSA-g73w-wv28-qw49",
  "modified": "2023-01-09T15:30:23Z",
  "published": "2023-01-01T09:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37785"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WeBankPartners/wecube-platform/issues/2329"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WeBankPartners/wecube-plugins-terminal"
    }
  ],
  "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-G7J7-H4Q8-8W2F

Vulnerability from github – Published: 2022-09-23 18:11 – Updated: 2022-09-23 18:11
VLAI
Summary
Rancher API and cluster.management.cattle.io object vulnerable to plaintext storage and exposure of credentials
Details

Impact

An issue was discovered in Rancher versions up to and including 2.5.15 and 2.6.6 where sensitive fields, like passwords, API keys and Rancher's service account token (used to provision clusters), were stored in plaintext directly on Kubernetes objects like Clusters, for example cluster.management.cattle.io. Anyone with read access to those objects in the Kubernetes API could retrieve the plaintext version of those sensitive data.

The exposed credentials are visible in Rancher to authenticated Cluster Owners, Cluster Members, Project Owners, Project Members and User Base on the endpoints: - /v1/management.cattle.io.catalogs - /v1/management.cattle.io.cluster - /v1/management.cattle.io.clustertemplates - /v1/management.cattle.io.notifiers - /v1/project.cattle.io.sourcecodeproviderconfig - /k8s/clusters/local/apis/management.cattle.io/v3/catalogs - /k8s/clusters/local/apis/management.cattle.io/v3/clusters - /k8s/clusters/local/apis/management.cattle.io/v3/clustertemplates - /k8s/clusters/local/apis/management.cattle.io/v3/notifiers - /k8s/clusters/local/apis/project.cattle.io/v3/sourcecodeproviderconfigs

Sensitive fields are now stripped from Clusters and other objects and moved to a Secret before the object is stored. The Secret is retrieved when the credential is needed. For objects that existed before this security fix, a one-time migration happens on startup.

Important: - The exposure of Rancher's serviceAccountToken allows any standard user to escalate its privileges to cluster administrator in Rancher. - For the exposure of credentials not related to Rancher, the final impact severity for confidentiality, integrity and availability is dependent on the permissions that the leaked credentials have on their own services.

The fields that have been addressed by this security fix are:

  • Notifier.SMTPConfig.Password
  • Notifier.WechatConfig.Secret
  • Notifier.DingtalkConfig.Secret
  • Catalog.Spec.Password
  • SourceCodeProviderConfig.GithubPipelineConfig.ClientSecret
  • SourceCodeProviderConfig.GitlabPipelineConfig.ClientSecret
  • SourceCodeProviderConfig.BitbucketCloudPipelineConfig.ClientSecret
  • SourceCodeProviderConfig.BitbucketServerPipelineConfig.PrivateKey
  • Cluster.Spec.RancherKubernetesEngineConfig.BackupConfig.S3BackupConfig.SecretKey
  • Cluster.Spec.RancherKubernetesEngineConfig.PrivateRegistries.Password
  • Cluster.Spec.RancherKubernetesEngineConfig.Network.WeaveNetworkProvider.Password
  • Cluster.Spec.RancherKubernetesEngineConfig.CloudProvider.VsphereCloudProvider.Global.Password
  • Cluster.Spec.RancherKubernetesEngineConfig.CloudProvider.VsphereCloudProvider.VirtualCenter.Password
  • Cluster.Spec.RancherKubernetesEngineConfig.CloudProvider.OpenstackCloudProvider.Global.Password
  • Cluster.Spec.RancherKubernetesEngineConfig.CloudProvider.AzureCloudProvider.AADClientSecret
  • Cluster.Spec.RancherKubernetesEngineConfig.CloudProvider.AzureCloudProvider.AADClientCertPassword
  • Cluster.Status.ServiceAccountToken
  • ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.PrivateRegistries.Password
  • ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.Network.WeaveNetworkProvider.Password
  • ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.VsphereCloudProvider.Global.Password
  • ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.VsphereCloudProvider.VirtualCenter.Password
  • ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.OpenstackCloudProvider.Global.Password
  • ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.AzureCloudProvider.AADClientSecret
  • ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.AzureCloudProvider.AADClientCertPassword

Patches

Patched versions include releases 2.5.16, 2.6.7 and later versions.

After upgrading to a patched version, it is important to check for the SecretsMigrated condition on Clusters, ClusterTemplates, and Catalogs to confirm when secrets have been fully migrated off of those objects and the objects scoped within them (Notifiers and SourceCodeProviderConfigs).

Workarounds

Limit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions.

Important: - It is highly advised to rotate Rancher's serviceAccountToken. This rotation is not done by the version upgrade. Please see the helper script below. - The local and downstream clusters should be checked for potential unrecognized services (pods), users and API keys. - It is recommended to review for potential leaked credentials in this scenario, that are not directly related to Rancher, and to change them if deemed necessary.

The script available in rancherlabs/support-tools/rotate-tokens repository can be used as a helper to rotate the service account token (used to provision clusters). The script requires a valid Rancher API token, kubectl access to the local cluster and the jq command.

Credits

We would like to recognize and appreciate Florian Struck (from Continum AG) and Marco Stuurman (from Shock Media B.V.) for the responsible disclosure of this security issue.

For more information

If you have any questions or comments about this advisory: * Reach out to SUSE Rancher Security team for security related inquiries. * Open an issue in Rancher repository. * Verify our support matrix and product support lifecycle.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rancher/rancher"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0"
            },
            {
              "fixed": "2.5.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rancher/rancher"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.6.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-36782"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-23T18:11:28Z",
    "nvd_published_at": "2022-09-07T09:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nAn issue was discovered in Rancher versions up to and including 2.5.15 and 2.6.6 where sensitive fields, like passwords, API keys and Rancher\u0027s service account token (used to provision clusters), were stored in plaintext directly on Kubernetes objects like `Clusters`, for example `cluster.management.cattle.io`. Anyone with read access to those objects in the Kubernetes API could retrieve the plaintext version of those sensitive data.\n\nThe exposed credentials are visible in Rancher to authenticated `Cluster Owners`, `Cluster Members`, `Project Owners`, `Project Members` and `User Base` on the endpoints:\n- `/v1/management.cattle.io.catalogs`\n- `/v1/management.cattle.io.cluster`\n- `/v1/management.cattle.io.clustertemplates`\n- `/v1/management.cattle.io.notifiers`\n- `/v1/project.cattle.io.sourcecodeproviderconfig`\n- `/k8s/clusters/local/apis/management.cattle.io/v3/catalogs`\n- `/k8s/clusters/local/apis/management.cattle.io/v3/clusters`\n-  `/k8s/clusters/local/apis/management.cattle.io/v3/clustertemplates`\n- `/k8s/clusters/local/apis/management.cattle.io/v3/notifiers`\n- `/k8s/clusters/local/apis/project.cattle.io/v3/sourcecodeproviderconfigs`\n\nSensitive fields are now stripped from `Clusters` and other objects and moved to a `Secret` before the object is stored. The `Secret` is retrieved when the credential is needed. For objects that existed before this security fix, a one-time migration happens on startup.\n\n**Important:**\n- The exposure of Rancher\u0027s `serviceAccountToken` allows any standard user to escalate its privileges to cluster administrator in Rancher.\n- For the exposure of credentials not related to Rancher, the final impact severity for confidentiality, integrity and availability is dependent on the permissions that the leaked credentials have on their own services.\n\nThe fields that have been addressed by this security fix are:\n\n- `Notifier.SMTPConfig.Password`\n- `Notifier.WechatConfig.Secret`\n- `Notifier.DingtalkConfig.Secret`\n- `Catalog.Spec.Password`\n- `SourceCodeProviderConfig.GithubPipelineConfig.ClientSecret`\n- `SourceCodeProviderConfig.GitlabPipelineConfig.ClientSecret`\n- `SourceCodeProviderConfig.BitbucketCloudPipelineConfig.ClientSecret`\n- `SourceCodeProviderConfig.BitbucketServerPipelineConfig.PrivateKey`\n- `Cluster.Spec.RancherKubernetesEngineConfig.BackupConfig.S3BackupConfig.SecretKey`\n- `Cluster.Spec.RancherKubernetesEngineConfig.PrivateRegistries.Password`\n- `Cluster.Spec.RancherKubernetesEngineConfig.Network.WeaveNetworkProvider.Password`\n- `Cluster.Spec.RancherKubernetesEngineConfig.CloudProvider.VsphereCloudProvider.Global.Password`\n- `Cluster.Spec.RancherKubernetesEngineConfig.CloudProvider.VsphereCloudProvider.VirtualCenter.Password`\n- `Cluster.Spec.RancherKubernetesEngineConfig.CloudProvider.OpenstackCloudProvider.Global.Password`\n- `Cluster.Spec.RancherKubernetesEngineConfig.CloudProvider.AzureCloudProvider.AADClientSecret`\n- `Cluster.Spec.RancherKubernetesEngineConfig.CloudProvider.AzureCloudProvider.AADClientCertPassword`\n- `Cluster.Status.ServiceAccountToken`\n- `ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.PrivateRegistries.Password`\n- `ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.Network.WeaveNetworkProvider.Password`\n- `ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.VsphereCloudProvider.Global.Password`\n- `ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.VsphereCloudProvider.VirtualCenter.Password`\n- `ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.OpenstackCloudProvider.Global.Password`\n- `ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.AzureCloudProvider.AADClientSecret`\n- `ClusterTemplate.Spec.ClusterConfig.RancherKubernetesEngineConfig.CloudProvider.AzureCloudProvider.AADClientCertPassword`\n\n### Patches\nPatched versions include releases 2.5.16, 2.6.7 and later versions.\n\nAfter upgrading to a patched version, it is important to check for the `SecretsMigrated` condition on `Clusters`, `ClusterTemplates`, and `Catalogs` to confirm when secrets have been fully migrated off of those objects and the objects scoped within them (`Notifiers` and `SourceCodeProviderConfigs`).\n\n### Workarounds\nLimit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions.\n\n**Important:**\n- It is highly advised to rotate Rancher\u0027s `serviceAccountToken`. This rotation is not done by the version upgrade. Please see the helper script below.\n- The local and downstream clusters should be checked for potential unrecognized services (pods), users and API keys.\n- It is recommended to review for potential leaked credentials in this scenario, that are not directly related to Rancher, and to change them if deemed necessary.\n\nThe script available in [rancherlabs/support-tools/rotate-tokens](https://github.com/rancherlabs/support-tools/blob/master/rotate-tokens) repository can be used as a helper to rotate the service account token (used to provision clusters). The script requires a valid Rancher API token, `kubectl` access to the `local` cluster and the `jq` command.\n\n### Credits\nWe would like to recognize and appreciate Florian Struck (from [Continum AG](https://www.continum.net/)) and [Marco Stuurman](https://github.com/fe-ax) (from [Shock Media B.V.](https://www.shockmedia.nl)) for the responsible disclosure of this security issue.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.\n* Open an issue in [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.\n* Verify our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).",
  "id": "GHSA-g7j7-h4q8-8w2f",
  "modified": "2022-09-23T18:11:28Z",
  "published": "2022-09-23T18:11:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rancher/rancher/security/advisories/GHSA-g7j7-h4q8-8w2f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36782"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=1193988"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rancher/rancher"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Rancher API and cluster.management.cattle.io object vulnerable to plaintext storage and exposure of credentials"
}

GHSA-G874-PFG5-PJ33

Vulnerability from github – Published: 2024-07-06 06:30 – Updated: 2024-07-06 06:30
VLAI
Details

The OpenAI ChatGPT app before 2024-07-05 for macOS opts out of the sandbox, and stores conversations in cleartext in a location accessible to other apps.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-40594"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-06T05:15:09Z",
    "severity": "LOW"
  },
  "details": "The OpenAI ChatGPT app before 2024-07-05 for macOS opts out of the sandbox, and stores conversations in cleartext in a location accessible to other apps.",
  "id": "GHSA-g874-pfg5-pj33",
  "modified": "2024-07-06T06:30:52Z",
  "published": "2024-07-06T06:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40594"
    },
    {
      "type": "WEB",
      "url": "https://arstechnica.com/ai/2024/07/chatgpts-much-heralded-mac-app-was-storing-conversations-as-plain-text"
    },
    {
      "type": "WEB",
      "url": "https://www.theverge.com/2024/7/3/24191636/openai-chatgpt-mac-app-conversations-plain-text"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Implementation System Configuration Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]

Mitigation
Implementation System Configuration Operation

In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.

CAPEC-37: Retrieve Embedded Sensitive Data

An attacker examines a target system to find sensitive data that has been embedded within it. This information can reveal confidential contents, such as account numbers or individual keys/credentials that can be used as an intermediate step in a larger attack.

← Back to the CWE list