Common Weakness Enumeration

CWE-532

Allowed

Insertion of Sensitive Information into Log File

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product writes sensitive information to a log file.

1961 vulnerabilities reference this CWE, most recent first.

GHSA-8RC9-2785-687M

Vulnerability from github – Published: 2023-09-12 00:30 – Updated: 2023-11-01 00:30
VLAI
Details

A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in iOS 15.7.8 and iPadOS 15.7.8, macOS Big Sur 11.7.9, macOS Monterey 12.6.8. An app may be able to read sensitive location information.

Severity
3.3 (Low)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-40442"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-12T00:15:09Z",
    "severity": "LOW"
  },
  "details": "A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in iOS 15.7.8 and iPadOS 15.7.8, macOS Big Sur 11.7.9, macOS Monterey 12.6.8. An app may be able to read sensitive location information.",
  "id": "GHSA-8rc9-2785-687m",
  "modified": "2023-11-01T00:30:48Z",
  "published": "2023-09-12T00:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40442"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213842"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213844"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213845"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT213841"
    }
  ],
  "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"
    }
  ]
}

GHSA-8RRQ-WCG8-CV5Q

Vulnerability from github – Published: 2026-05-18 17:56 – Updated: 2026-06-09 10:57
VLAI
Summary
OpenTelemetry eBPF Instrumentation: Redis error text is exported in span status messages
Details

Summary

OBI exports raw Redis error text as the span status message. Because Redis error replies can contain attacker-controlled or sensitive values, this behavior can exfiltrate tokens, PII, or other confidential input into telemetry backends and inject untrusted text into downstream analysis systems.

Details

In pkg/ebpf/common/redis_detect_transform.go, getRedisError trims the raw error buffer and stores it directly in request.DBError.Description.

Later, pkg/appolly/app/request/span.go returns that description as the exported status message for Redis spans whenever the span status is non-zero.

There is no opt-in control or sanitization beyond CRLF trimming. As a result, raw Redis error text becomes part of OTLP-exported status metadata by default.

PoC

Local request-layer testing recorded a status message containing ERR invalid password for user bob secret=TOPSECRET, which shows that unfiltered Redis error text reaches the exported status message.

Use a vulnerable build:

git checkout v0.0.0-rc.1+build
make build

Start Redis and OBI:

docker run --rm -p 6379:6379 redis:7
sudo ./bin/obi

Send a command that causes Redis to return an error containing caller-supplied text:

redis-cli -p 6379 'NOTACMD my-secret-token-123'

Capture the exported span or inspect the local telemetry output. On a vulnerable build, the span status message contains the Redis error text, including the supplied command fragment. This demonstrates that raw Redis error text is exported into telemetry by default and that values embedded in that text, including data supplied unintentionally by a caller, can be carried into tracing systems.

Impact

This is an information disclosure and telemetry injection issue. It affects any deployment that traces Redis traffic and exports spans to collectors, logs, or dashboards. Sensitive values, tokens, or PII present in Redis error text can be exfiltrated into telemetry systems, and untrusted text can contaminate downstream analysis.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/obi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45679"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T17:56:15Z",
    "nvd_published_at": "2026-06-02T16:16:42Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nOBI exports raw Redis error text as the span status message. Because Redis error replies can contain attacker-controlled or sensitive values, this behavior can exfiltrate tokens, PII, or other confidential input into telemetry backends and inject untrusted text into downstream analysis systems.\n\n### Details\n\nIn [pkg/ebpf/common/redis_detect_transform.go](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/4f35facce2fe611319672595838ab875490f404d/pkg/components/ebpf/common/redis_detect_transform.go#L60-L74), `getRedisError` trims the raw error buffer and stores it directly in `request.DBError.Description`.\n\nLater, [pkg/appolly/app/request/span.go](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/4f35facce2fe611319672595838ab875490f404d/pkg/app/request/span.go#L347-L352) returns that description as the exported status message for Redis spans whenever the span status is non-zero.\n\nThere is no opt-in control or sanitization beyond CRLF trimming. As a result, raw Redis error text becomes part of OTLP-exported status metadata by default.\n\n### PoC\n\nLocal request-layer testing recorded a status message containing `ERR invalid password for user bob secret=TOPSECRET`, which shows that unfiltered Redis error text reaches the exported status message.\n\nUse a vulnerable build:\n\n```bash\ngit checkout v0.0.0-rc.1+build\nmake build\n```\n\nStart Redis and OBI:\n\n```bash\ndocker run --rm -p 6379:6379 redis:7\nsudo ./bin/obi\n```\n\nSend a command that causes Redis to return an error containing caller-supplied text:\n\n```bash\nredis-cli -p 6379 \u0027NOTACMD my-secret-token-123\u0027\n```\n\nCapture the exported span or inspect the local telemetry output. On a vulnerable build, the span status message contains the Redis error text, including the supplied command fragment. This demonstrates that raw Redis error text is exported into telemetry by default and that values embedded in that text, including data supplied unintentionally by a caller, can be carried into tracing systems.\n\n### Impact\n\nThis is an information disclosure and telemetry injection issue. It affects any deployment that traces Redis traffic and exports spans to collectors, logs, or dashboards. Sensitive values, tokens, or PII present in Redis error text can be exfiltrated into telemetry systems, and untrusted text can contaminate downstream analysis.",
  "id": "GHSA-8rrq-wcg8-cv5q",
  "modified": "2026-06-09T10:57:58Z",
  "published": "2026-05-18T17:56:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/security/advisories/GHSA-8rrq-wcg8-cv5q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45679"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/tag/v0.9.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenTelemetry eBPF Instrumentation: Redis error text is exported in span status messages"
}

