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-C2G2-GX4J-RJ3J

Vulnerability from github – Published: 2024-06-02 22:28 – Updated: 2024-06-02 22:28
VLAI
Summary
Slack integration leaks sensitive information in logs
Details

Impact

Sentry's Slack integration incorrectly records the incoming request body in logs. This request data can contain sensitive information, including the deprecated Slack verification token. With this verification token, it is possible under specific configurations, an attacker can forge requests and act as the Slack integration.

The request body is leaked in log entries matching event == "slack.*" && name == "sentry.integrations.slack" && request_data == *. The deprecated slack verification token, will be found in the request_data.token key.

Example event:

{
    "name": "sentry.integrations.slack",
    "level": "info",
    "event": "slack.event.message",  # This could be any of the `slack.*` events
    "request_data": {
      # Other keys are omitted for brevity
      "token": "<MyDeprecatedSlackVerificationToken>",
    }
}

Patches

⚠️ Sentry's support for validating Slack requests via the legacy verification token will be deprecated in version 24.7.0.

Workarounds

Option 1

Set the slack.signing-secret instead of slack.verification-token. The signing secret is Slack's recommended way of authenticating webhooks.

By having slack.singing-secret set, Sentry self-hosted will no longer use the verification token for authentication of the webhooks, regardless of whether slack.verification-token is set or not.

Option 2

The deprecated Slack verification token is leaked in log levels of INFO and ERROR in the Slack integration. If the self-hosted instance is unable to be upgraded or re-configured to use the slack.signing-secret, the logging configuration can be adjusted to not generate logs from the integration. The default logging configuration can be found in src/sentry/conf/server.py. Services should be restarted once the configuration change is saved.

Below you'll find an example of the configuration adjustments necessary to remove the Slack integration logs:

# src/sentry/conf/server.py

...

LOGGING: LoggingConfig = {
    ...
    handlers: {
        # the line below already exists in the default configuration
        "null": {"class": "logging.NullHandler"},
        ...
    },
    "loggers": {
        "sentry.integrations.slack": {
            "handlers": ["null"],  # route logs to null handler
            "level": "CRITICAL",  # prevent generation of logs a lower levels (ex. ERROR and INFO)
        },
        ...
    },
}

