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.

2005 vulnerabilities reference this CWE, most recent first.

GHSA-253Q-PRR2-4PRX

Vulnerability from github – Published: 2024-08-13 00:31 – Updated: 2026-04-01 18:31
VLAI
Details

Exposure of Sensitive Information to an Unauthorized Actor, Missing Authorization vulnerability in ThemeSphere SmartMag allows Excavation, Accessing Functionality Not Properly Constrained by ACLs.This issue affects SmartMag: from n/a through 9.3.0.

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-2024-37930"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-532",
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-12T23:15:15Z",
    "severity": "MODERATE"
  },
  "details": "Exposure of Sensitive Information to an Unauthorized Actor, Missing Authorization vulnerability in ThemeSphere SmartMag allows Excavation, Accessing Functionality Not Properly Constrained by ACLs.This issue affects SmartMag: from n/a through 9.3.0.",
  "id": "GHSA-253q-prr2-4prx",
  "modified": "2026-04-01T18:31:53Z",
  "published": "2024-08-13T00:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37930"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Theme/smartmag-responsive-retina-wordpress-magazine/vulnerability/wordpress-smartmag-theme-9-3-0-sensitive-data-exposure-via-log-file-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/smartmag-responsive-retina-wordpress-magazine/wordpress-smartmag-theme-9-3-0-sensitive-data-exposure-via-log-file-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-256X-7Q8G-XJMC

Vulnerability from github – Published: 2026-09-04 18:31 – Updated: 2026-09-04 18:31
VLAI
Details

IBM App Connect Enterprise 13.0.1.0 through 13.0.8.1, and 12.0.1.0 through 12.0.12.28 and IBM Integration Bus for z/OS 10.1.0.0 through 10.1.0.7 could allow a local attacker to obtain sensitive information due to improper logging of credentials.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-16689"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-04T17:16:52Z",
    "severity": "MODERATE"
  },
  "details": "IBM App Connect Enterprise 13.0.1.0 through 13.0.8.1, and 12.0.1.0 through 12.0.12.28 and IBM Integration Bus for z/OS 10.1.0.0 through 10.1.0.7 could allow a local attacker to obtain sensitive information due to improper logging of credentials.",
  "id": "GHSA-256x-7q8g-xjmc",
  "modified": "2026-09-04T18:31:30Z",
  "published": "2026-09-04T18:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16689"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7286372"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-25XJ-89G5-FM6H

Vulnerability from github – Published: 2021-05-18 18:21 – Updated: 2023-10-02 15:05
VLAI
Summary
Information Disclosure in HashiCorp Vault
Details

HashiCorp Vault and Vault Enterprise before 1.3.6, and 1.4.2 before 1.4.2, insert Sensitive Information into a Log File. The vulnerability is affecting github.com/hashicorp/vault/command Go package.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/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/vault"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "1.3.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/vault"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.0"
            },
            {
              "fixed": "1.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-13223"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-13T14:30:01Z",
    "nvd_published_at": "2020-06-10T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "HashiCorp Vault and Vault Enterprise before 1.3.6, and 1.4.2 before 1.4.2, insert Sensitive Information into a Log File. The vulnerability is affecting `github.com/hashicorp/vault/command` Go package.",
  "id": "GHSA-25xj-89g5-fm6h",
  "modified": "2023-10-02T15:05:17Z",
  "published": "2021-05-18T18:21:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13223"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/vault/commit/87f47c216cf1a28f4054b80cff40de8c9e00e36c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/vault/commit/e52f34772affb69f3239b2cdf6523cb7cfd67a92"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hashicorp/vault"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/vault/blob/master/CHANGELOG.md#142-may-21st-2020"
    },
    {
      "type": "WEB",
      "url": "https://www.hashicorp.com/blog/category/vault"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Information Disclosure in HashiCorp Vault"
}

GHSA-2625-RW7M-5Q5X

Vulnerability from github – Published: 2026-07-24 21:49 – Updated: 2026-07-24 21:49
VLAI
Summary
Hubuum client library (Rust): Sensitive data may be exposed through default diagnostics
Details

Summary

hubuum_client diagnostics can expose sensitive request, response, import/export, task, delivery, or server-provided data when applications format or log errors and public models.

Affected behavior

Native reqwest::Error values retain the full request URL. Converting those errors into ApiError::Http, or exhausting retries and storing the error text in ApiError::RetryExhausted, preserves query parameter values. Detailed HTTP and decoding errors can retain server-provided messages, response bodies, or payload details, including through error source chains.

Several public response and model types also derived or implemented diagnostics over untrusted or secret-adjacent fields. These include raw response bodies and cursors; rendered and JSON export payloads; import schemas and object data; task summaries, links, output URLs, events, and import-result details; event-delivery claims and errors; event sink configuration; subscription routing; and remote-call failure details. High-level backup and export runners additionally copied unsuccessful server task summaries into ApiError::Api.

