<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-26T12:41:03.676115+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-113799</id>
    <title>fkie_cve-2026-113799</title>
    <updated>2026-10-26T12:41:03.710235+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.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. Version 2.28.0 patches the issue.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-113799"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-26w4-8w32-4x3v</id>
    <title>GHSA-26w4-8w32-4x3v — Slack Morphism verifier errors disclose valid HMACs in the logs</title>
    <updated>2026-10-26T12:41:03.710330+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: slack-morphism</p>
<p>### Summary</p>
<p>Slack Morphism exposes the correct Slack request HMAC when signature verification fails.</p>
<p>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.</p>
<p>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.</p>
<p>I reproduced this end-to-end against both the Axum and Hyper integrations in `slack-morphism` 2.26.0 and 2.27.0.</p>
<p>### Details</p>
<p>The vulnerability is in Slack Morphism's request signature verification error path.</p>
<p>In `src/signature_verifier.rs`, `SlackEventSignatureVerifier::verify` computes the expected signature before comparing it with the untrusted `X-Slack-Signature` supplied by the request.</p>
<p>On a mismatch, the implementation creates a `SlackEventWrongSignatureError` containing the complete correct signature in its…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-26w4-8w32-4x3v"/>
  </entry>
</feed>