GHSA-8RV8-VG5P-GRCR

Vulnerability from github – Published: 2023-10-10 15:30 – Updated: 2024-04-04 08:29
VLAI
Details

When TACACS+ audit forwarding is configured on BIG-IP or BIG-IQ system, sharedsecret is logged in plaintext in the audit log.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-43485"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-10T13:15:21Z",
    "severity": "MODERATE"
  },
  "details": "\nWhen TACACS+ audit forwarding is configured on BIG-IP or BIG-IQ system, sharedsecret is logged in plaintext in the audit log.\u00a0 Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
  "id": "GHSA-8rv8-vg5p-grcr",
  "modified": "2024-04-04T08:29:16Z",
  "published": "2023-10-10T15:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43485"
    },
    {
      "type": "WEB",
      "url": "https://my.f5.com/manage/s/article/K06110200"
    }
  ],
  "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-8RWQ-R56X-HX8F

Vulnerability from github – Published: 2026-09-27 03:31 – Updated: 2026-09-27 03:31
VLAI
Details

Edgelesssys Contrast is a confidential-computing runtime for Kubernetes. In versions 1.9.0 before 1.12.2, the initializer logs the full NewMeshCert response — which contains the workload secret — to standard output at INFO level. As a result, workload secrets are exposed to any Kubernetes user with get or list permission on pods/logs. Because workload secrets are used for encrypted storage and Vault integration, those must also be considered compromised. This is a regression of GHSA-h5f8-crrq-4pw8.

