CVE-2026-113799: Slack Morphism verifier errors disclose valid HMACs in the logs
Slack Morphism is a client library for Slack Web/Events API/Socket Mode and Block Kit. Versions 1.0.0 through 2.27.0 expose 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.generatedhash. 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. Version 2.28.0 patches the issue.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
slack-morphismto a version that resolves this vulnerability.Fixed in 2.28.0
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker must be able to send requests to the application's Slack callback endpoint and read the application's or service's logs. They do not need to know the Slack signing secret if they can obtain the generated signature from a log entry.
Are applications using the default Axum listener behavior affected?
Yes. The default Axum listener error handler logs the verification error at error level, and the error's Debug and Display representations expose the generated HMAC.
What is the practical impact of the leaked value?
The attacker can submit an invalid request, recover the correct HMAC for that attacker-controlled timestamp and body from logs, then resend the same request within the five-minute freshness window. The resent request passes signature verification and reaches the protected callback.
What can be done if an immediate upgrade is not possible?
Preventing an attacker from both reaching the Slack callback endpoint and reading application or service logs breaks the described attack path. The issue is patched in slack-morphism version 2.28.0.
How can I determine whether an installation is affected?
Installations using slack-morphism versions 1.0.0 through 2.27.0 are affected. Review error-level logs generated for failed signature verification for exposed generated HMAC values.