References

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "sentry"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "24.3.0"
            },
            {
              "fixed": "24.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-35196"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-02T22:28:09Z",
    "nvd_published_at": "2024-05-31T18:15:12Z",
    "severity": "LOW"
  },
  "details": "### Impact\nSentry\u0027s Slack integration incorrectly records the incoming request body in logs. This request data can contain sensitive information, including the [deprecated Slack verification token](https://api.slack.com/authentication/verifying-requests-from-slack#deprecation). With this verification token, it is possible under specific configurations, an attacker can forge requests and act as the Slack integration.\n\nThe request body is leaked in log entries matching `event == \"slack.*\" \u0026\u0026 name == \"sentry.integrations.slack\" \u0026\u0026 request_data == *`. The deprecated slack verification token, will be found in the `request_data.token` key.\n\nExample event:\n\n```json\n{\n    \"name\": \"sentry.integrations.slack\",\n    \"level\": \"info\",\n    \"event\": \"slack.event.message\",  # This could be any of the `slack.*` events\n    \"request_data\": {\n      # Other keys are omitted for brevity\n      \"token\": \"\u003cMyDeprecatedSlackVerificationToken\u003e\",\n    }\n}\n``` \n\n### Patches\n- **SaaS users** do not need to take any action.\n- **Self-hosted users** should upgrade to version 24.5.0 or higher, [rotate their Slack verification token](https://api.slack.com/authentication/verifying-requests-from-slack#regenerating), and [use the Slack Signing Secret instead of the verification token](https://develop.sentry.dev/integrations/slack/).\n  - If you are only using the `slack.signing-secret` in your self-hosted configuration, then the legacy verification token is not used to verify the webhook payload. It is ignored. \n \n\u003e \u26a0\ufe0f Sentry\u0027s support for validating Slack requests via the legacy verification token will be deprecated in version 24.7.0.\n\n\n### Workarounds\n\n#### Option 1\n\nSet the `slack.signing-secret` instead of `slack.verification-token`. The [signing secret](https://api.slack.com/authentication/verifying-requests-from-slack#app-management-updates) is Slack\u0027s recommended way of authenticating webhooks.\n\nBy having `slack.singing-secret` set, Sentry self-hosted will no longer use the verification token for authentication of the webhooks, regardless of whether `slack.verification-token` is set or not.\n\n#### Option 2\n\nThe deprecated Slack verification token is leaked in log levels of `INFO` and `ERROR` in the Slack integration. If the self-hosted instance is unable to be upgraded or re-configured to use the `slack.signing-secret`, the logging configuration can be adjusted to not generate logs from the integration. The [default logging configuration can be found in `src/sentry/conf/server.py`](https://github.com/getsentry/sentry/blob/17d2b87e39ccd57e11da4deed62971ff306253d1/src/sentry/conf/server.py#L1307). **Services should be restarted once the configuration change is saved.**\n\nBelow you\u0027ll find an example of the configuration adjustments necessary to remove the Slack integration logs:\n \n```python\n# src/sentry/conf/server.py\n\n...\n \nLOGGING: LoggingConfig = {\n    ...\n    handlers: {\n        # the line below already exists in the default configuration\n        \"null\": {\"class\": \"logging.NullHandler\"},\n        ...\n    },\n    \"loggers\": {\n        \"sentry.integrations.slack\": {\n            \"handlers\": [\"null\"],  # route logs to null handler\n            \"level\": \"CRITICAL\",  # prevent generation of logs a lower levels (ex. ERROR and INFO)\n        },\n        ...\n    },\n}\n```\n\n### References\n- https://github.com/getsentry/sentry/pull/70508\n- [Sentry Slack Integration Documentation for Self-Hosted users](https://develop.sentry.dev/integrations/slack/)\n- [Documentation on Slack Signing Secrets](https://api.slack.com/authentication/verifying-requests-from-slack#app-management-updates)\n- [Slack Deprecation for Verification Tokens](https://api.slack.com/authentication/verifying-requests-from-slack#deprecation)\n",
  "id": "GHSA-c2g2-gx4j-rj3j",
  "modified": "2024-06-02T22:28:09Z",
  "published": "2024-06-02T22:28:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getsentry/sentry/security/advisories/GHSA-c2g2-gx4j-rj3j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35196"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getsentry/sentry/pull/70508"
    },
    {
      "type": "WEB",
      "url": "https://api.slack.com/authentication/verifying-requests-from-slack#app-management-updates"
    },
    {
      "type": "WEB",
      "url": "https://api.slack.com/authentication/verifying-requests-from-slack#deprecation"
    },
    {
      "type": "WEB",
      "url": "https://api.slack.com/authentication/verifying-requests-from-slack#regenerating"
    },
    {
      "type": "WEB",
      "url": "https://develop.sentry.dev/integrations/slack"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getsentry/sentry"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getsentry/sentry/blob/17d2b87e39ccd57e11da4deed62971ff306253d1/src/sentry/conf/server.py#L1307"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Slack integration leaks sensitive information in logs"
}

GHSA-C2HF-VCMR-QJRF

Vulnerability from github – Published: 2024-07-23 18:31 – Updated: 2024-07-24 14:59
VLAI
Summary
Apache Arrow Rust Object Store: AWS WebIdentityToken exposure in log files
Details

Exposure of temporary credentials in logs in Apache Arrow Rust Object Store (object_store crate), version 0.10.1 and earlier on all platforms using AWS WebIdentityTokens. 

On certain error conditions, the logs may contain the OIDC token passed to AssumeRoleWithWebIdentity https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html . This allows someone with access to the logs to impersonate that identity, including performing their own calls to AssumeRoleWithWebIdentity, until the OIDC token expires. Typically OIDC tokens are valid for up to an hour, although this will vary depending on the issuer.

Users are recommended to use a different AWS authentication mechanism, disable logging or upgrade to version 0.10.2, which fixes this issue.

Details:

When using AWS WebIdentityTokens with the object_store crate, in the event of a failure and automatic retry, the underlying reqwest error, including the full URL with the credentials, potentially in the parameters, is written to the logs. 

