Skip to content
Heist/ feed
Back to feed
MediumFix available

Slack Morphism verifier errors disclose valid HMACs in the logs

Type: advisorySources: OSV

### 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 `

Products
slack-morphism
Affected versions
Not specified
Fixed versions
2.28.0
CVEs
CVE-2026-113799
Confirmed fixed CVEs
Not specified
Updated in this feed
31 Oct 2026, 14:34 UTC · Revision 1

Source evidence

Slack Morphism verifier errors disclose valid HMACs in the logs

core-osv · Original source

Published 21 Oct 2026, 16:38 UTC

### 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 `

osv:GHSA-26w4-8w32-4x3v

slack-morphism

Fixed versions: 2.28.0

Complete source record
{
  "id": "2a2fcb75ac8acc2ba1a2226fec5552ab177b65c76996c0bb4d9a43daa51c86c6",
  "url": "https://osv.dev/vulnerability/GHSA-26w4-8w32-4x3v",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "Slack Morphism verifier errors disclose valid HMACs in the logs",
    "summary": "### 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 `",
    "evidence": "osv:GHSA-26w4-8w32-4x3v",
    "products": [
      {
        "name": {
          "value": "slack-morphism",
          "evidence": "/affected/0/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "2.28.0",
            "evidence": "/affected/0/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "medium",
    "structured": {
      "id": "GHSA-26w4-8w32-4x3v",
      "aliases": [
        "CVE-2026-113799",
        "GHSA-26w4-8w32-4x3v"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "type": "SEMVER",
              "events": [
                {
                  "introduced": "1.0.0"
                },
                {
                  "fixed": "2.28.0"
                }
              ]
            }
          ],
          "package": {
            "name": "slack-morphism",
            "purl": "pkg:cargo/slack-morphism",
            "ecosystem": "crates.io"
          },
          "database_specific": {
            "source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/10/GHSA-26w4-8w32-4x3v/GHSA-26w4-8w32-4x3v.json",
            "last_known_affected_version_range": "<= 2.27.0"
          }
        }
      ],
      "modified": "2026-10-21T16:45:04.128108390Z",
      "provider": "osv",
      "references": [
        "https://github.com/abdolence/slack-morphism-rust/security/advisories/GHSA-26w4-8w32-4x3v",
        "https://github.com/abdolence/slack-morphism-rust/pull/387",
        "https://github.com/abdolence/slack-morphism-rust/commit/ac95d0d4539d0eac548a8db99c51c0c1ae832756",
        "https://github.com/abdolence/slack-morphism-rust",
        "https://github.com/abdolence/slack-morphism-rust/releases/tag/v2.28.0"
      ],
      "provider_metadata": {
        "cwe_ids": [
          "CWE-532"
        ],
        "severity": "MODERATE",
        "github_reviewed": true,
        "nvd_published_at": null,
        "github_reviewed_at": "2026-10-21T16:38:47Z"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-113799",
        "evidence": "/aliases"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 394537,
  "published_at": "2026-10-21T16:38:47+00:00"
}