CWE-312
AllowedCleartext 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.
1141 vulnerabilities reference this CWE, most recent first.
GHSA-G29V-5PWH-WXX4
Vulnerability from github – Published: 2023-01-26 21:30 – Updated: 2023-02-06 16:39Jenkins JIRA Pipeline Steps Plugin 2.0.165.v8846cf59f3db and earlier stores the private keys unencrypted in its global configuration file on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:jira-steps"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.0.165.v8846cf59f3db"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-24439"
],
"database_specific": {
"cwe_ids": [
"CWE-256",
"CWE-312"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-27T01:00:15Z",
"nvd_published_at": "2023-01-26T21:18:00Z",
"severity": "MODERATE"
},
"details": "Jenkins JIRA Pipeline Steps Plugin 2.0.165.v8846cf59f3db and earlier stores the private keys unencrypted in its global configuration file on the Jenkins controller where it can be viewed by users with access to the Jenkins controller file system.",
"id": "GHSA-g29v-5pwh-wxx4",
"modified": "2023-02-06T16:39:45Z",
"published": "2023-01-26T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24439"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2023-01-24/#SECURITY-2774"
}
],
"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"
}
],
"summary": "Plaintext Storage of a Password in Jenkins JIRA Pipeline Steps Plugin"
}
GHSA-G3FX-GVWR-W892
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-05-24 17:42Telegram before 7.4 (212543) Stable on macOS stores the local copy of self-destructed messages in a sandbox path, leading to sensitive information disclosure.
{
"affected": [],
"aliases": [
"CVE-2021-27205"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-12T08:15:00Z",
"severity": "MODERATE"
},
"details": "Telegram before 7.4 (212543) Stable on macOS stores the local copy of self-destructed messages in a sandbox path, leading to sensitive information disclosure.",
"id": "GHSA-g3fx-gvwr-w892",
"modified": "2022-05-24T17:42:08Z",
"published": "2022-05-24T17:42:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27205"
},
{
"type": "WEB",
"url": "https://www.inputzero.io/2020/12/telegram-privacy-fails-again.html"
},
{
"type": "WEB",
"url": "https://www.youtube.com/watch?v=Go-4srm_1fQ"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-G3V3-CPPQ-54CG
Vulnerability from github – Published: 2025-07-28 18:31 – Updated: 2025-07-28 18:31In JetBrains TeamCity before 2025.07 user credentials were stored in plain text in memory snapshots
{
"affected": [],
"aliases": [
"CVE-2025-54537"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-28T17:15:33Z",
"severity": "MODERATE"
},
"details": "In JetBrains TeamCity before 2025.07 user credentials were stored in plain text in memory snapshots",
"id": "GHSA-g3v3-cppq-54cg",
"modified": "2025-07-28T18:31:29Z",
"published": "2025-07-28T18:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54537"
},
{
"type": "WEB",
"url": "https://www.jetbrains.com/privacy-security/issues-fixed"
}
],
"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-G469-RX8Q-GP32
Vulnerability from github – Published: 2023-05-19 18:30 – Updated: 2024-04-04 04:15IBM InfoSphere Information Server 11.7 stores user credentials in plain clear text which can be read by a local user. IBM X-Force ID: 244373.
{
"affected": [],
"aliases": [
"CVE-2023-22878"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-19T16:15:10Z",
"severity": "MODERATE"
},
"details": "IBM InfoSphere Information Server 11.7 stores user credentials in plain clear text which can be read by a local user. IBM X-Force ID: 244373.",
"id": "GHSA-g469-rx8q-gp32",
"modified": "2024-04-04T04:15:21Z",
"published": "2023-05-19T18:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22878"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/244373"
},
{
"type": "WEB",
"url": "https://https://www.ibm.com/support/pages/node/6988155"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G472-F8CM-8X5F
Vulnerability from github – Published: 2023-04-12 18:30 – Updated: 2023-04-12 22:19Jenkins WSO2 Oauth Plugin 1.0 and earlier stores the WSO2 Oauth client secret unencrypted in the global config.xml file on the Jenkins controller as part of its configuration.
This client secret can be viewed by users with access to the Jenkins controller file system.
Additionally, the global configuration form does not mask the WSO2 Oauth client secret, increasing the potential for attackers to observe and capture it.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:wso2id-oauth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-30527"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": true,
"github_reviewed_at": "2023-04-12T22:19:04Z",
"nvd_published_at": "2023-04-12T18:15:00Z",
"severity": "LOW"
},
"details": "Jenkins WSO2 Oauth Plugin 1.0 and earlier stores the WSO2 Oauth client secret unencrypted in the global config.xml file on the Jenkins controller as part of its configuration.\n\nThis client secret can be viewed by users with access to the Jenkins controller file system.\n\nAdditionally, the global configuration form does not mask the WSO2 Oauth client secret, increasing the potential for attackers to observe and capture it.",
"id": "GHSA-g472-f8cm-8x5f",
"modified": "2023-04-12T22:19:04Z",
"published": "2023-04-12T18:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30527"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2023-04-12/#SECURITY-2992"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/04/13/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Jenkins WSO2 Oauth Plugin stores WSO2 Oauth client secret unencrypted in global config.xml file on Jenkins controller"
}
GHSA-G4G7-V7Q6-4XW8
Vulnerability from github – Published: 2022-05-24 16:55 – Updated: 2022-05-24 16:55In 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.
{
"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:32In 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.
{
"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"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."
{
"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:31This 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.
{
"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:36Summary
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.
{
"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"
}
Mitigation
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
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.