CWE-532
AllowedInsertion of Sensitive Information into Log File
Abstraction: Base · Status: Incomplete
The product writes sensitive information to a log file.
1742 vulnerabilities reference this CWE, most recent first.
GHSA-9W3W-43CP-9HPG
Vulnerability from github – Published: 2024-08-13 09:30 – Updated: 2024-08-13 09:30A vulnerability has been identified in RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2) (All versions < V8.1), RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2) (All versions < V8.1), SCALANCE M804PB (6GK5804-0AP00-2AA2) (All versions < V8.1), SCALANCE M812-1 ADSL-Router family (All versions < V8.1), SCALANCE M816-1 ADSL-Router family (All versions < V8.1), SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2) (All versions < V8.1), SCALANCE M874-2 (6GK5874-2AA00-2AA2) (All versions < V8.1), SCALANCE M874-3 (6GK5874-3AA00-2AA2) (All versions < V8.1), SCALANCE M874-3 3G-Router (CN) (6GK5874-3AA00-2FA2) (All versions < V8.1), SCALANCE M876-3 (6GK5876-3AA02-2BA2) (All versions < V8.1), SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2) (All versions < V8.1), SCALANCE M876-4 (6GK5876-4AA10-2BA2) (All versions < V8.1), SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2) (All versions < V8.1), SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2) (All versions < V8.1), SCALANCE MUM853-1 (A1) (6GK5853-2EA10-2AA1) (All versions < V8.1), SCALANCE MUM853-1 (B1) (6GK5853-2EA10-2BA1) (All versions < V8.1), SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1) (All versions < V8.1), SCALANCE MUM856-1 (A1) (6GK5856-2EA10-3AA1) (All versions < V8.1), SCALANCE MUM856-1 (B1) (6GK5856-2EA10-3BA1) (All versions < V8.1), SCALANCE MUM856-1 (CN) (6GK5856-2EA00-3FA1) (All versions < V8.1), SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1) (All versions < V8.1), SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1) (All versions < V8.1), SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2) (All versions < V8.1), SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2) (All versions < V8.1). Affected devices insert sensitive information about the generation of 2FA tokens into log files. This could allow an authenticated remote attacker to forge 2FA tokens of other users.
{
"affected": [],
"aliases": [
"CVE-2024-41978"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-13T08:15:15Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2) (All versions \u003c V8.1), RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2) (All versions \u003c V8.1), SCALANCE M804PB (6GK5804-0AP00-2AA2) (All versions \u003c V8.1), SCALANCE M812-1 ADSL-Router family (All versions \u003c V8.1), SCALANCE M816-1 ADSL-Router family (All versions \u003c V8.1), SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2) (All versions \u003c V8.1), SCALANCE M874-2 (6GK5874-2AA00-2AA2) (All versions \u003c V8.1), SCALANCE M874-3 (6GK5874-3AA00-2AA2) (All versions \u003c V8.1), SCALANCE M874-3 3G-Router (CN) (6GK5874-3AA00-2FA2) (All versions \u003c V8.1), SCALANCE M876-3 (6GK5876-3AA02-2BA2) (All versions \u003c V8.1), SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2) (All versions \u003c V8.1), SCALANCE M876-4 (6GK5876-4AA10-2BA2) (All versions \u003c V8.1), SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2) (All versions \u003c V8.1), SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2) (All versions \u003c V8.1), SCALANCE MUM853-1 (A1) (6GK5853-2EA10-2AA1) (All versions \u003c V8.1), SCALANCE MUM853-1 (B1) (6GK5853-2EA10-2BA1) (All versions \u003c V8.1), SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1) (All versions \u003c V8.1), SCALANCE MUM856-1 (A1) (6GK5856-2EA10-3AA1) (All versions \u003c V8.1), SCALANCE MUM856-1 (B1) (6GK5856-2EA10-3BA1) (All versions \u003c V8.1), SCALANCE MUM856-1 (CN) (6GK5856-2EA00-3FA1) (All versions \u003c V8.1), SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1) (All versions \u003c V8.1), SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1) (All versions \u003c V8.1), SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2) (All versions \u003c V8.1), SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2) (All versions \u003c V8.1). Affected devices insert sensitive information about the generation of 2FA tokens into log files. This could allow an authenticated remote attacker to forge 2FA tokens of other users.",
"id": "GHSA-9w3w-43cp-9hpg",
"modified": "2024-08-13T09:30:52Z",
"published": "2024-08-13T09:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41978"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-087301.html"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/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-9W5H-J492-M8F6
Vulnerability from github – Published: 2024-04-17 09:30 – Updated: 2026-04-28 21:34Insertion of Sensitive Information into Log File vulnerability in AdTribes.Io Product Feed PRO for WooCommerce.This issue affects Product Feed PRO for WooCommerce: from n/a through 13.3.1.
{
"affected": [],
"aliases": [
"CVE-2024-32513"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T08:15:07Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information into Log File vulnerability in AdTribes.Io Product Feed PRO for WooCommerce.This issue affects Product Feed PRO for WooCommerce: from n/a through 13.3.1.",
"id": "GHSA-9w5h-j492-m8f6",
"modified": "2026-04-28T21:34:45Z",
"published": "2024-04-17T09:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32513"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/woo-product-feed-pro/wordpress-product-feed-pro-for-woocommerce-plugin-13-3-1-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"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-9WMF-XF3H-R8PR
Vulnerability from github – Published: 2024-04-25 18:30 – Updated: 2025-10-24 19:33A vulnerability was found in jberet-core logging. An exception in 'dbProperties' might display user credentials such as the username and password for the database-connection.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jberet:jberet-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.1.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-1102"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-523",
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-25T19:57:35Z",
"nvd_published_at": "2024-04-25T17:15:47Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in jberet-core logging. An exception in \u0027dbProperties\u0027 might display user credentials such as the username and password for the database-connection.",
"id": "GHSA-9wmf-xf3h-r8pr",
"modified": "2025-10-24T19:33:18Z",
"published": "2024-04-25T18:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1102"
},
{
"type": "WEB",
"url": "https://github.com/jberet/jsr352/issues/452"
},
{
"type": "WEB",
"url": "https://github.com/jberet/jsr352/commit/eeef999663d7da0e372aeeeac26ecf7201a3121d"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:1677"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:3580"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:3581"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:3583"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-1102"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2262060"
},
{
"type": "PACKAGE",
"url": "https://github.com/jberet/jsr352"
}
],
"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": "Jberet: jberet-core logging database credentials"
}
GHSA-9XPJ-MVP2-3943
Vulnerability from github – Published: 2023-02-23 15:33 – Updated: 2023-03-08 15:29Potential Insertion of Sensitive Information into Jetty Log Files in multiple versions of OpenNMS Meridian and Horizon could allow disclosure of usernames and passwords if the logging level is set to debug.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.opennms:opennms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "31.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-0815"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2023-02-28T23:28:09Z",
"nvd_published_at": "2023-02-23T15:15:00Z",
"severity": "MODERATE"
},
"details": "Potential Insertion of Sensitive Information into Jetty Log Files in multiple versions of OpenNMS Meridian and Horizon could allow disclosure of usernames and passwords if the logging level is set to debug.",
"id": "GHSA-9xpj-mvp2-3943",
"modified": "2023-03-08T15:29:24Z",
"published": "2023-02-23T15:33:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0815"
},
{
"type": "WEB",
"url": "https://github.com/OpenNMS/opennms/pull/5741/files"
},
{
"type": "WEB",
"url": "https://docs.opennms.com/meridian/2022/releasenotes/changelog.html#releasenotes-changelog-Meridian-2022.1.13"
},
{
"type": "PACKAGE",
"url": "https://github.com/OpenNMS/opennms"
},
{
"type": "WEB",
"url": "https://github.com/OpenNMS/opennms/releases/tag/opennms-31.0.4-1"
}
],
"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": "OpenNMS has potential Insertion of Sensitive Information into Log File vulnerability"
}
GHSA-C2G2-GX4J-RJ3J
Vulnerability from github – Published: 2024-06-02 22:28 – Updated: 2024-06-02 22:28Impact
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
- SaaS users do not need to take any action.
- Self-hosted users should upgrade to version 24.5.0 or higher, rotate their Slack verification token, and use the Slack Signing Secret instead of the verification token.
- If you are only using the
slack.signing-secretin your self-hosted configuration, then the legacy verification token is not used to verify the webhook payload. It is ignored.
⚠️ 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
- https://github.com/getsentry/sentry/pull/70508
- Sentry Slack Integration Documentation for Self-Hosted users
- Documentation on Slack Signing Secrets
- Slack Deprecation for Verification Tokens
{
"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:59Exposure 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
{
"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:30Unauthenticated Error Log Disclosure vulnerability in Media Library Assistant plugin <= 3.00 on WordPress.
{
"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:47Summary
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
{
"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-C3MG-9HRC-3M49
Vulnerability from github – Published: 2024-03-12 06:30 – Updated: 2024-03-12 06:30Insertion 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.
{
"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-C3Q9-Q986-VRWH
Vulnerability from github – Published: 2025-03-10 18:31 – Updated: 2025-03-14 20:04Nomad 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.
{
"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"
}
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.