Read the docs
TI-2026-66685 Aliases GHSA-mhc4-qq83-fmrr

axonflow-sdk-go: Webhook signing-key (HMAC-SHA256) not exposed by SDK type, preventing signature verification

Priority LOW 38CWE-345Published · Updated

Key facts

Attack vector
—
Privileges required
—
User interaction
—
Attack complexity
—
Impact type
Security bypass
Confidentiality · integrity · availability
—
Fix status
Fixed

No CVSS vector from any source. Fix status from GitHub. Impact type from CWE-345.

Summary

## Summary The AxonFlow SDK's `WebhookSubscription` (or equivalent) type did not expose the HMAC-SHA256 signing key returned by the platform's `CreateWebhook` endpoint. Without access to the secret through the typed SDK API, callers had no path to verify the `X-AxonFlow-Signature` header on incoming webhook deliveries. Affected callers had two unsatisfactory options: 1. Skip signature verification entirely — accepting any payload from any source that knew the webhook URL. 2. Hand-parse the raw HTTP JSON response to extract the secret, bypassing the type-safe SDK surface. This advisory is filed across all four AxonFlow SDKs (Go, Python, TypeScript, Java) because the same defect and the same fix landed in each. ## Affected versions Versions 5.6.1 and below. ## Impact A webhook receiver using the SDK's typed API to handle inbound deliveries had no path to authenticate the source of incoming payloads. An attacker who learned the webhook URL — through misconfiguration, log leakage, observable network traffic during setup, or any other discovery channel — could forge webhook deliveries indistinguishable from legitimate ones, causing the receiving application to act on fabricated events (e.g. simulated approval-granted callbacks, simulated policy-decision callbacks, simulated step-completion callbacks). ## Remediation Upgrade to the patched version listed in Vulnerabilities below. The signing key is now exposed on the `WebhookSubscription` response type returned by `CreateWebhook`. Implementations should: 1. Persist the secret returned by `CreateWebhook` securely (it is only returned once, at create time). 2. On each incoming webhook delivery, compute `HMAC-SHA256(secret, raw_body)` and compare it in constant time against the `X-AxonFlow-Signature` header. 3. Reject any delivery whose signature does not match. ## Credit Identified by AxonFlow internal security review during the April 2026 quality-freeze epic.

Why it matters now

Fix Fixed github.com/getaxonflow/axonflow-sdk-go/v5 (Go): 5.7.0

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
—github.com/getaxonflow/axonflow-sdk-go/v5 (Go)before 5.7.05.7.0Patch availableGHSA-mhc4-qq83-fmrr
  • github.com/getaxonflow/axonflow-sdk-go/v5 (Go) Vendor— Affected before 5.7.0 Fixed in 5.7.0 Patch available GHSA-mhc4-qq83-fmrr

Remediation

  • Fix · GHSA-mhc4-qq83-fmrr github.com/getaxonflow/axonflow-sdk-go/v5 (Go) Fixed in 5.7.0 Advisory →

Timeline

  1. 2026-10-03 Threatist record created from GHSA-mhc4-qq83-fmrr

References

Sources

This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences