# GHSA-mph8-9v29-pm42: axonflow-sdk-typescript: Webhook signing-key (HMAC-SHA256) not exposed by SDK type, preventing signature verification

> Developers using the AxonFlow SDK cannot verify webhook signatures, allowing attackers to forge events if the webhook URL is known.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 6 May 2026

## What is GHSA-mph8-9v29-pm42?

GHSA-mph8-9v29-pm42 is a vulnerability in @axonflow/sdk, published on 6 May 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

## 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.0 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.

## Which versions are affected by GHSA-mph8-9v29-pm42?

2 open source packages ship an affected version, including @axonflow/sdk.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `@axonflow/sdk` | npm | All versions | 6.0.0 |
| `@axonflow/sdk` | npm | All versions | 6.0.0 |

## How do I fix GHSA-mph8-9v29-pm42?

Upgrade @axonflow/sdk to 6.0.0 or later.

## Is GHSA-mph8-9v29-pm42 being exploited?

There is no known exploitation of GHSA-mph8-9v29-pm42 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-mph8-9v29-pm42 and fix it if it is affected.

What it is: GHSA-mph8-9v29-pm42 is a vulnerability in @axonflow/sdk, published on 6 May 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-mph8-9v29-pm42 in the wild and no public exploit code.

Affected packages and fixed versions:
- @axonflow/sdk (npm): affected all versions; fixed in 6.0.0
- @axonflow/sdk (npm): affected all versions; fixed in 6.0.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-mph8-9v29-pm42/ (Markdown: https://insights.sbomify.com/GHSA-mph8-9v29-pm42/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-mph8-9v29-pm42

---
From sbomify Insights: https://insights.sbomify.com/GHSA-mph8-9v29-pm42/
Summaries are generated and may contain mistakes; the official description above is the record.