Thanks to Paul Hatcherian for reporting this vulnerability

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "object_store"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.10.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-41178"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-24T14:59:02Z",
    "nvd_published_at": "2024-07-23T17:15:12Z",
    "severity": "MODERATE"
  },
  "details": "Exposure of temporary credentials in logs\u00a0in Apache Arrow Rust Object Store (`object_store` crate), version 0.10.1 and earlier on all platforms using AWS WebIdentityTokens.\u00a0\n\nOn certain error conditions, the logs may contain the OIDC token passed to  AssumeRoleWithWebIdentity https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html . This allows someone with access to the logs to impersonate that identity, including performing their own calls to AssumeRoleWithWebIdentity, until the OIDC token expires. Typically OIDC tokens are valid for up to an hour, although this will vary depending on the issuer.\n\nUsers are recommended to use a different AWS authentication mechanism, disable logging or upgrade to version 0.10.2, which fixes this issue.\n\nDetails:\n\nWhen using AWS WebIdentityTokens with the object_store crate, in the event of a failure and automatic retry, the underlying reqwest error, including the full URL with the credentials, potentially in the parameters, is written to the logs.\u00a0\n\nThanks to Paul\u00a0Hatcherian for reporting this vulnerability",
  "id": "GHSA-c2hf-vcmr-qjrf",
  "modified": "2024-07-24T14:59:02Z",
  "published": "2024-07-23T18:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41178"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/arrow-rs/pull/6074"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/arrow-rs/commit/4978e32654235f569062f2cad6c7361e410f1254"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/arrow-rs"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/3t0povdppnt2czv6crlsqhvyko93kcrg"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0358.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/07/23/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Arrow Rust Object Store: AWS WebIdentityToken exposure in log files"
}

GHSA-C343-52CW-6JVQ

Vulnerability from github – Published: 2022-11-19 00:30 – Updated: 2022-11-28 21:30
VLAI
Details

Unauthenticated Error Log Disclosure vulnerability in Media Library Assistant plugin <= 3.00 on WordPress.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-41618"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-18T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Unauthenticated Error Log Disclosure vulnerability in Media Library Assistant plugin \u003c= 3.00 on WordPress.",
  "id": "GHSA-c343-52cw-6jvq",
  "modified": "2022-11-28T21:30:22Z",
  "published": "2022-11-19T00:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41618"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/media-library-assistant/wordpress-media-library-assistant-plugin-3-00-unauthenticated-error-log-disclosure-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/media-library-assistant/#developers"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C37V-3C8W-CRQ8

Vulnerability from github – Published: 2025-05-22 20:33 – Updated: 2025-05-28 19:47
VLAI
Summary
zot logs secrets
Details

Summary

When using Keycloak as an oidc provider, the clientsecret gets printed into the container stdout logs for an example at container startup.

Details

Container Image (15.04.2025): ghcr.io/project-zot/zot-linux-amd64:latest Here is an example how the configuration can look which causes the above stated problem:

http: address: "0.0.0.0" port: 5000 externalUrl: "https://zot.example.com" auth: { failDelay: 1, openid: { providers: { oidc: { name: "Keycloak", clientid: "zot-client-id", clientsecret: fsdfkmmiwljasdklfsjaskldjfkljewijrf234i52k3j45l, keypath: "", issuer: "https://keycloak.example.com/realms/example", scopes: ["openid"] } } } }

PoC

Set up a blank new zot k8s deployment with the code snippet above.

Impact

exposure of secrets, on configuring a oidc provider

Severity
5.5 (Medium)
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/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "zotregistry.dev/zot"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.4-0.20250522160828-8a99a3ed231f"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-48374"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-22T20:33:39Z",
    "nvd_published_at": "2025-05-22T21:15:37Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nWhen using Keycloak as an oidc provider, the clientsecret gets printed into the container stdout logs for an example at container startup.\n\n### Details\nContainer Image (15.04.2025): ghcr.io/project-zot/zot-linux-amd64:latest\nHere is an example how the configuration can look which causes the above stated problem:\n\n`    http:\n      address: \"0.0.0.0\"\n      port: 5000\n      externalUrl: \"https://zot.example.com\"\n      auth: {\n        failDelay: 1,\n        openid: {\n          providers: {\n            oidc: {\n              name: \"Keycloak\",\n              clientid: \"zot-client-id\",\n              clientsecret: fsdfkmmiwljasdklfsjaskldjfkljewijrf234i52k3j45l,\n              keypath: \"\",\n              issuer: \"https://keycloak.example.com/realms/example\",\n              scopes: [\"openid\"]\n            }\n          }\n        }\n      }\n`\n\n### PoC\nSet up a blank new zot k8s deployment with the code snippet above.\n\n### Impact\nexposure of secrets, on configuring a oidc provider",
  "id": "GHSA-c37v-3c8w-crq8",
  "modified": "2025-05-28T19:47:48Z",
  "published": "2025-05-22T20:33:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/project-zot/zot/security/advisories/GHSA-c37v-3c8w-crq8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48374"
    },
    {
      "type": "WEB",
      "url": "https://github.com/project-zot/zot/commit/8a99a3ed231fdcd8467e986182b4705342b6a15e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/project-zot/zot"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3705"
    }
  ],
  "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/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "zot logs secrets"
}

GHSA-C3HC-Q36Q-95G4