Applications commonly log errors and response values, so credentials, tokens, cursors, filters, echoed request content, imported object data, schema defaults, task or delivery details, and other sensitive payloads can be written to logs even though normal request logging redacts query values.

Remediation

The proposed fix redacts query values from embedded request URLs before storing native HTTP errors and applies the same sanitization to exhausted retries. Default error and model diagnostics now report safe metadata rather than server messages, payloads, cursors, links, configuration, or secret-adjacent details. JSON codec errors no longer appear in the standard source chain, and unsuccessful high-level backup/export operations use the structured TaskUnsuccessful variant without copying task summaries.

Explicit response, error, task, import, export, event, and delivery APIs continue to expose original values for applications that deliberately inspect them.

Validation

Regression coverage exercises direct HTTP conversion, async and blocking retry exhaustion, response and decoding diagnostics, import/export/raw-response containers, unsuccessful async and blocking task runners, task/event/import-result models, and secret-bearing event and remote models. The workspace format, lint, documentation, test, feature-matrix, Rust 1.88 MSRV, OpenAPI validation, release-metadata, and combined library plus consumer integration suites pass against the immutable Hubuum 0.0.3 image.

Severity
2.3 (Low)
CVSS:4.0/AV:N/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= 0.6.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "hubuum_client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:49:18Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\n\n`hubuum_client` diagnostics can expose sensitive request, response, import/export, task, delivery, or server-provided data when applications format or log errors and public models.\n\n## Affected behavior\n\nNative `reqwest::Error` values retain the full request URL. Converting those errors into `ApiError::Http`, or exhausting retries and storing the error text in `ApiError::RetryExhausted`, preserves query parameter values. Detailed HTTP and decoding errors can retain server-provided messages, response bodies, or payload details, including through error source chains.\n\nSeveral public response and model types also derived or implemented diagnostics over untrusted or secret-adjacent fields. These include raw response bodies and cursors; rendered and JSON export payloads; import schemas and object data; task summaries, links, output URLs, events, and import-result details; event-delivery claims and errors; event sink configuration; subscription routing; and remote-call failure details. High-level backup and export runners additionally copied unsuccessful server task summaries into `ApiError::Api`.\n\nApplications commonly log errors and response values, so credentials, tokens, cursors, filters, echoed request content, imported object data, schema defaults, task or delivery details, and other sensitive payloads can be written to logs even though normal request logging redacts query values.\n\n## Remediation\n\nThe proposed fix redacts query values from embedded request URLs before storing native HTTP errors and applies the same sanitization to exhausted retries. Default error and model diagnostics now report safe metadata rather than server messages, payloads, cursors, links, configuration, or secret-adjacent details. JSON codec errors no longer appear in the standard source chain, and unsuccessful high-level backup/export operations use the structured `TaskUnsuccessful` variant without copying task summaries.\n\nExplicit response, error, task, import, export, event, and delivery APIs continue to expose original values for applications that deliberately inspect them.\n\n## Validation\n\nRegression coverage exercises direct HTTP conversion, async and blocking retry exhaustion, response and decoding diagnostics, import/export/raw-response containers, unsuccessful async and blocking task runners, task/event/import-result models, and secret-bearing event and remote models. The workspace format, lint, documentation, test, feature-matrix, Rust 1.88 MSRV, OpenAPI validation, release-metadata, and combined library plus consumer integration suites pass against the immutable Hubuum 0.0.3 image.",
  "id": "GHSA-2625-rw7m-5q5x",
  "modified": "2026-07-24T21:49:18Z",
  "published": "2026-07-24T21:49:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hubuum/hubuum-client-rust/security/advisories/GHSA-2625-rw7m-5q5x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hubuum/hubuum-client-rust/commit/5a5c275ffa45f342459b7d3e977926da643bde50"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hubuum/hubuum-client-rust"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hubuum/hubuum-client-rust/releases/tag/v0.6.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Hubuum client library (Rust): Sensitive data may be exposed through default diagnostics"
}

GHSA-269M-C36J-R834

Vulnerability from github – Published: 2025-01-28 09:32 – Updated: 2025-03-12 14:45
VLAI
Summary
Infinispan vulnerable to Insertion of Sensitive Information into Log File
Details