Severity
7.3 (High)
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
8.5 (High)
CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-71423"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-27T02:17:15Z",
    "severity": "HIGH"
  },
  "details": "Edgelesssys Contrast is a confidential-computing runtime for Kubernetes. In versions 1.9.0 before 1.12.2, the initializer logs the full NewMeshCert response \u2014 which contains the workload secret \u2014 to standard output at INFO level. As a result, workload secrets are exposed to any Kubernetes user with get or list permission on pods/logs. Because workload secrets are used for encrypted storage and Vault integration, those must also be considered compromised. This is a regression of GHSA-h5f8-crrq-4pw8.",
  "id": "GHSA-8rwq-r56x-hx8f",
  "modified": "2026-09-27T03:31:03Z",
  "published": "2026-09-27T03:31:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/edgelesssys/contrast/security/advisories/GHSA-vxg3-w9rv-rhr2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71423"
    },
    {
      "type": "WEB",
      "url": "https://github.com/edgelesssys/contrast/commit/5a5512c4af63c17bb66331e7bd2768a863b2f225"
    },
    {
      "type": "WEB",
      "url": "https://github.com/edgelesssys/contrast/commit/cf58026b30c43fe7df91eac5322da02e1725d554"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/edgelesssys-contrast-before-1.12.2-workload-secrets-information-disclosure"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/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-8VG2-WF3Q-MWV7

Vulnerability from github – Published: 2023-03-23 19:47 – Updated: 2023-03-31 16:08
VLAI
Summary
directus vulnerable to Insertion of Sensitive Information into Log File
Details

Summary

CWE-532: Insertion of Sensitive Information into Log File discovered in v9.23.1. The directus_refresh_token is not redacted properly from the log outputs and can be used to impersonate users without their permission.

Details

Using v9.23.1, I am seeing that the directus_refresh_token is not properly redacted as indicated by https://github.com/directus/directus/blob/7c479c5161639aac466c763b6b958a9524201d74/api/src/logger.ts#L13

I'm classifying this as a security vulnerability because if someone has access to the log outputs, for example with a shared Cloud account or Splunk implementation, they could exchange the refresh token using /auth/refresh for an access token and use the token to perform actions on behalf of an unsuspecting user. This situation creates issues with accountability and non-repudiation because we can no longer have confidence that actions taken in the application were authorized or even performed by the logged-in user.

A couple of examples of this are: - A disgruntled employee deletes all of the data to get even with a target team member before logging off on their last day - Under the guise of their unsuspecting boss, a mischievous engineer uploads questionable images that get displayed on internal or external facing content sites

The list could go on but I think these communicate the risk of an internal threat that has access to this information 😆

PoC

  1. Set LOG_STYLE="raw" and run Directus v9.23.1
  2. Log in to the application

  3. Look at the shell output and see that directus_refresh_token is logged > Note: This is different from the standard raw output format. I intentionally ran this with npx directus start | pino-pretty so logs would be easier to read. It can also be reproduced by running npx directus start alone.

    image

  4. Exchange the directus_refresh_token for an access_token

    shell curl -X POST \ 'http://0.0.0.0:8055/auth/refresh' \ --header 'Accept: */*' \ --header 'Cookie: directus_refresh_token=$shh'

Impact

Because this can be used to exploit other threats related to CWE-284: Improper Access Control I rank it with a Moderate severity. An insider with knowledge of this could do many mischievous things and get away with them for a long time without victims knowing about it.

Severity
4.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "directus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.23.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-28443"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-23T19:47:12Z",
    "nvd_published_at": "2023-03-24T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nCWE-532: Insertion of Sensitive Information into Log File discovered in v9.23.1. The `directus_refresh_token` is not redacted properly from the log outputs and can be used to impersonate users without their permission. \n\n### Details\n\nUsing `v9.23.1`, I am seeing that the `directus_refresh_token` is not properly redacted as indicated by https://github.com/directus/directus/blob/7c479c5161639aac466c763b6b958a9524201d74/api/src/logger.ts#L13\n\nI\u0027m classifying this as a security vulnerability because if someone has access to the log outputs, for example with a shared Cloud account or Splunk implementation, they could exchange the refresh token using `/auth/refresh` for an access token and use the token to perform actions on behalf of an unsuspecting user. This situation creates issues with accountability and non-repudiation because we can no longer have confidence that actions taken in the application were authorized or even performed by the logged-in user. \n\nA couple of examples of this are:\n- A disgruntled employee deletes all of the data to get even with a target team member before logging off on their last day\n- Under the guise of their unsuspecting boss, a mischievous engineer uploads _questionable_ images that get displayed on internal or external facing content sites\n\nThe list could go on but I think these communicate the risk of an internal threat that has access to this information \ud83d\ude06 \n\n### PoC\n1. Set `LOG_STYLE=\"raw\"` and run Directus v9.23.1\n1. Log in to the application\n1. Look at the shell output and see that `directus_refresh_token` is logged\n    \u003e Note: This is different from the standard `raw` output format. I intentionally ran this with `npx directus start | pino-pretty` so logs would be easier to read. It can also be reproduced by running `npx directus start` alone. \n\n    ![image](https://user-images.githubusercontent.com/13325146/224877190-54e12d7e-3c3e-42d3-9e21-0bd4439f4f44.png)\n\n1. Exchange the `directus_refresh_token` for an `access_token`\n\n     ``` shell\n      curl -X POST \\\n        \u0027http://0.0.0.0:8055/auth/refresh\u0027 \\\n        --header \u0027Accept: */*\u0027 \\\n        --header \u0027Cookie: directus_refresh_token=$shh\u0027\n     ```\n\n### Impact\nBecause this can be used to exploit other threats related to  [CWE-284: Improper Access Control](https://cwe.mitre.org/data/definitions/284.html) I rank it with a Moderate severity. An insider with knowledge of this could do many mischievous things and get away with them for a long time without victims knowing about it. \n",
  "id": "GHSA-8vg2-wf3q-mwv7",
  "modified": "2023-03-31T16:08:10Z",
  "published": "2023-03-23T19:47:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/security/advisories/GHSA-8vg2-wf3q-mwv7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28443"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/commit/349536303983ccba68ecb3e4fb35315424011afc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/directus/directus"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/blob/7c479c5161639aac466c763b6b958a9524201d74/api/src/logger.ts#L13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "directus vulnerable to Insertion of Sensitive Information into Log File"
}

