Common Weakness Enumeration

CWE-312

Allowed

Cleartext Storage of Sensitive Information

Abstraction: Base · Status: Draft

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

1155 vulnerabilities reference this CWE, most recent first.

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."

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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"
    }
  ]
}

GHSA-G96F-P224-QWCP

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

IBM Spectrum Protect Plus 10.1.0 through 10.1.6 may include sensitive information in its URLs increasing the risk of such information being caputured by an attacker. IBM X-Force ID: 193654.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-5018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-08T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "IBM Spectrum Protect Plus 10.1.0 through 10.1.6 may include sensitive information in its URLs increasing the risk of such information being caputured by an attacker. IBM X-Force ID: 193654.",
  "id": "GHSA-g96f-p224-qwcp",
  "modified": "2022-05-24T17:38:22Z",
  "published": "2022-05-24T17:38:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5018"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/193654"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6398754"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GC3J-M753-J4HJ

Vulnerability from github – Published: 2024-08-28 09:30 – Updated: 2024-08-28 09:30
VLAI
Details

A vulnerability identified in storing and reusing information in Advance Authentication. This issue can lead to leakage of sensitive data to unauthorized user. The issue affects NetIQ Advance Authentication before 6.3.5.1

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-22509"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-28T07:15:04Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability identified in storing and reusing information in Advance Authentication. This issue can lead to leakage of sensitive data to unauthorized user. The issue affects NetIQ Advance Authentication before 6.3.5.1",
  "id": "GHSA-gc3j-m753-j4hj",
  "modified": "2024-08-28T09:30:34Z",
  "published": "2024-08-28T09:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22509"
    },
    {
      "type": "WEB",
      "url": "https://www.netiq.com/documentation/advanced-authentication-63/advanced-authentication-releasenotes-6351/data/advanced-authentication-releasenotes-6351.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:L",
      "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.