CWE-532
AllowedInsertion of Sensitive Information into Log File
Abstraction: Base · Status: Incomplete
The product writes sensitive information to a log file.
1744 vulnerabilities reference this CWE, most recent first.
GHSA-FC6M-C8V2-74Q6
Vulnerability from github – Published: 2024-05-07 21:31 – Updated: 2024-05-07 21:31IBM Watson CP4D Data Stores 4.0.0 through 4.8.4 stores potentially sensitive information in log files that could be read by a local user. IBM X-Force ID: 264838.
{
"affected": [],
"aliases": [
"CVE-2023-40694"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-07T21:15:08Z",
"severity": "MODERATE"
},
"details": "IBM Watson CP4D Data Stores 4.0.0 through 4.8.4 stores potentially sensitive information in log files that could be read by a local user. IBM X-Force ID: 264838.",
"id": "GHSA-fc6m-c8v2-74q6",
"modified": "2024-05-07T21:31:45Z",
"published": "2024-05-07T21:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40694"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/264838"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7150286"
}
],
"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-FC75-58R8-RM3H
Vulnerability from github – Published: 2023-10-19 15:50 – Updated: 2023-10-19 15:50Impact
A user with a limited-permission editor account for the Wagtail admin can make a direct URL request to the admin view that handles bulk actions on user accounts. While authentication rules prevent the user from making any changes, the error message discloses the display names of user accounts, and by modifying URL parameters, the user can retrieve the display name for any user. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.
Patches
Patched versions have been released as Wagtail 4.1.9 (LTS), 5.0.5 and 5.1.3. The fix is also included in Release Candidate 1 of the forthcoming Wagtail 5.2 release.
Workarounds
None.
Acknowledgements
Many thanks to @quyenheu for reporting this issue.
For more information
If you have any questions or comments about this advisory:
- Visit Wagtail's support channels
- Email us at security@wagtail.org (view our security policy for more information).
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "wagtail"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "wagtail"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0"
},
{
"fixed": "5.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "wagtail"
},
"ranges": [
{
"events": [
{
"introduced": "5.1.0"
},
{
"fixed": "5.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-45809"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-425",
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-19T15:50:58Z",
"nvd_published_at": "2023-10-19T19:15:15Z",
"severity": "LOW"
},
"details": "### Impact\n\nA user with a limited-permission editor account for the Wagtail admin can make a direct URL request to the admin view that handles bulk actions on user accounts. While authentication rules prevent the user from making any changes, the error message discloses the display names of user accounts, and by modifying URL parameters, the user can retrieve the display name for any user. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.\n\n### Patches\nPatched versions have been released as Wagtail 4.1.9 (LTS), 5.0.5 and 5.1.3. The fix is also included in Release Candidate 1 of the forthcoming Wagtail 5.2 release.\n\n### Workarounds\nNone.\n\n### Acknowledgements\nMany thanks to @quyenheu for reporting this issue.\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n* Visit Wagtail\u0027s [support channels](https://docs.wagtail.io/en/stable/support.html)\n* Email us at [security@wagtail.org](mailto:security@wagtail.org) (view our [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).",
"id": "GHSA-fc75-58r8-rm3h",
"modified": "2023-10-19T15:50:58Z",
"published": "2023-10-19T15:50:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/security/advisories/GHSA-fc75-58r8-rm3h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45809"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/commit/0bacd29473107d9d7f5b723a15a683449679756d"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/commit/2231f462c75dfe84307fb40577e8c2109a23b27e"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/commit/bc96aed6ac53f998b2f4c4bf97e2d4f5fe337e5b"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/wagtail/PYSEC-2023-219.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/wagtail/wagtail"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/releases/tag/v4.1.9"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/releases/tag/v5.0.5"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/releases/tag/v5.1.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Wagtail vulnerable to disclosure of user names via admin bulk action views"
}
GHSA-FCMH-QFXC-W685
Vulnerability from github – Published: 2026-04-08 00:07 – Updated: 2026-04-08 00:07Summary
When kube-router is configured with per-node BGP peer passwords using the kube-router.io/peer.passwords node annotation, and verbose logging is enabled (--v=2 or higher), the raw Kubernetes node annotation map is logged verbatim — including the base64-encoded BGP MD5 passwords. Anyone with access to kube-router's logs (via kubectl logs, log aggregation systems, or shared log dumps during debugging) can extract and decode the BGP peer passwords. The official troubleshooting documentation instructs users to collect logs at -v=2 before filing issues, making accidental disclosure during support interactions a realistic scenario.
Details
The vulnerability is at pkg/controllers/routing/network_routes_controller.go:1129:
// pkg/controllers/routing/network_routes_controller.go:1127-1133
// If the global routing peer is configured then peer with it
// else attempt to get peers from node specific BGP annotations.
if len(nrc.globalPeerRouters) == 0 {
klog.V(2).Infof("Attempting to construct peer configs from annotation: %+v", node.Annotations)
peerCfgs, err := bgpPeerConfigsFromAnnotations(
node.Annotations is of type map[string]string. This type does not implement fmt.Stringer, so %+v formatting dumps every key-value pair verbatim. When kube-router.io/peer.passwords is set on the node (the documented mechanism for providing per-node BGP MD5 passwords), its base64-encoded value appears in the log output.
The BGP peer password annotation is documented in docs/user-guide.md and has the constant:
// pkg/controllers/routing/network_routes_controller.go:59
peerPasswordAnnotation = "kube-router.io/peer.passwords"
Note that a password-safe String() method exists on PeerConfig and PeerConfigs in pkg/bgp/peer_config.go and is tested:
// pkg/bgp/peer_config.go:63-79
// Custom Stringer to prevent leaking passwords when printed
func (p PeerConfig) String() string {
// ...password field is intentionally omitted...
}
However, this protective method is never invoked by the vulnerable log statement, which dumps the raw annotation map before any parsing occurs. The password masking only applies after the annotation is parsed into PeerConfig structs.
The second log statement at line 1510 (klog.Infof("Peer config from %s annotation: %+v", peersAnnotation, peerConfigs)) is not vulnerable — peerConfigs is of type bgp.PeerConfigs which implements fmt.Stringer and correctly masks passwords.
The vulnerable path (bgpPeerConfigsFromIndividualAnnotations) is triggered when the kube-router.io/peers consolidated YAML annotation is not set — i.e., when operators use the older individual annotation format (kube-router.io/peer.ips, kube-router.io/peer.asns, kube-router.io/peer.passwords). This older format remains fully supported and documented.
PoC
Setup: Node has per-node BGP peer annotations including a password:
kubectl annotate node worker-1 \
kube-router.io/peer.ips=192.0.2.1 \
kube-router.io/peer.asns=65001 \
"kube-router.io/peer.passwords=$(echo -n 's3cr3t-bgp-p@ss' | base64)"
Trigger: Start kube-router with verbose logging (e.g., following troubleshooting documentation):
# As documented in docs/troubleshoot.md for debugging:
kube-router ... --v=2
Observe: In kube-router pod logs:
I0318 10:23:41.123456 1 network_routes_controller.go:1129] Attempting to construct peer configs from annotation:
map[
kube-router.io/peer.asns:65001
kube-router.io/peer.ips:192.0.2.1
kube-router.io/peer.passwords:czNjcjN0LWJncC1wQHNz <-- base64-encoded password
...other annotations...
]
Decode the password:
echo "czNjcjN0LWJncC1wQHNz" | base64 -d
# Output: s3cr3t-bgp-p@ss
Impact: With the decoded password and network adjacency to the BGP peer, an attacker can establish an unauthorized BGP session, inject routes, or disrupt legitimate BGP peering.
Impact
- BGP credential disclosure: BGP MD5 authentication passwords are exposed to anyone with access to kube-router log output
- BGP session hijacking: An attacker who obtains the password and has network-level access to a BGP neighbor can impersonate the kube-router node, injecting malicious routes into the BGP table
- Log forwarding risk: Log aggregation systems (Fluentd, Loki, Elastic, Splunk) typically have different and often broader access controls than Kubernetes RBAC. Passwords aggregated into these systems may be accessible to personnel without Kubernetes node access
- Support workflow exposure: The official troubleshooting documentation recommends collecting
--v=2logs before filing issues, creating a realistic path for passwords to be shared in bug reports or support tickets
Recommended Fix
Remove or redact the vulnerable log statement at line 1129. The diagnostic information it provides (confirming that annotation-based peer configuration is being used) can be conveyed without exposing credential values:
// Before (vulnerable):
klog.V(2).Infof("Attempting to construct peer configs from annotation: %+v", node.Annotations)
// After (safe):
klog.V(2).Infof("Attempting to construct peer configs from per-node annotations (kube-router.io/peer.ips, etc.)")
If full annotation content is needed for debugging (e.g., to show non-sensitive annotations), log a filtered version that explicitly excludes the password annotation:
// Safe alternative that preserves non-sensitive diagnostic info:
safeAnnotations := make(map[string]string)
for k, v := range node.Annotations {
if k != peerPasswordAnnotation {
safeAnnotations[k] = v
}
}
klog.V(2).Infof("Attempting to construct peer configs from annotations: %+v", safeAnnotations)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudnativelabs/kube-router/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0"
},
{
"last_affected": "2.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T00:07:53Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nWhen kube-router is configured with per-node BGP peer passwords using the `kube-router.io/peer.passwords` node annotation, and verbose logging is enabled (`--v=2` or higher), the raw Kubernetes node annotation map is logged verbatim \u2014 including the base64-encoded BGP MD5 passwords. Anyone with access to kube-router\u0027s logs (via `kubectl logs`, log aggregation systems, or shared log dumps during debugging) can extract and decode the BGP peer passwords. The official troubleshooting documentation instructs users to collect logs at `-v=2` before filing issues, making accidental disclosure during support interactions a realistic scenario.\n\n## Details\n\nThe vulnerability is at `pkg/controllers/routing/network_routes_controller.go:1129`:\n\n```go\n// pkg/controllers/routing/network_routes_controller.go:1127-1133\n// If the global routing peer is configured then peer with it\n// else attempt to get peers from node specific BGP annotations.\nif len(nrc.globalPeerRouters) == 0 {\n klog.V(2).Infof(\"Attempting to construct peer configs from annotation: %+v\", node.Annotations)\n peerCfgs, err := bgpPeerConfigsFromAnnotations(\n```\n\n`node.Annotations` is of type `map[string]string`. This type does not implement `fmt.Stringer`, so `%+v` formatting dumps every key-value pair verbatim. When `kube-router.io/peer.passwords` is set on the node (the documented mechanism for providing per-node BGP MD5 passwords), its base64-encoded value appears in the log output.\n\nThe BGP peer password annotation is documented in `docs/user-guide.md` and has the constant:\n\n```go\n// pkg/controllers/routing/network_routes_controller.go:59\npeerPasswordAnnotation = \"kube-router.io/peer.passwords\"\n```\n\nNote that a password-safe `String()` method exists on `PeerConfig` and `PeerConfigs` in `pkg/bgp/peer_config.go` and is tested:\n\n```go\n// pkg/bgp/peer_config.go:63-79\n// Custom Stringer to prevent leaking passwords when printed\nfunc (p PeerConfig) String() string {\n // ...password field is intentionally omitted...\n}\n```\n\nHowever, this protective method is never invoked by the vulnerable log statement, which dumps the raw annotation map before any parsing occurs. The password masking only applies after the annotation is parsed into `PeerConfig` structs.\n\nThe second log statement at line 1510 (`klog.Infof(\"Peer config from %s annotation: %+v\", peersAnnotation, peerConfigs)`) is **not vulnerable** \u2014 `peerConfigs` is of type `bgp.PeerConfigs` which implements `fmt.Stringer` and correctly masks passwords.\n\nThe vulnerable path (`bgpPeerConfigsFromIndividualAnnotations`) is triggered when the `kube-router.io/peers` consolidated YAML annotation is not set \u2014 i.e., when operators use the older individual annotation format (`kube-router.io/peer.ips`, `kube-router.io/peer.asns`, `kube-router.io/peer.passwords`). This older format remains fully supported and documented.\n\n## PoC\n\n**Setup**: Node has per-node BGP peer annotations including a password:\n```bash\nkubectl annotate node worker-1 \\\n kube-router.io/peer.ips=192.0.2.1 \\\n kube-router.io/peer.asns=65001 \\\n \"kube-router.io/peer.passwords=$(echo -n \u0027s3cr3t-bgp-p@ss\u0027 | base64)\"\n```\n\n**Trigger**: Start kube-router with verbose logging (e.g., following troubleshooting documentation):\n```bash\n# As documented in docs/troubleshoot.md for debugging:\nkube-router ... --v=2\n```\n\n**Observe**: In kube-router pod logs:\n```\nI0318 10:23:41.123456 1 network_routes_controller.go:1129] Attempting to construct peer configs from annotation:\nmap[\n kube-router.io/peer.asns:65001\n kube-router.io/peer.ips:192.0.2.1\n kube-router.io/peer.passwords:czNjcjN0LWJncC1wQHNz \u003c-- base64-encoded password\n ...other annotations...\n]\n```\n\n**Decode the password**:\n```bash\necho \"czNjcjN0LWJncC1wQHNz\" | base64 -d\n# Output: s3cr3t-bgp-p@ss\n```\n\n**Impact**: With the decoded password and network adjacency to the BGP peer, an attacker can establish an unauthorized BGP session, inject routes, or disrupt legitimate BGP peering.\n\n## Impact\n\n- **BGP credential disclosure**: BGP MD5 authentication passwords are exposed to anyone with access to kube-router log output\n- **BGP session hijacking**: An attacker who obtains the password and has network-level access to a BGP neighbor can impersonate the kube-router node, injecting malicious routes into the BGP table\n- **Log forwarding risk**: Log aggregation systems (Fluentd, Loki, Elastic, Splunk) typically have different and often broader access controls than Kubernetes RBAC. Passwords aggregated into these systems may be accessible to personnel without Kubernetes node access\n- **Support workflow exposure**: The official troubleshooting documentation recommends collecting `--v=2` logs before filing issues, creating a realistic path for passwords to be shared in bug reports or support tickets\n\n## Recommended Fix\n\nRemove or redact the vulnerable log statement at line 1129. The diagnostic information it provides (confirming that annotation-based peer configuration is being used) can be conveyed without exposing credential values:\n\n```go\n// Before (vulnerable):\nklog.V(2).Infof(\"Attempting to construct peer configs from annotation: %+v\", node.Annotations)\n\n// After (safe):\nklog.V(2).Infof(\"Attempting to construct peer configs from per-node annotations (kube-router.io/peer.ips, etc.)\")\n```\n\nIf full annotation content is needed for debugging (e.g., to show non-sensitive annotations), log a filtered version that explicitly excludes the password annotation:\n\n```go\n// Safe alternative that preserves non-sensitive diagnostic info:\nsafeAnnotations := make(map[string]string)\nfor k, v := range node.Annotations {\n if k != peerPasswordAnnotation {\n safeAnnotations[k] = v\n }\n}\nklog.V(2).Infof(\"Attempting to construct peer configs from annotations: %+v\", safeAnnotations)\n```",
"id": "GHSA-fcmh-qfxc-w685",
"modified": "2026-04-08T00:07:53Z",
"published": "2026-04-08T00:07:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudnativelabs/kube-router/security/advisories/GHSA-fcmh-qfxc-w685"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudnativelabs/kube-router"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "kube-router: BGP Peer Passwords Exposed in Logs at Verbose Logging Level"
}
GHSA-FCPF-28P8-7VXV
Vulnerability from github – Published: 2022-05-13 01:22 – Updated: 2022-05-13 01:22RSA Archer versions, prior to 6.5 SP2, contain an information exposure vulnerability. The database connection password may get logged in plain text in the RSA Archer log files. An authenticated malicious local user with access to the log files may obtain the exposed password to use it in further attacks.
{
"affected": [],
"aliases": [
"CVE-2019-3716"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-03-13T21:29:00Z",
"severity": "HIGH"
},
"details": "RSA Archer versions, prior to 6.5 SP2, contain an information exposure vulnerability. The database connection password may get logged in plain text in the RSA Archer log files. An authenticated malicious local user with access to the log files may obtain the exposed password to use it in further attacks.",
"id": "GHSA-fcpf-28p8-7vxv",
"modified": "2022-05-13T01:22:27Z",
"published": "2022-05-13T01:22:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3716"
},
{
"type": "WEB",
"url": "https://seclists.org/fulldisclosure/2019/Mar/19"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/107406"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FCW8-C2XC-6RFJ
Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2024-04-04 02:26In the PowerSchool Mobile application 1.1.8 for Android, the username and password are stored in the log during authentication, and may be available to attackers via logcat.
{
"affected": [],
"aliases": [
"CVE-2019-17396"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-15T21:15:00Z",
"severity": "CRITICAL"
},
"details": "In the PowerSchool Mobile application 1.1.8 for Android, the username and password are stored in the log during authentication, and may be available to attackers via logcat.",
"id": "GHSA-fcw8-c2xc-6rfj",
"modified": "2024-04-04T02:26:32Z",
"published": "2022-05-24T16:58:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17396"
},
{
"type": "WEB",
"url": "https://pastebin.com/9VBiRpAR"
}
],
"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-FGJC-2W92-Q899
Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-09 18:30An insertion of sensitive information into log file vulnerability [CWE-532] in FortiOS 7.4.0 through 7.4.3, 7.2.0 through 7.2.7, 7.0 all versions; FortiProxy 7.4.0 through 7.4.3, 7.2.0 through 7.2.11; FortiPAM 1.4 all versions, 1.3 all versions, 1.2 all versions, 1.1 all versions, 1.0 all versions and FortiSRA 1.4 all versions may allow a read-only administrator to retrieve API tokens of other administrators via observing REST API logs, if REST API logging is enabled (non-default configuration).
{
"affected": [],
"aliases": [
"CVE-2024-47570"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-09T18:15:47Z",
"severity": "MODERATE"
},
"details": "An insertion of sensitive information into log file vulnerability [CWE-532] in FortiOS 7.4.0 through 7.4.3, 7.2.0 through 7.2.7, 7.0 all versions; FortiProxy 7.4.0 through 7.4.3, 7.2.0 through 7.2.11; FortiPAM 1.4 all versions, 1.3 all versions, 1.2 all versions, 1.1 all versions, 1.0 all versions and FortiSRA 1.4 all versions may allow a read-only administrator to retrieve API tokens of other administrators via observing REST API logs, if REST API logging is enabled (non-default configuration).",
"id": "GHSA-fgjc-2w92-q899",
"modified": "2025-12-09T18:30:44Z",
"published": "2025-12-09T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47570"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-268"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FH34-C629-P8XJ
Vulnerability from github – Published: 2026-04-07 18:31 – Updated: 2026-04-08 19:31Sensitive Information Leak in cqlsh in Apache Cassandra 4.0 allows access to sensitive information, like passwords, from previously executed cqlsh command via ~/.cassandra/cqlsh_history local file access.
Users are recommended to upgrade to version 4.0.20, which fixes this issue.
-- Description: Cassandra's command-line tool, cqlsh, provides a command history feature that allows users to recall previously executed commands using the up/down arrow keys. These history records are saved in the ~/.cassandra/cqlsh_history file in the user's home directory.
However, cqlsh does not redact sensitive information when saving command history. This means that if a user executes operations involving passwords (such as logging in or creating users) within cqlsh, these passwords are permanently stored in cleartext in the history file on the disk.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.cassandra:cassandra-all"
},
"ranges": [
{
"events": [
{
"introduced": "4.0"
},
{
"fixed": "4.0.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27315"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T19:31:30Z",
"nvd_published_at": "2026-04-07T17:16:27Z",
"severity": "MODERATE"
},
"details": "Sensitive Information Leak in cqlsh in Apache Cassandra 4.0 allows access to sensitive information, like passwords, from previously executed cqlsh command via \u00a0~/.cassandra/cqlsh_history\u00a0local file access.\n\nUsers are recommended to upgrade to version 4.0.20, which fixes this issue.\n\n--\nDescription: Cassandra\u0027s command-line tool, cqlsh, provides a command history feature that allows users to recall previously executed commands using the up/down arrow keys. These history records are saved in the ~/.cassandra/cqlsh_history file in the user\u0027s home directory.\n\nHowever, cqlsh does not redact sensitive information when saving command history. This means that if a user executes operations involving passwords (such as logging in or creating users) within cqlsh, these passwords are permanently stored in cleartext in the history file on the disk.",
"id": "GHSA-fh34-c629-p8xj",
"modified": "2026-04-08T19:31:30Z",
"published": "2026-04-07T18:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27315"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/cassandra"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/CASSANDRA-21180"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/ft77zrk2mzt8qsch4g6jqjj4901d22k3"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/04/07/8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Apache Cassandra has sensitive Information Leak in cqlsh"
}
GHSA-FH5V-5F35-2RV2
Vulnerability from github – Published: 2022-03-17 00:00 – Updated: 2022-06-29 12:15A flaw was found in ansible module where credentials are disclosed in the console log by default and not protected by the security feature when using the bitbucket_pipeline_variable module. This flaw allows an attacker to steal bitbucket_pipeline credentials. The highest threat from this vulnerability is to confidentiality.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ansible"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0a1"
},
{
"fixed": "2.8.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "ansible"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0b1"
},
{
"fixed": "2.9.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-20180"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-29T12:15:59Z",
"nvd_published_at": "2022-03-16T15:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in ansible module where credentials are disclosed in the console log by default and not protected by the security feature when using the bitbucket_pipeline_variable module. This flaw allows an attacker to steal bitbucket_pipeline credentials. The highest threat from this vulnerability is to confidentiality.",
"id": "GHSA-fh5v-5f35-2rv2",
"modified": "2022-06-29T12:15:59Z",
"published": "2022-03-17T00:00:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20180"
},
{
"type": "WEB",
"url": "https://github.com/ansible/ansible/pull/73242"
},
{
"type": "WEB",
"url": "https://github.com/ansible/ansible/pull/73243"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1915808"
},
{
"type": "PACKAGE",
"url": "https://github.com/ansible/ansible"
},
{
"type": "WEB",
"url": "https://github.com/ansible/ansible/blob/v2.8.19/changelogs/CHANGELOG-v2.8.rst"
},
{
"type": "WEB",
"url": "https://github.com/ansible/ansible/blob/v2.9.18/changelogs/CHANGELOG-v2.9.rst"
},
{
"type": "WEB",
"url": "https://github.com/ansible/ansible/tree/v2.7.18/lib/ansible/modules/source_control"
},
{
"type": "WEB",
"url": "https://github.com/ansible/ansible/tree/v2.8.0a1/lib/ansible/modules/source_control"
}
],
"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": "Insertion of Sensitive Information into Log File in ansible"
}
GHSA-FH95-FJJQ-3FXV
Vulnerability from github – Published: 2024-09-26 15:30 – Updated: 2024-09-26 15:30IBM Cloud Pak for Multicloud Management 2.3 through 2.3 FP8 stores user credentials in a log file plain clear text which can be read by a privileged user.
{
"affected": [],
"aliases": [
"CVE-2023-46175"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-26T14:15:07Z",
"severity": "MODERATE"
},
"details": "IBM Cloud Pak for Multicloud Management 2.3 through 2.3 FP8 stores user credentials in a log file plain clear text which can be read by a privileged user.",
"id": "GHSA-fh95-fjjq-3fxv",
"modified": "2024-09-26T15:30:43Z",
"published": "2024-09-26T15:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46175"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7170411"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FH99-4PGR-8J99
Vulnerability from github – Published: 2022-06-17 20:55 – Updated: 2022-06-17 20:55Meta
- CVSS:
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N/E:F/RL:O/RC:C(4.9)
Problem
It has been discovered that system internal credentials or keys (e.g. database credentials) have been logged as plaintext in exception handlers, when logging the complete exception stack trace.
Solution
Update to TYPO3 versions 7.6.57 ELTS, 8.7.47 ELTS, 9.5.35 ELTS, 10.4.29, 11.5.11 that fix the problem described above.
Credits
Thanks to Marco Huber who reported this issue and to TYPO3 security member Torben Hansen who fixed the issue.
References
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.6.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.7.47"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.5.35"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.4.29"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.5.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.4.29"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.5.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-31047"
],
"database_specific": {
"cwe_ids": [
"CWE-209",
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-17T20:55:14Z",
"nvd_published_at": "2022-06-14T21:15:00Z",
"severity": "MODERATE"
},
"details": "\u003e ### Meta\n\u003e * CVSS: `CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N/E:F/RL:O/RC:C` (4.9)\n\n### Problem\nIt has been discovered that system internal credentials or keys (e.g. database credentials) have been logged as plaintext in exception handlers, when logging the complete exception stack trace.\n\n### Solution\nUpdate to TYPO3 versions 7.6.57 ELTS, 8.7.47 ELTS, 9.5.35 ELTS, 10.4.29, 11.5.11 that fix the problem described above.\n\n### Credits\nThanks to Marco Huber who reported this issue and to TYPO3 security member Torben Hansen who fixed the issue.\n\n### References\n* [TYPO3-CORE-SA-2022-002](https://typo3.org/security/advisory/typo3-core-sa-2022-002)",
"id": "GHSA-fh99-4pgr-8j99",
"modified": "2022-06-17T20:55:14Z",
"published": "2022-06-17T20:55:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/TYPO3/typo3/security/advisories/GHSA-fh99-4pgr-8j99"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31047"
},
{
"type": "WEB",
"url": "https://github.com/TYPO3/typo3/commit/c93ea692e7dfef03b7c50fe5437487545bee4d6a"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms/CVE-2022-31047.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/TYPO3-CMS/core"
},
{
"type": "WEB",
"url": "https://typo3.org/security/advisory/typo3-core-sa-2022-002"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Insertion of Sensitive Information into Log File in typo3/cms-core"
}
Mitigation
Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files.
Mitigation
Remove debug log files before deploying the application into production.
Mitigation
Protect log files against unauthorized read/write.
Mitigation
Adjust configurations appropriately when software is transitioned from a debug state to production.
CAPEC-215: Fuzzing for application mapping
An attacker sends random, malformed, or otherwise unexpected messages to a target application and observes the application's log or error messages returned. The attacker does not initially know how a target will respond to individual messages but by attempting a large number of message variants they may find a variant that trigger's desired behavior. In this attack, the purpose of the fuzzing is to observe the application's log and error messages, although fuzzing a target can also sometimes cause the target to enter an unstable state, causing a crash.