Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

GHSA-9h64-2846-7x7f

CRITICAL

Axonflow fixed bugs by implementing multi-tenant isolation and access-control hardening

Published
May 6, 2026
Updated
May 6, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected
🐹github.com/getaxonflow/axonflow

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Eight independently-filed bug fixes in the v7.1.3 → v7.5.0 release window collectively close a set of multi-tenant isolation, access-control, and policy-enforcement defects in the AxonFlow platform. They are filed as a single consolidated advisory because the recommended remediation is a single platform upgrade.

Affected versions

< 7.5.0. Specific items affect different earlier minors; see Impact below.

Patched versions

>= 7.5.0.

Impact

#ItemAffectedPatchedCWE
1MAP execution multi-tenant isolation. A body-supplied org_id could override the Basic-auth-derived org for both execution recording and policy evaluation. In multi-tenant deployments with shared agents, this could record one tenant's request under another tenant's audit log and evaluate it under the wrong tenant's policy set.< 7.4.5>= 7.4.5CWE-863
2Cross-tenant audit-log leak via evidence/explain handlers. The handlers behind /api/v1/evidence/* and /api/v1/decisions/*/explain failed open when the tenant context was missing, returning data scoped to a different tenant or returning data without scope.< 7.2.0>= 7.2.0CWE-200, CWE-863
3License-validation bypass on onboard-customer. The portal customer-onboard endpoint lacked authentication and license-key validation, allowing unauthenticated callers to invoke the onboard flow.< 7.2.0>= 7.2.0CWE-862
4Tenant-scope fail-open on evidence/explain. Distinct from item 2: when tenant headers were absent, the handler defaulted to a permissive read scope rather than refusing the request.< 7.2.0>= 7.2.0CWE-862
5Internal-service auth fallback bypass in non-Community modes. Evaluation/Enterprise builds carried an auth fallback path that, under specific request shapes, could be exploited to bypass apiAuthMiddleware.< 7.2.0>= 7.2.0CWE-863
6Login timing / org-existence disclosure on the portal. The login handler returned different timing and response bodies for invalid-org vs invalid-password, allowing org enumeration.< 7.1.3>= 7.1.3CWE-208
7Portal DoS via unbounded request body. The portal accepted unbounded request bodies, allowing memory-exhaustion attacks. Capped at 1 MiB.< 7.1.5>= 7.1.5CWE-770
8SQL-injection enforcement regression on try.getaxonflow.com. The Community SaaS hosted endpoint inherited the warn SQLi default introduced in v6.2.0, allowing SQL-injection-shaped requests to pass governance to the LLM. Self-hosted deployments were unaffected unless they manually changed the default.< 7.5.0 (try.getaxonflow.com only)>= 7.5.0CWE-89

Remediation

Upgrade to AxonFlow platform v7.5.0 or later. No configuration changes required — the platform is purely additive and existing API/SDK callers continue to work.

For users who can't upgrade immediately, item-specific mitigations:

  • Items 1–5: ensure the agent middleware sets X-Org-ID / X-Tenant-ID from authenticated identity at the ingress, never accepting body-supplied identity.
  • Item 8 (Community SaaS): SQLI_ACTION=block can be set explicitly via the agent task definition; v7.5.0 makes this the default.

Resources

Credit

Identified by AxonFlow internal security review during the April 2026 quality-freeze epic.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/getaxonflow/axonflowall versions7.5.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 github.com/getaxonflow/axonflow. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/getaxonflow/axonflow to 7.5.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9h64-2846-7x7f 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-9h64-2846-7x7f is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-9h64-2846-7x7f. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary Eight independently-filed bug fixes in the v7.1.3 → v7.5.0 release window collectively close a set of multi-tenant isolation, access-control, and policy-enforcement defects in the AxonFlow platform. They are filed as a single consolidated advisory because the recommended remediation is a single platform upgrade. ## Affected versions `< 7.5.0`. Specific items affect different earlier minors; see Impact below. ## Patched versions `>= 7.5.0`. ## Impact | # | Item | Affected | Patched | CWE | |---|---|---|---|---| | 1 | **MAP execution multi-tenant isolation.** A body-supplied `o
O3 Security · Impact-Aware SCA

Is GHSA-9h64-2846-7x7f in your dependencies?

O3 detects GHSA-9h64-2846-7x7f across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.