A flaw was found in Infinispan, when using JGroups with JDBC_PING. This issue occurs when an application inadvertently exposes sensitive information, such as configuration details or credentials, through logging mechanisms. This exposure can lead to unauthorized access and exploitation by malicious actors.

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": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.infinispan:infinispan-parent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "15.1.4.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-0736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-28T19:15:59Z",
    "nvd_published_at": "2025-01-28T09:15:09Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in Infinispan, when using JGroups with JDBC_PING. This issue occurs when an application inadvertently exposes sensitive information, such as configuration details or credentials, through logging mechanisms. This exposure can lead to unauthorized access and exploitation by malicious actors.",
  "id": "GHSA-269m-c36j-r834",
  "modified": "2025-03-12T14:45:44Z",
  "published": "2025-01-28T09:32:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0736"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:2663"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-0736"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2342233"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/infinispan/infinispan"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Infinispan vulnerable to Insertion of Sensitive Information into Log File"
}

GHSA-26F4-XFJH-462V

Vulnerability from github – Published: 2024-04-24 09:30 – Updated: 2026-04-01 18:31
VLAI
Details

Insertion of Sensitive Information into Log File vulnerability in Patrick Posner Simply Static.This issue affects Simply Static: from n/a through 3.1.3.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-32825"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201",
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-24T08:15:41Z",
    "severity": "HIGH"
  },
  "details": "Insertion of Sensitive Information into Log File vulnerability in Patrick Posner Simply Static.This issue affects Simply Static: from n/a through 3.1.3.",
  "id": "GHSA-26f4-xfjh-462v",
  "modified": "2026-04-01T18:31:46Z",
  "published": "2024-04-24T09:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32825"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/simply-static/vulnerability/wordpress-simply-static-plugin-3-1-3-sensitive-data-exposure-via-log-file-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/simply-static/wordpress-simply-static-plugin-3-1-3-sensitive-data-exposure-via-log-file-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:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-26MW-3PV7-3GQF

Vulnerability from github – Published: 2022-11-02 19:00 – Updated: 2022-11-04 19:01
VLAI
Details

An exposure of sensitive information to an unauthorized actor vulnerabiltiy [CWE-200] in FortiClient for Mac versions 7.0.0 through 7.0.5 may allow a local authenticated attacker to obtain the SSL-VPN password in cleartext via running a logstream for the FortiTray process in the terminal.

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-2022-33878"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-02T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An exposure of sensitive information to an unauthorized actor vulnerabiltiy [CWE-200] in FortiClient for Mac versions 7.0.0 through 7.0.5 may allow a local authenticated attacker to obtain the SSL-VPN password in cleartext via running a logstream for the FortiTray process in the terminal.",
  "id": "GHSA-26mw-3pv7-3gqf",
  "modified": "2022-11-04T19:01:16Z",
  "published": "2022-11-02T19:00:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33878"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.com/psirt/FG-IR-22-246"
    }
  ],
  "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-26W4-8W32-4X3V

Vulnerability from github – Published: 2026-10-21 16:38 – Updated: 2026-10-21 16:38
VLAI
Summary
Slack Morphism verifier errors disclose valid HMACs in the logs
Details

Summary

Slack Morphism exposes the correct Slack request HMAC when signature verification fails.

For an invalid request, slack-morphism computes the correct signature for the attacker-controlled timestamp and request body and stores it in SlackEventWrongSignatureError.generated_hash. The error's Debug and Display representations expose that value, and the default Axum listener error handler logs it at error level.

An attacker who can both reach the application's Slack callback endpoint and read its application/service logs can therefore use the verifier as a chosen-message HMAC oracle. The attacker can send an arbitrary request with an invalid signature, recover the correct signature from the resulting log entry, and resend the same request within the five-minute freshness window. The second request passes Slack Morphism's signature verification and reaches the protected application callback without the attacker knowing the Slack signing secret.

I reproduced this end-to-end against both the Axum and Hyper integrations in slack-morphism 2.26.0 and 2.27.0.

Details

The vulnerability is in Slack Morphism's request signature verification error path.

In src/signature_verifier.rs, SlackEventSignatureVerifier::verify computes the expected signature before comparing it with the untrusted X-Slack-Signature supplied by the request.

On a mismatch, the implementation creates a SlackEventWrongSignatureError containing the complete correct signature in its public generated_hash field.

Relevant source path:

src/signature_verifier.rs:46-59

The error type is defined around:

src/signature_verifier.rs:182-199

generated_hash is a public String; the type derives Debug, and its Display implementation also prints the generated signature.

The resulting source-to-sink path is:

  1. SlackEventSignatureVerifier::verify computes the expected HMAC for the attacker-controlled timestamp and raw request body.
  2. Signature verification fails because the attacker initially sends an invalid signature.
  3. Slack Morphism places the correct expected value in SlackEventWrongSignatureError.generated_hash.
  4. The error's Debug and Display representations reveal that HMAC.
  5. The Axum middleware propagates/formats the error through src/axum_support/slack_events_middleware.rs.
  6. The default listener error handler in src/listener.rs logs the error at error level.
  7. The attacker reads the generated HMAC from the logs.
  8. The attacker resends the identical timestamp and body using the disclosed value as X-Slack-Signature.
  9. Slack Morphism accepts the request and executes the protected callback.

