CVE-2026-113799: 
Rust vulnerability analysis and mitigation

CVE-2026-113799 is a sensitive information disclosure vulnerability in Slack Morphism (slack-morphism-rust), a Rust client library for the Slack Web/Events API, Socket Mode, and Block Kit. The flaw causes the library to expose a valid HMAC-SHA256 request signature in error logs whenever signature verification fails, enabling a chosen-message HMAC oracle attack. Affected versions are 1.0.0 through 2.27.0 (inclusive); version 2.28.0 contains the fix. It carries a CVSS v3.1 base score of 5.3 (Medium) (Github Advisory). The advisory was originally published by the repository maintainer on September 19, 2026, and added to the GitHub Advisory Database on October 21, 2026 (Github Advisory).

The root cause is CWE-532 (Insertion of Sensitive Information into Log File). In src/signature_verifier.rs, SlackEventSignatureVerifier::verify computes the expected HMAC-SHA256 signature (v0=hex(HMAC-SHA256(signing_secret, "v0:" || timestamp || ":" || raw_body))) before comparing it to the attacker-supplied X-Slack-Signature header. On a mismatch, the full correct signature is stored in the public field SlackEventWrongSignatureError.generated_hash, which is then exposed via both the Debug and Display trait implementations of that error type (Github Advisory). The default Axum listener error handler logs this error at the error level, and the Hyper integration similarly propagates the error as a service error, both leaking the valid credential to application logs (Github Advisory). An attacker can exploit this as a chosen-message oracle: send a request with an arbitrary body and an invalid signature, read the correct HMAC from the logs, then replay the identical request with the disclosed signature within the five-minute Slack freshness window to bypass authentication entirely (Github Advisory).

Successful exploitation results in a complete authentication-boundary bypass for Slack callback endpoints protected by Slack Morphism's signature verification. An attacker can forge valid Slack Events API, slash-command, or interaction requests with arbitrary attacker-controlled payloads, causing the protected application callback to execute without possessing the Slack signing secret. The downstream business impact depends on the consuming application — any operation exposed through authenticated Slack callbacks (e.g., triggering workflows, data modifications, or administrative actions) can be invoked by the attacker. Confidentiality and availability are not directly impacted; the primary risk is high integrity impact through unauthorized callback execution (Github Advisory).

A proof-of-concept was included in the original security advisory and was end-to-end reproduced against both the Axum and Hyper integrations of slack-morphism 2.26.0 and 2.27.0 (Github Advisory). Exploitation requires two preconditions: network access to the application's Slack callback endpoint, and read access to the application's logs (e.g., as a lower-privileged internal user or via a log aggregation system). There is no evidence of in-the-wild exploitation, no known threat actor attribution, and the EPSS score is 0.0. The vulnerability is not listed in the CISA KEV catalog (Github Advisory).

1. Reconnaissance: Identify an application using slack-morphism (versions 1.0.0–2.27.0) that exposes a Slack callback endpoint (Events API, slash commands, interactions, etc.) and uses the default Axum or Hyper listener error handling.
2. Craft initial probe request: Prepare an HTTP POST request to the target Slack callback endpoint with an attacker-chosen body (e.g., {"type":"attacker_chosen","action":"transfer"}), a current Unix timestamp in the X-Slack-Request-Timestamp header, and a deliberately invalid signature (e.g., X-Slack-Signature: v0=0000000000000000000000000000000000000000000000000000000000000000).
3. Send probe and observe rejection: The application returns HTTP 400, but Slack Morphism logs an error containing SlackEventWrongSignatureError { ... generated_hash: "v0=<correct_hmac>" } at the error log level.
4. Extract valid HMAC from logs: Read the application or service logs (requires log read access) and extract the generated_hash value — this is the valid HMAC-SHA256 signature for the exact timestamp and body used in step 2.
5. Replay request within freshness window: Within five minutes of the original timestamp, resend the identical request body and X-Slack-Request-Timestamp, replacing the signature header with the extracted value: X-Slack-Signature: v0=<extracted_hmac>.
6. Achieve authentication bypass: The second request passes Slack Morphism's signature verification and the protected application callback executes, confirming successful authentication bypass without knowledge of the Slack signing secret (Github Advisory).

• Logs: Application error logs containing entries matching SlackEventWrongSignatureError { ... generated_hash: "v0=<64-char hex>" } or Slack API signature validation error: Body len: ..., received ts: ..., received hash: ..., generated hash: v0=... — especially when followed shortly by a successful (HTTP 200) request with the same timestamp and body.
• Network: Two near-identical HTTP POST requests to the Slack callback endpoint within a short time window (under five minutes) sharing the same X-Slack-Request-Timestamp and body, where the first returns HTTP 400 and the second returns HTTP 200; the second request's X-Slack-Signature matches the generated_hash value logged from the first.
• Logs: Repeated HTTP 400 responses to the Slack callback endpoint from the same source IP with all-zero or otherwise obviously invalid X-Slack-Signature values, indicating probing activity.
• Logs: If logs were accessible to untrusted parties, any historical log entries containing generated_hash values should be treated as potentially compromised credentials, warranting Slack signing secret rotation (Github Advisory).

Upgrade to slack-morphism version 2.28.0, which removes generated_hash from SlackEventWrongSignatureError entirely and retains only a short prefix of the received signature for diagnostic purposes (Release v2.28.0, PR #387). If immediate upgrade is not possible, restrict log access to trusted personnel only and suppress or redact error-level logs from the Slack callback middleware as a temporary measure. Additionally, any deployments where application logs containing generated_hash values were accessible to untrusted parties should rotate the Slack signing secret immediately (Github Advisory).

The vulnerability was reported by a researcher credited as "Ridful" and was responsibly disclosed to the maintainer, who merged the fix (PR #387) on September 9, 2026, prior to the advisory's public release on September 19, 2026 (Github Advisory, PR #387). The maintainer acknowledged the issue and noted that the fix also addresses a secondary disclosure risk where a correctly signed request against a misconfigured local secret could expose a valid credential via the received signature field (PR #387). No significant broader media coverage or notable community commentary beyond the advisory and patch discussion has been identified.