GHSA-mhc4-qq83-fmrr json
axonflow-sdk-go: Webhook signing-key (HMAC-SHA256) not exposed by SDK type, preventing signature verification
published 6mo ago modified 4mo ago also GO-2026-5508
- cvss
- 5.9
- version 3.1, GitHub
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
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.
Patch / fix
- go github.com/getaxonflow/axonflow-sdk-go/v5 5.7.0
Is GHSA-mhc4-qq83-fmrr in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| GitHub | 3.1 | 5.9 | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| go | github.com/getaxonflow/axonflow-sdk-go/v5 | <5.7.0 |
5.7.0 |
| go | github.com/getaxonflow/axonflow-sdk-go | all versions |
no fix listed |
| go | github.com/getaxonflow/axonflow-sdk-go/v2 | all versions |
no fix listed |
| go | github.com/getaxonflow/axonflow-sdk-go/v3 | all versions |
no fix listed |
| go | github.com/getaxonflow/axonflow-sdk-go/v4 | all versions |
no fix listed |
Classification
References
Sources
- GitHub Advisory GHSA-mhc4-qq83-fmrr
- OSV GO-2026-5508
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.