The Hyper path is also affected. src/hyper_tokio/hyper_ext.rs propagates the verifier error as a service error, and formatting that error similarly exposes the generated signature.

The disclosed value is exactly the credential required to authenticate the corresponding request:

v0=hex(HMAC-SHA256(signing_secret, "v0:" || timestamp || ":" || raw_body))

There is no weakness in HMAC-SHA256 or the constant-time comparison itself. The vulnerability is that the expected authentication value is disclosed through the verifier's error path.

Affected versions

I reproduced the vulnerability against:

  • slack-morphism 2.26.0
  • slack-morphism 2.27.0
  • current master at audit time: e3b3ecabf99dfcf6c3548a42fba89fbfa510d21c

Git history indicates that the public generated_hash field was introduced in:

9bf623bd51c6a9ef0cd22d842cc707a3311f1f22

and appears to have existed since v0.10.0. Since versions before 2.26.0 are unsupported and were not dynamically tested during this assessment, I am reporting the independently validated supported range as:

>= 2.26.0, <= 2.27.0

No patched release is currently available.

PoC

The PoC uses only localhost and a synthetic signing secret.

Tested environment:

slack-morphism = 2.27.0
Rust 1.98.1
Linux x86_64
Axum and Hyper integrations

Synthetic signing secret:

SLACK_MORPHISM_SYNTHETIC_SIGNING_SECRET_7c91

Start a Slack Morphism Axum callback endpoint using the normal Slack request signature verification middleware and the default listener error handling.

Send a request using:

Body:
{"type":"attacker_chosen","action":"transfer"}

X-Slack-Request-Timestamp:
<current Unix timestamp>

X-Slack-Signature:
v0=0000000000000000000000000000000000000000000000000000000000000000

The all-zero signature is deliberately invalid.

First request

The first request is correctly rejected with HTTP 400.

However, Slack Morphism's default error output contains an entry equivalent to:

SlackEventWrongSignatureError {
    ...
    generated_hash: "v0=<correct-HMAC>"
}

where <correct-HMAC> is the valid Slack request signature for the exact attacker-controlled timestamp and body.

Copy that generated_hash.

Before the five-minute timestamp window expires, resend the identical body and timestamp, changing only the signature header:

X-Slack-Signature: v0=<correct-HMAC-from-error>

Result

The second request returns HTTP 200 and the protected application callback executes.

In my end-to-end Axum reproduction the application observed:

PROTECTED_CALLBACK_EXECUTED body={"type":"attacker_chosen","action":"transfer"}

I independently reproduced the same primitive through the Hyper integration. The invalid request produces a service error containing:

WrongSignatureError(... generated_hash: "v0=<correct-HMAC>")

and replaying that value with the same timestamp and body causes the protected callback to execute.

Expected behavior

An invalid Slack request should be rejected without exposing any verifier-derived value that could authenticate a subsequent request.

Neither verifier error objects nor application logs should contain the expected HMAC.

Actual behavior

The invalid request is rejected, but Slack Morphism exposes the correct HMAC for the attacker-selected timestamp and body through the verifier error.

Reusing that disclosed HMAC within the freshness window causes the previously invalid attacker-controlled request to pass authentication and reach the protected callback.

Impact

An attacker requires:

  1. network access to a Slack Morphism Events API, slash-command, interaction, or equivalent signed callback endpoint; and
  2. lower-privilege read access to the application's/service's logs containing the verifier error.

The attacker does not need:

  • the Slack signing secret;
  • a Slack access token;
  • a Slack app token;
  • access to a Slack workspace; or
  • permission to modify the application's configuration.

The demonstrated impact is an authentication-boundary bypass: a lower-trust log reader can generate a valid signature for attacker-chosen request bytes and cause application functionality protected by Slack request authentication to execute.

The downstream consequences depend on the consuming application. A forged event, slash command, or interaction may trigger whatever business operations that application deliberately exposes to authenticated Slack callbacks. I am not claiming that the vulnerability itself grants access to Slack data or provides a specific application-level operation.

This is a Slack Morphism vulnerability rather than an Axum/Hyper or downstream application issue because Slack Morphism itself:

  • computes the correct HMAC;
  • places it into its own public error type;
  • exposes it through Debug and Display;
  • and, in the default Axum path, sends it to its own error logger.

Signature verification is enabled and correctly configured in the reproduction.

Suggested remediation

The safest fix is to remove generated_hash from SlackEventWrongSignatureError entirely.

The expected HMAC should not be retained in a public error object because merely changing Display would still leave other disclosure paths such as derived Debug, callers inspecting the public field, or nested error formatting.

Signature mismatch errors should contain only non-sensitive diagnostic information.

I also recommend:

  • implementing sanitized Debug and Display representations for verification errors;
  • reviewing all Axum and Hyper signature-error sinks;
  • returning an ordinary sanitized HTTP authentication failure from the Hyper integration instead of exposing cryptographic verification state as a service error;
  • adding equivalent regression coverage for Events API, commands, and interactions; and
  • advising users whose logs exposed generated_hash values to rotate the Slack signing secret if those logs were accessible to an untrusted party.

A regression test can directly assert that the expected HMAC is absent from both representations:

let error = verifier.verify(BOGUS, BODY, TIMESTAMP).unwrap_err();

assert!(!format!("{error:?}").contains(CORRECT_HMAC));
assert!(!format!("{error}").contains(CORRECT_HMAC));

An integration regression test should additionally verify that default listener logs do not contain the expected HMAC and that a request using the original invalid signature never reaches the application callback.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.27.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "slack-morphism"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "2.28.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-113799"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-21T16:38:47Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nSlack Morphism exposes the correct Slack request HMAC when signature verification fails.\n\nFor an invalid request, `slack-morphism` computes the correct signature for the attacker-controlled timestamp and request body and stores it in `SlackEventWrongSignatureError.generated_hash`. The error\u0027s `Debug` and `Display` representations expose that value, and the default Axum listener error handler logs it at error level.\n\nAn attacker who can both reach the application\u0027s Slack callback endpoint and read its application/service logs can therefore use the verifier as a chosen-message HMAC oracle. The attacker can send an arbitrary request with an invalid signature, recover the correct signature from the resulting log entry, and resend the same request within the five-minute freshness window. The second request passes Slack Morphism\u0027s signature verification and reaches the protected application callback without the attacker knowing the Slack signing secret.\n\nI reproduced this end-to-end against both the Axum and Hyper integrations in `slack-morphism` 2.26.0 and 2.27.0.\n\n### Details\n\nThe vulnerability is in Slack Morphism\u0027s request signature verification error path.\n\nIn `src/signature_verifier.rs`, `SlackEventSignatureVerifier::verify` computes the expected signature before comparing it with the untrusted `X-Slack-Signature` supplied by the request.\n\nOn a mismatch, the implementation creates a `SlackEventWrongSignatureError` containing the complete correct signature in its public `generated_hash` field.\n\nRelevant source path:\n\n```text\nsrc/signature_verifier.rs:46-59\n```\n\nThe error type is defined around:\n\n```text\nsrc/signature_verifier.rs:182-199\n```\n\n`generated_hash` is a public `String`; the type derives `Debug`, and its `Display` implementation also prints the generated signature.\n\nThe resulting source-to-sink path is:\n\n1. `SlackEventSignatureVerifier::verify` computes the expected HMAC for the attacker-controlled timestamp and raw request body.\n2. Signature verification fails because the attacker initially sends an invalid signature.\n3. Slack Morphism places the correct expected value in `SlackEventWrongSignatureError.generated_hash`.\n4. The error\u0027s `Debug` and `Display` representations reveal that HMAC.\n5. The Axum middleware propagates/formats the error through `src/axum_support/slack_events_middleware.rs`.\n6. The default listener error handler in `src/listener.rs` logs the error at error level.\n7. The attacker reads the generated HMAC from the logs.\n8. The attacker resends the identical timestamp and body using the disclosed value as `X-Slack-Signature`.\n9. Slack Morphism accepts the request and executes the protected callback.\n\nThe Hyper path is also affected. `src/hyper_tokio/hyper_ext.rs` propagates the verifier error as a service error, and formatting that error similarly exposes the generated signature.\n\nThe disclosed value is exactly the credential required to authenticate the corresponding request:\n\n```text\nv0=hex(HMAC-SHA256(signing_secret, \"v0:\" || timestamp || \":\" || raw_body))\n```\n\nThere is no weakness in HMAC-SHA256 or the constant-time comparison itself. The vulnerability is that the expected authentication value is disclosed through the verifier\u0027s error path.\n\n#### Affected versions\n\nI reproduced the vulnerability against:\n\n- `slack-morphism` 2.26.0\n- `slack-morphism` 2.27.0\n- current `master` at audit time:\n  `e3b3ecabf99dfcf6c3548a42fba89fbfa510d21c`\n\nGit history indicates that the public `generated_hash` field was introduced in:\n\n```text\n9bf623bd51c6a9ef0cd22d842cc707a3311f1f22\n```\n\nand appears to have existed since v0.10.0. Since versions before 2.26.0 are unsupported and were not dynamically tested during this assessment, I am reporting the independently validated supported range as:\n\n```text\n\u003e= 2.26.0, \u003c= 2.27.0\n```\n\nNo patched release is currently available.\n\n### PoC\n\nThe PoC uses only localhost and a synthetic signing secret.\n\nTested environment:\n\n```text\nslack-morphism = 2.27.0\nRust 1.98.1\nLinux x86_64\nAxum and Hyper integrations\n```\n\nSynthetic signing secret:\n\n```text\nSLACK_MORPHISM_SYNTHETIC_SIGNING_SECRET_7c91\n```\n\nStart a Slack Morphism Axum callback endpoint using the normal Slack request signature verification middleware and the default listener error handling.\n\nSend a request using:\n\n```text\nBody:\n{\"type\":\"attacker_chosen\",\"action\":\"transfer\"}\n\nX-Slack-Request-Timestamp:\n\u003ccurrent Unix timestamp\u003e\n\nX-Slack-Signature:\nv0=0000000000000000000000000000000000000000000000000000000000000000\n```\n\nThe all-zero signature is deliberately invalid.\n\n#### First request\n\nThe first request is correctly rejected with HTTP 400.\n\nHowever, Slack Morphism\u0027s default error output contains an entry equivalent to:\n\n```text\nSlackEventWrongSignatureError {\n    ...\n    generated_hash: \"v0=\u003ccorrect-HMAC\u003e\"\n}\n```\n\nwhere `\u003ccorrect-HMAC\u003e` is the valid Slack request signature for the exact attacker-controlled timestamp and body.\n\nCopy that `generated_hash`.\n\nBefore the five-minute timestamp window expires, resend the **identical body and timestamp**, changing only the signature header:\n\n```text\nX-Slack-Signature: v0=\u003ccorrect-HMAC-from-error\u003e\n```\n\n#### Result\n\nThe second request returns HTTP 200 and the protected application callback executes.\n\nIn my end-to-end Axum reproduction the application observed:\n\n```text\nPROTECTED_CALLBACK_EXECUTED body={\"type\":\"attacker_chosen\",\"action\":\"transfer\"}\n```\n\nI independently reproduced the same primitive through the Hyper integration. The invalid request produces a service error containing:\n\n```text\nWrongSignatureError(... generated_hash: \"v0=\u003ccorrect-HMAC\u003e\")\n```\n\nand replaying that value with the same timestamp and body causes the protected callback to execute.\n\n#### Expected behavior\n\nAn invalid Slack request should be rejected without exposing any verifier-derived value that could authenticate a subsequent request.\n\nNeither verifier error objects nor application logs should contain the expected HMAC.\n\n#### Actual behavior\n\nThe invalid request is rejected, but Slack Morphism exposes the correct HMAC for the attacker-selected timestamp and body through the verifier error.\n\nReusing that disclosed HMAC within the freshness window causes the previously invalid attacker-controlled request to pass authentication and reach the protected callback.\n\n### Impact\n\nAn attacker requires:\n\n1. network access to a Slack Morphism Events API, slash-command, interaction, or equivalent signed callback endpoint; and\n2. lower-privilege read access to the application\u0027s/service\u0027s logs containing the verifier error.\n\nThe attacker does **not** need:\n\n- the Slack signing secret;\n- a Slack access token;\n- a Slack app token;\n- access to a Slack workspace; or\n- permission to modify the application\u0027s configuration.\n\nThe demonstrated impact is an authentication-boundary bypass: a lower-trust log reader can generate a valid signature for attacker-chosen request bytes and cause application functionality protected by Slack request authentication to execute.\n\nThe downstream consequences depend on the consuming application. A forged event, slash command, or interaction may trigger whatever business operations that application deliberately exposes to authenticated Slack callbacks. I am not claiming that the vulnerability itself grants access to Slack data or provides a specific application-level operation.\n\nThis is a Slack Morphism vulnerability rather than an Axum/Hyper or downstream application issue because Slack Morphism itself:\n\n- computes the correct HMAC;\n- places it into its own public error type;\n- exposes it through `Debug` and `Display`;\n- and, in the default Axum path, sends it to its own error logger.\n\nSignature verification is enabled and correctly configured in the reproduction.\n\n### Suggested remediation\n\nThe safest fix is to remove `generated_hash` from `SlackEventWrongSignatureError` entirely.\n\nThe expected HMAC should not be retained in a public error object because merely changing `Display` would still leave other disclosure paths such as derived `Debug`, callers inspecting the public field, or nested error formatting.\n\nSignature mismatch errors should contain only non-sensitive diagnostic information.\n\nI also recommend:\n\n- implementing sanitized `Debug` and `Display` representations for verification errors;\n- reviewing all Axum and Hyper signature-error sinks;\n- returning an ordinary sanitized HTTP authentication failure from the Hyper integration instead of exposing cryptographic verification state as a service error;\n- adding equivalent regression coverage for Events API, commands, and interactions; and\n- advising users whose logs exposed `generated_hash` values to rotate the Slack signing secret if those logs were accessible to an untrusted party.\n\nA regression test can directly assert that the expected HMAC is absent from both representations:\n\n```rust\nlet error = verifier.verify(BOGUS, BODY, TIMESTAMP).unwrap_err();\n\nassert!(!format!(\"{error:?}\").contains(CORRECT_HMAC));\nassert!(!format!(\"{error}\").contains(CORRECT_HMAC));\n```\n\nAn integration regression test should additionally verify that default listener logs do not contain the expected HMAC and that a request using the original invalid signature never reaches the application callback.",
  "id": "GHSA-26w4-8w32-4x3v",
  "modified": "2026-10-21T16:38:47Z",
  "published": "2026-10-21T16:38:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/abdolence/slack-morphism-rust/security/advisories/GHSA-26w4-8w32-4x3v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/abdolence/slack-morphism-rust/pull/387"
    },
    {
      "type": "WEB",
      "url": "https://github.com/abdolence/slack-morphism-rust/commit/ac95d0d4539d0eac548a8db99c51c0c1ae832756"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/abdolence/slack-morphism-rust"
    },
    {
      "type": "WEB",
      "url": "https://github.com/abdolence/slack-morphism-rust/releases/tag/v2.28.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Slack Morphism verifier errors disclose valid HMACs in the logs"
}

