CVE-2026-113799

### 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: ```text src/signature_verifier.rs:46-59 ``` The error type is defined around: ```text 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 ve