GHSA-8VH8-VC28-M2HF

Vulnerability from github – Published: 2019-11-20 01:33 – Updated: 2022-02-11 21:12
VLAI
Summary
Potential to access user credentials from the log files when debug logging enabled
Details

A flaw was found in, all under 2.0.20, in the Undertow DEBUG log for io.undertow.request.security. If enabled, an attacker could abuse this flaw to obtain the user's credentials from the log files.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.undertow:undertow-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10212"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2019-11-19T02:49:57Z",
    "nvd_published_at": "2019-10-02T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A flaw was found in, all under 2.0.20, in the Undertow DEBUG log for io.undertow.request.security. If enabled, an attacker could abuse this flaw to obtain the user\u0027s credentials from the log files.",
  "id": "GHSA-8vh8-vc28-m2hf",
  "modified": "2022-02-11T21:12:59Z",
  "published": "2019-11-20T01:33:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10212"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2998"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0727"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10212"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220210-0017"
    }
  ],
  "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"
    }
  ],
  "summary": "Potential to access user credentials from the log files when debug logging enabled"
}

GHSA-8W53-FQWP-95J2

Vulnerability from github – Published: 2026-09-16 21:32 – Updated: 2026-09-16 21:32
VLAI
Details

Under certain circumstances on affected platforms running Arista EOS with gRPC Network Packet Sampling Interface (gNPSI) enabled, the gNPSI client credentials might be logged in clear text in local or remote accounting logs to authenticated users.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
6.0 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-73457"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-16T19:17:32Z",
    "severity": "MODERATE"
  },
  "details": "Under certain circumstances on affected platforms running Arista EOS with gRPC Network Packet Sampling Interface (gNPSI) enabled, the gNPSI client credentials might be logged in clear text in local or remote accounting logs to authenticated users.",
  "id": "GHSA-8w53-fqwp-95j2",
  "modified": "2026-09-16T21:32:43Z",
  "published": "2026-09-16T21:32:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73457"
    },
    {
      "type": "WEB",
      "url": "https://www.arista.com/en/support/advisories-notices/security-advisory/24714-security-advisory-0158"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/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-8WF6-Q8C8-VQJ7

Vulnerability from github – Published: 2025-12-05 18:31 – Updated: 2025-12-05 18:31
VLAI
Details

ReQuest Serious Play F3 Media Server versions 7.0.3.4968 (Pro), 7.0.2.4954, 6.5.2.4954, 6.4.2.4681, 6.3.2.4203, and 2.0.1.823 allows unauthenticated attackers to disclose the webserver's Python debug log file containing system information, credentials, paths, processes and command arguments running on the device. Attackers can access sensitive information by visiting the message_log page.

Severity
8.7 (High)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-36876"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-05T18:15:53Z",
    "severity": "HIGH"
  },
  "details": "ReQuest Serious Play F3 Media Server versions 7.0.3.4968 (Pro), 7.0.2.4954, 6.5.2.4954, 6.4.2.4681, 6.3.2.4203, and 2.0.1.823 allows unauthenticated attackers to disclose the webserver\u0027s Python debug log file containing system information, credentials, paths, processes and command arguments running on the device. Attackers can access sensitive information by visiting the message_log page.",
  "id": "GHSA-8wf6-q8c8-vqj7",
  "modified": "2025-12-05T18:31:12Z",
  "published": "2025-12-05T18:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36876"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/48950"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/request-serious-play-f-media-server-debug-log-disclosure"
    },
    {
      "type": "WEB",
      "url": "https://www.zeroscience.mk/en/vulnerabilities/ZSL-2020-5600.php"
    },
    {
      "type": "WEB",
      "url": "http://request.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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-8WMF-6V46-5GFG

Vulnerability from github – Published: 2026-09-17 20:31 – Updated: 2026-09-17 20:31
VLAI
Summary
OpenTelemetry-Go: Exporter config logging may leak endpoint URLs in info logs
Details

Summary

OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs.

The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log.

Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c.

Details

When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include:

  1. the provider's span processors;
  2. each processor's span exporter; and
  3. for the OTLP trace exporter, its client configuration.

This causes the following values to be present in the event:

  • OTLP trace gRPC: the configured endpoint;
  • OTLP trace HTTP: the configured endpoint and the Insecure flag; and
  • Zipkin: the complete collector URL.

OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent:

  • versions 1.5.0 through 1.14.x use V(1) for this Info event; and
  • versions 1.15.0 through 1.44.0 use V(4).

OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format.

Proof of concept

The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging:

package main

import (
    "bytes"
    "context"
    "fmt"

    "github.com/go-logr/logr/funcr"
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/exporters/zipkin"
    sdktrace "go.opentelemetry.io/otel/sdk/trace"
)

func main() {
    var logs bytes.Buffer
    otel.SetLogger(funcr.New(func(_, args string) {
        _, _ = logs.WriteString(args)
    }, funcr.Options{Verbosity: 4}))

    exporter, err := zipkin.New(
        "http://user:pass@zipkin.internal:9411/api/v2/spans?token=secret",
    )
    if err != nil {
        panic(err)
    }

    tp := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter))
    _ = tp.Shutdown(context.Background())

    fmt.Println(logs.String())
}