GHSA-26WC-MJPC-3F8M

Vulnerability from github – Published: 2024-07-02 21:32 – Updated: 2024-10-24 18:30
VLAI
Details

Vulnerability in Realtek RtsPer driver for PCIe Card Reader (RtsPer.sys) before 10.0.22000.21355 and Realtek RtsUer driver for USB Card Reader (RtsUer.sys) before 10.0.22000.31274 leaks driver logs that contain addresses of kernel mode objects, weakening KASLR.

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-2022-25477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-02T19:15:11Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in Realtek RtsPer driver for PCIe Card Reader (RtsPer.sys) before 10.0.22000.21355 and Realtek RtsUer driver for USB Card Reader (RtsUer.sys) before 10.0.22000.31274 leaks driver logs that contain addresses of kernel mode objects, weakening KASLR.",
  "id": "GHSA-26wc-mjpc-3f8m",
  "modified": "2024-10-24T18:30:40Z",
  "published": "2024-07-02T21:32:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25477"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/zwclose/feb16f1424779a61cb1d9f6d5681408a"
    },
    {
      "type": "WEB",
      "url": "https://www.realtek.com/images/safe-report/Realtek_RtsPer_RtsUer_Security_Advisory_Report.pdf"
    },
    {
      "type": "WEB",
      "url": "https://zwclose.github.io/2024/10/14/rtsper1.html"
    },
    {
      "type": "WEB",
      "url": "http://realtek.com"
    }
  ],
  "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-26WH-CC3R-W6PJ

