Slack Morphism EUVD-2026-107388

Exploitation requires a specific combination: (1) the application uses slack-morphism 1.0.0-2.27.0 with its Axum (or Hyper) listener and the DEFAULT listener error handler, which logs SlackEventWrongSignatureError at error level including the public generated_hash field; (2) the attacker can send requests to the application's Slack callback/events endpoint; and (3) the attacker can read the application's or service's logs where the error is written. Given those, the attacker sends any chosen body with a deliberately invalid signature, recovers the correct HMAC from the log entry, and must replay the identical request within Slack's five-minute timestamp freshness window. Limiting factors that reduce real-world risk: the mandatory log-read access (an elevated/trusted position rather than purely remote-anonymous), the tight five-minute replay window (AC:H), dependence on the unmodified default error handler, and that applications using a custom error handler which suppresses the hash are not affected. No signing secret is needed, but the forged request is confined to the same body and timestamp for which the oracle leaked a signature.

This is a moderate, conditional-risk flaw rather than a drop-everything priority. The supplied CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N, base 5.3 MEDIUM) is internally consistent with the mechanism: network-reachable (AV:N), but with high attack complexity (AC:H) because the attacker must win a race against the five-minute freshness window and already possess log-read access, and with required privileges (PR:L) reflecting that very need to read application/service logs. The headline impact is integrity (I:H) - forged, attacker-chosen requests pass signature verification and reach the protected callback - with no direct confidentiality or availability loss (C:N/A:N). No EPSS score, CISA KEV entry, or SSVC decision data was provided, so automatability and widespread-exploitation signals cannot be assessed from the input. No public exploit code is referenced, though the reporter (GitHub_M) states they reproduced the issue end-to-end against both the Axum and Hyper integrations in 2.26.0 and 2.27.0; reproduction by the researcher is not the same as a released weaponized PoC. The key real-world limiter, and the reason this is not critical, is the dual precondition: an attacker needs BOTH network access to the Slack callback endpoint AND read access to the service's logs. That log-access requirement typically implies an already-partially-trusted or compromised position (shared log aggregation, insider, or a secondary log-exposure bug), making this more of an exploit-chain primitive than a standalone internet-facing break.

An attacker with the ability to read the target service's logs (e.g., via a shared logging/observability platform) sends a crafted request to the application's Slack callback endpoint carrying a deliberately invalid X-Slack-Signature. Slack Morphism's default Axum error handler logs the SlackEventWrongSignatureError, which contains the correct HMAC it computed for that exact body and timestamp. The attacker reads the valid signature from the log and replays the identical request within the five-minute freshness window, passing signature verification and delivering a forged Slack event to the protected callback without ever knowing the signing secret. The reporter confirmed end-to-end reproduction against the Axum and Hyper integrations, but no public exploit code is referenced.