The TracerProvider created event contains:

http://user:pass@zipkin.internal:9411/api/v2/spans?token=secret

For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead.

Impact

This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs.

There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path.

Remediation

Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead.

If an immediate upgrade is not possible:

  • keep OpenTelemetry internal logging below the Info verbosity described above;
  • do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and
  • restrict access to existing logs and rotate any credentials that may already have been recorded.
Severity
2.0 (Low)
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.44.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/otel/sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.45.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.44.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/otel/exporters/otlp/otlptrace"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.45.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.44.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.45.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.44.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.45.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.44.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/otel/exporters/zipkin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.45.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-81870"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T20:31:06Z",
    "nvd_published_at": "2026-09-16T20:17:32Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\nOpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK `TracerProvider` is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry\u0027s internal Info-level diagnostics and for someone other than the intended audience to have access to those logs.\n\nThe logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log.\n\nExporter `MarshalLog` implementations that caused this configuration to be included in internal logs were introduced by [`a1fff3c`](https://github.com/open-telemetry/opentelemetry-go/commit/a1fff3c2588c783d1f3f6fd2315aa2660fc6d330).\n\n### Details\n\nWhen `sdk/trace.NewTracerProvider` constructs a provider, it records a `TracerProvider created` internal Info event containing the provider configuration. In affected versions, the configuration\u0027s `MarshalLog` methods recursively include:\n\n1. the provider\u0027s span processors;\n2. each processor\u0027s span exporter; and\n3. for the OTLP trace exporter, its client configuration.\n\nThis causes the following values to be present in the event:\n\n- OTLP trace gRPC: the configured endpoint;\n- OTLP trace HTTP: the configured endpoint and the `Insecure` flag; and\n- Zipkin: the complete collector URL.\n\nOpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with `otel.SetLogger`. The required `logr` verbosity is version-dependent:\n\n- versions 1.5.0 through 1.14.x use `V(1)` for this Info event; and\n- versions 1.15.0 through 1.44.0 use `V(4)`.\n\nOTLP header configuration is not part of the marshaled object, so credentials supplied with `WithHeaders` or the corresponding environment variables are not exposed. The documented OTLP `WithEndpoint` input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format.\n\n### Proof of concept\n\nThe following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging:\n\n```go\npackage main\n\nimport (\n\t\"bytes\"\n\t\"context\"\n\t\"fmt\"\n\n\t\"github.com/go-logr/logr/funcr\"\n\t\"go.opentelemetry.io/otel\"\n\t\"go.opentelemetry.io/otel/exporters/zipkin\"\n\tsdktrace \"go.opentelemetry.io/otel/sdk/trace\"\n)\n\nfunc main() {\n\tvar logs bytes.Buffer\n\totel.SetLogger(funcr.New(func(_, args string) {\n\t\t_, _ = logs.WriteString(args)\n\t}, funcr.Options{Verbosity: 4}))\n\n\texporter, err := zipkin.New(\n\t\t\"http://user:pass@zipkin.internal:9411/api/v2/spans?token=secret\",\n\t)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\ttp := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter))\n\t_ = tp.Shutdown(context.Background())\n\n\tfmt.Println(logs.String())\n}\n```\n\nThe `TracerProvider created` event contains:\n\n```text\nhttp://user:pass@zipkin.internal:9411/api/v2/spans?token=secret\n```\n\nFor versions before 1.15.0, set `funcr.Options{Verbosity: 1}` instead.\n\n### Impact\n\nThis is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs.\n\nThere is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path.\n\n### Remediation\n\nUpgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in [`3a1412d`](https://github.com/open-telemetry/opentelemetry-go/commit/3a1412d2b3bc4e4231fbeac2ed42117ae541bb38) stops recursively marshaling exporter and client configuration and records their types instead.\n\nIf an immediate upgrade is not possible:\n\n- keep OpenTelemetry internal logging below the Info verbosity described above;\n- do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and\n- restrict access to existing logs and rotate any credentials that may already have been recorded.",
  "id": "GHSA-8wmf-6v46-5gfg",
  "modified": "2026-09-17T20:31:06Z",
  "published": "2026-09-17T20:31:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-8wmf-6v46-5gfg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81870"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-go/pull/8438"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-go/commit/3a1412d2b3bc4e4231fbeac2ed42117ae541bb38"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-go/releases/tag/exporters/zipkin/v1.45.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-go/releases/tag/sdk/v1.45.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenTelemetry-Go: Exporter config logging may leak endpoint URLs in info logs"
}