Vulnerability from github – Published: 2025-04-02 22:36 – Updated: 2025-04-03 13:26
VLAI
Summary
canonical/get-workflow-version-action can leak a partial GITHUB_TOKEN in exception output
Details

Impact

Users using the github-token input are impacted.

If the get-workflow-version-action step fails, the exception output may include the GITHUB_TOKEN. If the full token is included in the exception output, GitHub will automatically redact the secret from the GitHub Actions logs. However, the token may be truncated—causing part of the GITHUB_TOKEN to be displayed in plaintext in the GitHub Actions logs.

Anyone with read access to the GitHub repository can view GitHub Actions logs. For public repositories, anyone can view the GitHub Actions logs.

The opportunity to exploit this vulnerability is limited—the GITHUB_TOKEN is automatically revoked when the job completes. However, there is an opportunity for an attack in the time between the GITHUB_TOKEN being displayed in the logs and the completion of the job. Normally this is less than a second, but it may be greater if continue-on-error is used in the get-workflow-version-action step or if status check functions are used in a later step in the same job. For an example of an attack in the time between the GITHUB_TOKEN being displayed in the logs & the completion of the job, see https://www.praetorian.com/blog/codeqleaked-public-secrets-exposure-leads-to-supply-chain-attack-on-github-codeql/

For users who passed the GITHUB_TOKEN to the github-token input, update to v1.0.1. Any secrets that were partially leaked while using v1.0.0 should have already been revoked, since the GITHUB_TOKEN is automatically revoked when the job completes. However, in the unlikely event that an attack was executed using a GITHUB_TOKEN before it was revoked (as described above), users' repositories may still be impacted—for example, a sophisticated attack could have used the GITHUB_TOKEN to push something to the repository.

