Slack Morphism verifier errors disclose valid HMACs in the logs
### 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 sourcePublished 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"
}