Vulnerability from github – Published: 2026-08-10 12:31 – Updated: 2026-08-10 21:32
VLAI
Details

Logs contain replayable JWT tokens in Apache Ranger versions <= 2.8.0 Users are recommended to upgrade to version 2.9.0, which fixes this issue.

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": [],
  "aliases": [
    "CVE-2026-65945"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-10T11:17:27Z",
    "severity": "MODERATE"
  },
  "details": "Logs contain replayable JWT tokens in Apache Ranger versions \u003c= 2.8.0\nUsers are recommended to upgrade to version 2.9.0, which fixes this issue.",
  "id": "GHSA-c3hc-q36q-95g4",
  "modified": "2026-08-10T21:32:02Z",
  "published": "2026-08-10T12:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65945"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/ww4b3d59r3pnhosljcrq9b98qzqtnclk"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/08/09/10"
    }
  ],
  "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"
    }
  ]
}

GHSA-C3MG-9HRC-3M49

Vulnerability from github – Published: 2024-03-12 06:30 – Updated: 2024-03-12 06:30
VLAI
Details

Insertion of Sensitive Information into Log File vulnerability in Hitachi Cosminexus Component Container allows local users to gain sensitive information.This issue affects Cosminexus Component Container: from 11-30 before 11-30-05, from 11-20 through 11-20-, from 11-10 through 11-10-, from 11-00 before 11-00-12, All versions of V8 and V9.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-6814"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-12T04:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Insertion of Sensitive Information into Log File vulnerability in Hitachi Cosminexus Component Container allows local users to gain sensitive information.This issue affects Cosminexus Component Container: from 11-30 before 11-30-05, from 11-20 through 11-20-*, from 11-10 through 11-10-*, from 11-00 before 11-00-12, All versions of V8 and V9.\n\n",
  "id": "GHSA-c3mg-9hrc-3m49",
  "modified": "2024-03-12T06:30:45Z",
  "published": "2024-03-12T06:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6814"
    },
    {
      "type": "WEB",
      "url": "https://www.hitachi.com/products/it/software/security/info/vuls/hitachi-sec-2024-118/index.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C3MW-737P-C7G2

Vulnerability from github – Published: 2026-09-17 20:28 – Updated: 2026-09-17 20:28
VLAI
Summary
Jupyter Server: 5xx request logging leaks token-bearing Referer header values
Details

Summary

When a request returns a 500, jupyter_server/log.py logs a small JSON block of request headers.

The Referer header was copied into it as-is, so a token in the Referer URL ended up in the logs in plain text.

Impact

Anyone who can read the server logs can pick tokens out of these 500 entries. Tokens end up in the Referer during normal token-based login and launch flows.

Affected: all versions before 2.21.0.

PoC

Any malformed request that returns a 500 works:

curl -i -X POST \
  -H 'Content-Type: application/json' \
  -H 'Referer: http://127.0.0.1:8899/tree?token=REFERTOKEN' \
  --data '{"name":123}' \
  'http://127.0.0.1:8899/api/kernels?token=VALIDTOKEN'

The log shows the token twice, once raw and once redacted:

"Referer": "http://127.0.0.1:8899/tree?token=REFERTOKEN",
[E ... ServerApp] 500 POST /api/kernels?token=[secret] (...) referer=http://127.0.0.1:8899/tree?token=[secret]

Patches

Fixed in 2.21.0 by 5251352. Header values are now scrubbed before the block is logged. Upgrade to 2.21.0 or later.

Workarounds

Limit who can read the server logs. If you can, avoid flows that put the token in the URL.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.20.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyter_server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.21.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-86049"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T20:28:55Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWhen a request returns a 500, `jupyter_server/log.py` logs a small JSON block of request headers. \n\nThe Referer header was copied into it as-is, so a token in the Referer URL ended up in the logs in plain text.\n\n### Impact\n\nAnyone who can read the server logs can pick tokens out of these 500 entries. Tokens end up in the Referer during normal token-based login and launch flows.\n\nAffected: all versions before 2.21.0.\n\n### PoC\n\nAny malformed request that returns a 500 works:\n\n```bash\ncurl -i -X POST \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Referer: http://127.0.0.1:8899/tree?token=REFERTOKEN\u0027 \\\n  --data \u0027{\"name\":123}\u0027 \\\n  \u0027http://127.0.0.1:8899/api/kernels?token=VALIDTOKEN\u0027\n```\n\nThe log shows the token twice, once raw and once redacted:\n\n```\n\"Referer\": \"http://127.0.0.1:8899/tree?token=REFERTOKEN\",\n[E ... ServerApp] 500 POST /api/kernels?token=[secret] (...) referer=http://127.0.0.1:8899/tree?token=[secret]\n```\n\n### Patches\n\nFixed in 2.21.0 by 5251352. Header values are now scrubbed before the block is logged. Upgrade to 2.21.0 or later.\n\n### Workarounds\n\nLimit who can read the server logs. If you can, avoid flows that put the token in the URL.",
  "id": "GHSA-c3mw-737p-c7g2",
  "modified": "2026-09-17T20:28:55Z",
  "published": "2026-09-17T20:28:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/jupyter_server/security/advisories/GHSA-c3mw-737p-c7g2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/jupyter_server/pull/1681"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/jupyter_server/commit/52513529af7096e622c00911b17627b266294717"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jupyter-server/jupyter_server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/jupyter_server/releases/tag/v2.21.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jupyter Server: 5xx request logging leaks token-bearing Referer header values"
}

