NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
MEDIUM severity

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

MEDIUM

GHSA-mph8-9v29-pm42 is a medium-severity (CVSS 5.9) vulnerability in @axonflow/sdk. A fix is available for @axonflow/sdk — see the affected versions and patch details below.

Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of May 6, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

0other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@axonflow/sdknpm
31downloads / week

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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@axonflow/sdkall versions6.0.0npm install @axonflow/sdk@6.0.0

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @axonflow/sdk, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update @axonflow/sdk to 6.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mph8-9v29-pm42 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

## 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 fi
O3 Security · Impact-Aware SCA

Is GHSA-mph8-9v29-pm42 in your dependencies?

Find it across npm, including transitive dependencies.

Scan my dependencies How O3 SCA works
axonflow-sdk-typescript: Webhook signing-key…