GHSA-248h-974q-xrc2 json
axonflow-sdk-java: Webhook signing-key (HMAC-SHA256) not exposed by SDK type, preventing signature verification
published 6mo ago modified 2mo ago
- 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 prior to 7.0.0.
## 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
- maven com.getaxonflow:axonflow-sdk 7.0.0
Is GHSA-248h-974q-xrc2 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 |
|---|---|---|---|
| maven | com.getaxonflow:axonflow-sdk | <7.0.0 |
7.0.0 |
Classification
References
-
github.com
/getaxonflow/axonflow-sdk-java/pull/156
web
-
github.com
/getaxonflow/axonflow-sdk-java/commit/53c049a2ff34e7d9ef428bf6f24dac050200f5bc
web
-
github.com
/getaxonflow/axonflow-sdk-java/security/advisories/GHSA-248h-974q-xrc2
web
-
github.com
/getaxonflow/axonflow-sdk-java
package
-
github.com
/getaxonflow/axonflow-sdk-java/blob/bac65ce6143327e1f9201d0dc73815e93dcdb47c/CHANGELOG.md?plain=1#L632
web
Sources
- GitHub Advisory GHSA-248h-974q-xrc2
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.