GHSA-C3Q9-Q986-VRWH

Vulnerability from github – Published: 2025-03-10 18:31 – Updated: 2025-03-14 20:04
VLAI
Summary
Nomad is vulnerable to unintentional exposure of the workload identity token and client secret token in audit logs
Details

Nomad Community and Nomad Enterprise (“Nomad”) are vulnerable to unintentional exposure of the workload identity token and client secret token in audit logs. This vulnerability, identified as CVE-2025-1296, is fixed in Nomad Community Edition 1.9.7 and Nomad Enterprise 1.9.7, 1.8.11, and 1.7.19.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/nomad"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-1296"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-10T22:25:55Z",
    "nvd_published_at": "2025-03-10T18:15:30Z",
    "severity": "MODERATE"
  },
  "details": "Nomad Community and Nomad Enterprise (\u201cNomad\u201d) are vulnerable to unintentional exposure of the workload identity token and client secret token in audit logs. This vulnerability, identified as CVE-2025-1296, is fixed in Nomad Community Edition 1.9.7 and Nomad Enterprise 1.9.7, 1.8.11, and 1.7.19.",
  "id": "GHSA-c3q9-q986-vrwh",
  "modified": "2025-03-14T20:04:19Z",
  "published": "2025-03-10T18:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1296"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/nomad/commit/dc482bf9058faf7a192486eb52caa1d42646f6b3"
    },
    {
      "type": "WEB",
      "url": "https://discuss.hashicorp.com/t/hcsec-2025-04-nomad-exposes-sensitive-workload-identity-and-client-secret-token-in-audit-logs/73737"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hashicorp/nomad"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3510"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nomad is vulnerable to unintentional exposure of the workload identity token and client secret token in audit logs"
}

GHSA-C45C-73JC-5CP5

Vulnerability from github – Published: 2023-04-24 03:30 – Updated: 2024-04-04 03:38
VLAI
Details

CloverDX before 5.17.3 writes passwords to the audit log in certain situations, if the audit log is enabled and single sign-on is not employed. The fixed versions are 5.15.4, 5.16.2, 5.17.3, and 6.0.x.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-31056"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-24T03:15:07Z",
    "severity": "MODERATE"
  },
  "details": "CloverDX before 5.17.3 writes passwords to the audit log in certain situations, if the audit log is enabled and single sign-on is not employed. The fixed versions are 5.15.4, 5.16.2, 5.17.3, and 6.0.x.",
  "id": "GHSA-c45c-73jc-5cp5",
  "modified": "2024-04-04T03:38:58Z",
  "published": "2023-04-24T03:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31056"
    },
    {
      "type": "WEB",
      "url": "https://support1.cloverdx.com/hc/en-us/articles/8484869595164-Security-advisory-April-2023"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C49H-JV3F-MRWC

Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-05-24 19:10
VLAI
Details

Dell Wyse ThinOS, versions 9.0, 9.1, and 9.1 MR1, contain a Sensitive Information Disclosure Vulnerability. An authenticated attacker with physical access to the system could exploit this vulnerability to read sensitive Smartcard data in log files.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-21598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-10T19:15:00Z",
    "severity": "LOW"
  },
  "details": "Dell Wyse ThinOS, versions 9.0, 9.1, and 9.1 MR1, contain a Sensitive Information Disclosure Vulnerability. An authenticated attacker with physical access to the system could exploit this vulnerability to read sensitive Smartcard data in log files.",
  "id": "GHSA-c49h-jv3f-mrwc",
  "modified": "2022-05-24T19:10:31Z",
  "published": "2022-05-24T19:10:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21598"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/000189543"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
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