The potential effects of an attack depend on the permissions of any GITHUB_TOKENs that were leaked. However, in a very sophisticated attack, even a GITHUB_TOKEN with read-only permissions can affect other GitHub Actions in the same repository if those actions use the Actions cache. For more information, see the "But Wait, There’s More" section of https://www.praetorian.com/blog/codeqleaked-public-secrets-exposure-leads-to-supply-chain-attack-on-github-codeql/ and https://github.com/AdnaneKhan/Cacheract

If any users used a long-lived secret (e.g. a personal access token) instead of the GITHUB_TOKEN in the github-token input, they should immediately revoke that secret. The get-workflow-version-action's documentation & examples all instructed the user to use the GITHUB_TOKEN, so it is unlikely that users used a long-lived secret instead of the GITHUB_TOKEN.

Patches

This has been fixed in v1.0.1. Also, the v1 tag has been updated to include the fix.

References

https://github.com/canonical/get-workflow-version-action/issues/2

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "GitHub Actions",
        "name": "canonical/get-workflow-version-action"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-31479"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-02T22:36:03Z",
    "nvd_published_at": "2025-04-02T22:15:20Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nUsers using the [`github-token` input](https://github.com/canonical/get-workflow-version-action/blob/a5d53b08d254a157ea441c9819ea5002ffc12edc/action.yaml#L10) are impacted.\n\nIf the `get-workflow-version-action` step fails, the exception output may include the GITHUB_TOKEN. If the full token is included in the exception output, GitHub will automatically redact the secret from the GitHub Actions logs. However, the token may be truncated\u2014causing part of the GITHUB_TOKEN to be displayed in plaintext in the GitHub Actions logs.\n\nAnyone with read access to the GitHub repository can view GitHub Actions logs. For public repositories, anyone can view the GitHub Actions logs.\n\nThe opportunity to exploit this vulnerability is limited\u2014the GITHUB_TOKEN is automatically revoked when the job completes. However, there is an opportunity for an attack in the time between the GITHUB_TOKEN being displayed in the logs and the completion of the job. Normally this is less than a second, but it may be greater if [`continue-on-error`](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error) is used in the `get-workflow-version-action` step or if [status check functions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#status-check-functions) are used in a later step in the same job. For an example of an attack in the time between the GITHUB_TOKEN being displayed in the logs \u0026 the completion of the job, see https://www.praetorian.com/blog/codeqleaked-public-secrets-exposure-leads-to-supply-chain-attack-on-github-codeql/\n\nFor users who passed the GITHUB_TOKEN to the `github-token` input, update to `v1.0.1`. Any secrets that were partially leaked while using `v1.0.0` should have already been revoked, since the GITHUB_TOKEN is automatically revoked when the job completes. However, in the unlikely event that an attack was executed using a GITHUB_TOKEN before it was revoked (as described above), users\u0027 repositories may still be impacted\u2014for example, a sophisticated attack could have used the GITHUB_TOKEN to push something to the repository.\n\nThe potential effects of an attack depend on the permissions of any GITHUB_TOKENs that were leaked. However, in a very sophisticated attack, even a GITHUB_TOKEN with read-only permissions can affect other GitHub Actions in the same repository if those actions use the Actions [cache](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows). For more information, see the \"But Wait, There\u2019s More\" section of https://www.praetorian.com/blog/codeqleaked-public-secrets-exposure-leads-to-supply-chain-attack-on-github-codeql/ and https://github.com/AdnaneKhan/Cacheract\n\nIf any users used a long-lived secret (e.g. a personal access token) instead of the GITHUB_TOKEN in the `github-token` input, they should immediately revoke that secret. The `get-workflow-version-action`\u0027s documentation \u0026 examples all instructed the user to use the GITHUB_TOKEN, so it is unlikely that users used a long-lived secret instead of the GITHUB_TOKEN.\n\n### Patches\nThis has been fixed in `v1.0.1`. Also, the `v1` tag has been updated to include the fix.\n\n### References\nhttps://github.com/canonical/get-workflow-version-action/issues/2",
  "id": "GHSA-26wh-cc3r-w6pj",
  "modified": "2025-04-03T13:26:02Z",
  "published": "2025-04-02T22:36:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/canonical/get-workflow-version-action/security/advisories/GHSA-26wh-cc3r-w6pj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/canonical/get-workflow-version-action/issues/2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/canonical/get-workflow-version-action/commit/88281a62e96e1c0ef4df30352ae0668a9f3e3369"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/canonical/get-workflow-version-action"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "canonical/get-workflow-version-action can leak a partial GITHUB_TOKEN in exception output"
}
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