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.
1017 vulnerabilities reference this CWE, most recent first.
GHSA-H34R-JXQM-QGPR
Vulnerability from github – Published: 2025-07-01 17:35 – Updated: 2025-07-01 17:35Summary
Certs generated by v4 contain their private key.
Details
Background
Recently, I encountered an API in Go that’s easy to misuse: sha512.Sum384 and sha512.New384().Sum look very similar and behave very differently. https://go.dev/play/p/kDCqqoYk84k demonstrates this. I want to discuss extending static analysis to detect this case with the go community, but before I do that, I want to make a best-effort pass at open-source projects to fix the existing bugs. I figured that if there were any vulnerabilities out there, they would be easy to find once that discussion begins, so it’s better to address them early.
This work is a hobby project and has no affiliation with my employer, so I may be slow to respond due to existing commitments.
PoC
https://go.dev/play/p/vSW0U3Hq4qk
Impact
This code (cert.NewLeaf) generates certs with the SubjectKeyId set to sha512.New384().Sum(/* private */ key).
If a cert which was generated by cert.NewLeaf is transferred over the network in plaintext, as is often the case in TLS handshakes, an attacker listening on that network may sniff the cert and trivially extract the private key from it. This applies to client and server TLS certs generated by vulnerable versions of this library.
Getting the server cert and its key would only require performing a TLS handshake (with a matching SNI) with the server. At that point, the attacker could impersonate the server.
Similarly, getting the client cert and its key would require getting the client to perform a TLS handshake against an attacker-controlled server. At that point, an attacker could impersonate the client.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.0.3"
},
"package": {
"ecosystem": "Go",
"name": "github.com/juju/utils/v4/cert"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-6224"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-01T17:35:16Z",
"nvd_published_at": "2025-07-01T11:15:21Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nCerts generated by v4 contain their private key.\n\n## Details\n\n### Background\n\nRecently, I encountered an API in Go that\u2019s easy to misuse: sha512.Sum384 and sha512.New384().Sum look very similar and behave very differently. https://go.dev/play/p/kDCqqoYk84k demonstrates this. I want to discuss extending static analysis to detect this case with the go community, but before I do that, I want to make a best-effort pass at open-source projects to fix the existing bugs. I figured that if there were any vulnerabilities out there, they would be easy to find once that discussion begins, so it\u2019s better to address them early. \n\nThis work is a hobby project and has no affiliation with my employer, so I may be slow to respond due to existing commitments. \n\n### PoC\n\nhttps://go.dev/play/p/vSW0U3Hq4qk\n\n### Impact\n\n[This code](https://github.com/juju/utils/blob/0141ef0ee74a0cac603c5c9e4aff194008722f41/cert/cert.go#L120) (cert.NewLeaf) generates certs with the SubjectKeyId set to `sha512.New384().Sum(/* private */ key)`.\n\nIf a cert which was generated by cert.NewLeaf is transferred over the network in plaintext, as is often the case in TLS handshakes, an attacker listening on that network may sniff the cert and trivially extract the private key from it. This applies to client and server TLS certs generated by vulnerable versions of this library.\n\nGetting the server cert and its key would only require performing a TLS handshake (with a matching SNI) with the server. At that point, the attacker could impersonate the server.\n\nSimilarly, getting the client cert and its key would require getting the client to perform a TLS handshake against an attacker-controlled server. At that point, an attacker could impersonate the client.",
"id": "GHSA-h34r-jxqm-qgpr",
"modified": "2025-07-01T17:35:16Z",
"published": "2025-07-01T17:35:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/juju/utils/security/advisories/GHSA-h34r-jxqm-qgpr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6224"
},
{
"type": "WEB",
"url": "https://github.com/juju/utils/commit/766f27d7bcd10433453a9764509a864c17a46a76"
},
{
"type": "PACKAGE",
"url": "https://github.com/juju/utils"
},
{
"type": "WEB",
"url": "https://github.com/juju/utils/releases/tag/v4.0.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "juju/utils leaks private key in certs"
}
GHSA-H3QR-39J9-4R5V
Vulnerability from github – Published: 2023-05-01 13:42 – Updated: 2023-05-01 13:42Impact
This vulnerability impacts GitHub workflows using the Gradle Build Action that have executed the Gradle Build Tool with the configuration cache enabled, potentially exposing secrets configured for the repository.
Secrets configured for GitHub Actions are normally passed to the Gradle Build Tool via environment variables. Due to the way that the Gradle Build Tool records these environment variables, they may be persisted into an entry in the GitHub Actions cache. This data stored in the GitHub Actions cache can be read by a GitHub Actions workflow running in an untrusted context, such as that running for a Pull Request submitted by a developer via a repository fork.
This vulnerability was discovered internally through code review, and we have not seen any evidence of it being exploited in the wild. However, in addition to upgrading the Gradle Build Action, you should delete any potentially vulnerable cache entries and may choose to rotate any potentially affected secrets (see Remediation).
Patches
Gradle Build Action v2.4.2 (and newer) no longer save this sensitive data for later use, preventing ongoing leakage of secrets via the GitHub Actions Cache. We strongly recommend that all users of the Gradle Build Action upgrade to v2.4.2 (or simply v2) immediately.
Remediation
While upgrading to the latest version of the Gradle Build Action will prevent leakage of secrets going forward, additional actions may be required due to current or previous GitHub Actions Cache entries containing this information.
Current cache entries will remain vulnerable until they are forcibly deleted or they expire naturally after 7 days of not being used. Potentially vulnerable entries can be easily identified in the GitHub UI by searching for a cache entry with key matching configuration-cache-*. We recommend that users of the Gradle Build Action inspect their list of cache entries and manually delete any that match this pattern.
While we have not seen any evidence of this vulnerability being exploited, we recommend cycling any repository secrets if you cannot be certain that these have not been compromised. Compromise could occur if you run a GitHub Actions workflow for a pull request attempting to exploit this data. Warning signs to look for in a pull request include: - Making changes to GitHub Actions workflow files in a way that may attempt to read/extract data from the Gradle User Home or /.gradle directories. - Making changes to Gradle build files or other executable files that may be invoked by a GitHub Actions workflow, in a way that may attempt to read/extract information from these locations.
Workarounds
We strongly recommend that all users upgrade to the latest version of the Gradle Build Action as soon as possible, and delete any potentially vulnerable cache entries from the GitHub Actions cache (see Remediation).
If for some reason this is not possible, users can limit the impact of this vulnerability:
- If the Gradle project does not opt-in to using the configuration cache, then it is not vulnerable.
- If the Gradle project does opt-in to using the configuration-cache by default, then the --no-configuration-cache command-line argument can be used to disable this feature in a GitHub Actions workflow.
In any case, we recommend that users carefully inspect any pull request before approving the execution of GitHub Actions workflows. It may be prudent to require approval for all PRs from external contributors, as described here.
{
"affected": [
{
"package": {
"ecosystem": "GitHub Actions",
"name": "gradle/gradle-build-action"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-30853"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-312"
],
"github_reviewed": true,
"github_reviewed_at": "2023-05-01T13:42:44Z",
"nvd_published_at": "2023-04-28T16:15:10Z",
"severity": "HIGH"
},
"details": "### Impact\n\nThis vulnerability impacts GitHub workflows using the [Gradle Build Action](https://github.com/marketplace/actions/gradle-build-action) that have executed the Gradle Build Tool with the [configuration cache](https://docs.gradle.org/current/userguide/configuration_cache.html) enabled, potentially exposing secrets configured for the repository.\n\nSecrets configured for GitHub Actions are normally passed to the Gradle Build Tool via environment variables. Due to the way that the Gradle Build Tool records these environment variables, they may be persisted into an entry in the GitHub Actions cache. This data stored in the GitHub Actions cache can be read by a GitHub Actions workflow running in an untrusted context, such as that running for a Pull Request submitted by a developer via a repository fork.\n\nThis vulnerability was discovered internally through code review, and we have not seen any evidence of it being exploited in the wild. However, in addition to upgrading the Gradle Build Action, you should delete any potentially vulnerable cache entries and may choose to rotate any potentially affected secrets ([see Remediation](#Remediation)).\n\n### Patches\n\n[Gradle Build Action v2.4.2](https://github.com/gradle/gradle-build-action/releases/tag/v2.4.2) (and newer) no longer save this sensitive data for later use, preventing ongoing leakage of secrets via the GitHub Actions Cache. We strongly recommend that all users of the Gradle Build Action upgrade to `v2.4.2` (or simply `v2`) immediately.\n\n### Remediation\n\nWhile upgrading to the latest version of the Gradle Build Action will prevent leakage of secrets going forward, additional actions may be required due to current or previous GitHub Actions Cache entries containing this information.\n\nCurrent cache entries will remain vulnerable until they are forcibly deleted or they expire naturally after 7 days of not being used. Potentially vulnerable entries can be easily identified in the GitHub UI by searching for a cache entry with key matching `configuration-cache-*`. We recommend that users of the Gradle Build Action inspect their list of cache entries and [manually delete any that match this pattern](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#deleting-cache-entries).\n\nWhile we have not seen any evidence of this vulnerability being exploited, we recommend cycling any repository secrets if you cannot be certain that these have not been compromised. Compromise could occur if you run a GitHub Actions workflow for a pull request attempting to exploit this data. \nWarning signs to look for in a pull request include:\n- Making changes to GitHub Actions workflow files in a way that may attempt to read/extract data from the Gradle User Home or \u003cproject-root\u003e/.gradle directories.\n- Making changes to Gradle build files or other executable files that may be invoked by a GitHub Actions workflow, in a way that may attempt to read/extract information from these locations.\n\n### Workarounds\n\nWe strongly recommend that all users upgrade to the latest version of the Gradle Build Action as soon as possible, and delete any potentially vulnerable cache entries from the GitHub Actions cache ([see Remediation](#Remediation)). \n\nIf for some reason this is not possible, users can limit the impact of this vulnerability:\n- If the Gradle project does not opt-in to using the configuration cache, then it is not vulnerable. \n- If the Gradle project does opt-in to using the configuration-cache by default, then the `--no-configuration-cache` command-line argument can be used to disable this feature in a GitHub Actions workflow.\n\nIn any case, we recommend that users carefully inspect any pull request before approving the execution of GitHub Actions workflows. It may be prudent to require approval for all PRs from external contributors, as described [here](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#controlling-changes-from-forks-to-workflows-in-public-repositories).",
"id": "GHSA-h3qr-39j9-4r5v",
"modified": "2023-05-01T13:42:44Z",
"published": "2023-05-01T13:42:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gradle/gradle-build-action/security/advisories/GHSA-h3qr-39j9-4r5v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30853"
},
{
"type": "PACKAGE",
"url": "https://github.com/gradle/gradle-build-action"
},
{
"type": "WEB",
"url": "https://github.com/gradle/gradle-build-action/releases/tag/v2.4.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Data written to GitHub Actions Cache may expose secrets"
}
GHSA-H3WH-323M-4H77
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02In multiple managed switches by WAGO in different versions the webserver cookies of the web based UI contain user credentials.
{
"affected": [],
"aliases": [
"CVE-2021-20995"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-13T14:15:00Z",
"severity": "HIGH"
},
"details": "In multiple managed switches by WAGO in different versions the webserver cookies of the web based UI contain user credentials.",
"id": "GHSA-h3wh-323m-4h77",
"modified": "2022-05-24T19:02:22Z",
"published": "2022-05-24T19:02:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20995"
},
{
"type": "WEB",
"url": "https://cert.vde.com/en-us/advisories/vde-2021-013"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-H4JV-267R-4GXQ
Vulnerability from github – Published: 2022-04-12 00:00 – Updated: 2022-04-19 00:01AVEVA System Platform 2020 stores sensitive information in cleartext, which may allow access to an attacker or a low-privileged user.
{
"affected": [],
"aliases": [
"CVE-2022-0835"
],
"database_specific": {
"cwe_ids": [
"CWE-312",
"CWE-316"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-11T20:15:00Z",
"severity": "MODERATE"
},
"details": "AVEVA System Platform 2020 stores sensitive information in cleartext, which may allow access to an attacker or a low-privileged user.",
"id": "GHSA-h4jv-267r-4gxq",
"modified": "2022-04-19T00:01:25Z",
"published": "2022-04-12T00:00:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0835"
},
{
"type": "WEB",
"url": "https://www.aveva.com/content/dam/aveva/documents/support/cyber-security-updates/SecurityBulletin_AVEVA-2021-007.pdf"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-067-02"
}
],
"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-H528-F7W4-RG4J
Vulnerability from github – Published: 2022-05-24 17:11 – Updated: 2023-04-26 21:30D-Link DSL-2875AL and DSL-2877AL devices through 1.00.05 are prone to information disclosure via a simple crafted request to index.asp on the web management server because of username_v and password_v variables.
{
"affected": [],
"aliases": [
"CVE-2019-15656"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-03-19T18:15:00Z",
"severity": "MODERATE"
},
"details": "D-Link DSL-2875AL and DSL-2877AL devices through 1.00.05 are prone to information disclosure via a simple crafted request to index.asp on the web management server because of username_v and password_v variables.",
"id": "GHSA-h528-f7w4-rg4j",
"modified": "2023-04-26T21:30:30Z",
"published": "2022-05-24T17:11:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15656"
},
{
"type": "WEB",
"url": "https://www.dlink.com/en/security-bulletin"
},
{
"type": "WEB",
"url": "https://www.trustwave.com/en-us/resources/security-resources/security-advisories/?fid=26165"
}
],
"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-H594-V489-8M9P
Vulnerability from github – Published: 2023-08-07 06:30 – Updated: 2024-04-04 06:35An issue was discovered in Fujitsu Software Infrastructure Manager (ISM) before 2.8.0.061. The ismsnap component (in this specific case at /var/log/fujitsu/ServerViewSuite/ism/FirmwareManagement/FirmwareManagement.log) allows insecure collection and storage of authorization credentials in cleartext. That occurs when users perform any ISM Firmware Repository Address setup test (Test the Connection), or regularly authorize against an already configured remote firmware repository site, as set up in ISM Firmware Repository Address. A privileged attacker is therefore able to potentially gather the associated ismsnap maintenance data, in the same manner as a trusted party allowed to export ismsnap data from ISM. The preconditions for an ISM installation to be generally vulnerable are that the Download Firmware (Firmware Repository Server) function is enabled and configured, and that the character \ (backslash) is used in a user credential (i.e., user/ID or password) of the remote proxy host / firmware repository server. NOTE: this may overlap CVE-2023-39379.
{
"affected": [],
"aliases": [
"CVE-2023-39903"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-07T05:15:09Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Fujitsu Software Infrastructure Manager (ISM) before 2.8.0.061. The ismsnap component (in this specific case at /var/log/fujitsu/ServerViewSuite/ism/FirmwareManagement/FirmwareManagement.log) allows insecure collection and storage of authorization credentials in cleartext. That occurs when users perform any ISM Firmware Repository Address setup test (Test the Connection), or regularly authorize against an already configured remote firmware repository site, as set up in ISM Firmware Repository Address. A privileged attacker is therefore able to potentially gather the associated ismsnap maintenance data, in the same manner as a trusted party allowed to export ismsnap data from ISM. The preconditions for an ISM installation to be generally vulnerable are that the Download Firmware (Firmware Repository Server) function is enabled and configured, and that the character \\ (backslash) is used in a user credential (i.e., user/ID or password) of the remote proxy host / firmware repository server. NOTE: this may overlap CVE-2023-39379.",
"id": "GHSA-h594-v489-8m9p",
"modified": "2024-04-04T06:35:30Z",
"published": "2023-08-07T06:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39903"
},
{
"type": "WEB",
"url": "https://security.ts.fujitsu.com/IndexDownload.asp?SoftwareGuid=a0131919-6d84-43b4-800e-d7f78200a70f"
},
{
"type": "WEB",
"url": "https://security.ts.fujitsu.com/ProductSecurity/content/Fujitsu-PSIRT-ISS-IS-2023-071410-Security-Notice.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H59C-HV3V-MJ8Q
Vulnerability from github – Published: 2026-06-27 00:30 – Updated: 2026-06-29 15:32Cleartext storage and exposure of WPA2 credentials, and missing authentication on the rr/wr memory read/write commands, in the unauthenticated UART debug console of the Tenda N300 F3 (V603) allow a physically proximate attacker to obtain stored WPA2 credentials in cleartext and to read or write arbitrary memory via the serial console.
{
"affected": [],
"aliases": [
"CVE-2026-38571"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-26T22:16:31Z",
"severity": "MODERATE"
},
"details": "Cleartext storage and exposure of WPA2 credentials, and missing authentication on the rr/wr memory read/write commands, in the unauthenticated UART debug console of the Tenda N300 F3 (V603) allow a physically proximate attacker to obtain stored WPA2 credentials in cleartext and to read or write arbitrary memory via the serial console.",
"id": "GHSA-h59c-hv3v-mj8q",
"modified": "2026-06-29T15:32:00Z",
"published": "2026-06-27T00:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-38571"
},
{
"type": "WEB",
"url": "https://github.com/ZEssaidi-CS/Vulnerability-research/tree/main/CVE-2026-38571"
}
],
"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"
}
]
}
GHSA-H5H4-CJWM-9G2F
Vulnerability from github – Published: 2022-04-30 18:18 – Updated: 2024-02-13 18:38Xitami 2.4 through 2.5 b4 stores the Administrator password in plaintext in the default.aut file, whose default permissions are world-readable, which allows remote attackers to gain privileges.
{
"affected": [],
"aliases": [
"CVE-2001-1481"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2001-12-31T05:00:00Z",
"severity": "HIGH"
},
"details": "Xitami 2.4 through 2.5 b4 stores the Administrator password in plaintext in the default.aut file, whose default permissions are world-readable, which allows remote attackers to gain privileges.",
"id": "GHSA-h5h4-cjwm-9g2f",
"modified": "2024-02-13T18:38:18Z",
"published": "2022-04-30T18:18:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2001-1481"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/7600"
},
{
"type": "WEB",
"url": "http://archives.neohapsis.com/archives/win2ksecadvice/2000-q4/0109.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/242375"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/3582"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H76G-VP43-8CW5
Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-07-13 00:01KDE Messagelib through 5.17.0 reveals cleartext of encrypted messages in some situations. Deleting an attachment of a decrypted encrypted message stored on a remote server (e.g., an IMAP server) causes KMail to upload the decrypted content of the message to the remote server. With a crafted message, a user could be tricked into decrypting an encrypted message and then deleting an attachment attached to this message. If the attacker has access to the messages stored on the email server, then the attacker could read the decrypted content of the encrypted message. This occurs in ViewerPrivate::deleteAttachment in messageviewer/src/viewer/viewer_p.cpp.
{
"affected": [],
"aliases": [
"CVE-2021-31855"
],
"database_specific": {
"cwe_ids": [
"CWE-312",
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-02T16:15:00Z",
"severity": "MODERATE"
},
"details": "KDE Messagelib through 5.17.0 reveals cleartext of encrypted messages in some situations. Deleting an attachment of a decrypted encrypted message stored on a remote server (e.g., an IMAP server) causes KMail to upload the decrypted content of the message to the remote server. With a crafted message, a user could be tricked into decrypting an encrypted message and then deleting an attachment attached to this message. If the attacker has access to the messages stored on the email server, then the attacker could read the decrypted content of the encrypted message. This occurs in ViewerPrivate::deleteAttachment in messageviewer/src/viewer/viewer_p.cpp.",
"id": "GHSA-h76g-vp43-8cw5",
"modified": "2022-07-13T00:01:25Z",
"published": "2022-05-24T19:03:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31855"
},
{
"type": "WEB",
"url": "https://github.com/KDE/messagelib/commit/3b5b171e91ce78b966c98b1292a1bcbc8d984799"
},
{
"type": "WEB",
"url": "https://kde.org/info/security/advisory-20210429-1.txt"
}
],
"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-H8VQ-X2W7-P2C6
Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03Some PON MDU devices of ZTE stored sensitive information in plaintext, and users with login authority can obtain it by inputing command. This affects: ZTE PON MDU device ZXA10 F821 V1.7.0P3T22, ZXA10 F822 V1.4.3T6, ZXA10 F819 V1.2.1T5, ZXA10 F832 V1.1.1T7, ZXA10 F839 V1.1.0T8, ZXA10 F809 V3.2.1T1, ZXA10 F822P V1.1.1T7, ZXA10 F832 V2.00.00.01
{
"affected": [],
"aliases": [
"CVE-2021-21734"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-28T12:15:00Z",
"severity": "MODERATE"
},
"details": "Some PON MDU devices of ZTE stored sensitive information in plaintext, and users with login authority can obtain it by inputing command. This affects: ZTE PON MDU device ZXA10 F821 V1.7.0P3T22, ZXA10 F822 V1.4.3T6, ZXA10 F819 V1.2.1T5, ZXA10 F832 V1.1.1T7, ZXA10 F839 V1.1.0T8, ZXA10 F809 V3.2.1T1, ZXA10 F822P V1.1.1T7, ZXA10 F832 V2.00.00.01",
"id": "GHSA-h8vq-x2w7-p2c6",
"modified": "2022-05-24T19:03:37Z",
"published": "2022-05-24T19:03:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21734"
},
{
"type": "WEB",
"url": "https://support.zte.com.cn/support/news/LoopholeInfoDetail.aspx?newsId=1015524"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.