GHSA-8WPJ-W799-92RG

Vulnerability from github – Published: 2022-05-13 01:19 – Updated: 2025-05-30 18:30
VLAI
Details

** DISPUTED ** An issue was discovered in SecurEnvoy SecurAccess 9.3.502. When put in Debug mode and used for RDP connections, the application stores the emergency credentials in cleartext in the logs (present in the DEBUG folder) that can be accessed by anyone. NOTE: The vendor disputes this as a vulnerability since the disclosure of a local account password (actually an alpha numeric passcode) is achievable only when a custom registry key is added to the windows registry. This action requires administrator access and the registry key is only provided by support staff at securenvoy to troubleshoot customer issues.

Severity
7.0 (High)
CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-18466"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-21T16:00:00Z",
    "severity": "HIGH"
  },
  "details": "** DISPUTED ** An issue was discovered in SecurEnvoy SecurAccess 9.3.502. When put in Debug mode and used for RDP connections, the application stores the emergency credentials in cleartext in the logs (present in the DEBUG folder) that can be accessed by anyone. NOTE: The vendor disputes this as a vulnerability since the disclosure of a local account password (actually an alpha numeric passcode) is achievable only when a custom registry key is added to the windows registry. This action requires administrator access and the registry key is only provided by support staff at securenvoy to troubleshoot customer issues.",
  "id": "GHSA-8wpj-w799-92rg",
  "modified": "2025-05-30T18:30:34Z",
  "published": "2022-05-13T01:19:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18466"
    },
    {
      "type": "WEB",
      "url": "https://cds.thalesgroup.com/en/tcs-cert/CVE-2018-18466"
    },
    {
      "type": "WEB",
      "url": "https://www.excellium-services.com/cert-xlm-advisory"
    },
    {
      "type": "WEB",
      "url": "https://www.excellium-services.com/cert-xlm-advisory/cve-2018-18466"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design Implementation

Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files.

Mitigation
Distribution

Remove debug log files before deploying the application into production.

Mitigation
Operation

Protect log files against unauthorized read/write.

Mitigation
Implementation

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.

← Back to the CWE list