Multi-Tenant Auth Infrastructure.
Scalpel, not demolition.

A trust boundary that never existed.

The framework markets multi-tenancy as a built-in feature. Operators create tenants on a single core instance, each with its own user pool, login methods, and session configuration. The assumption — reinforced by the vendor’s own documentation — is that tenant boundaries enforce isolation.

They do not. A session created in Tenant A verifies successfully in Tenant B. The session object carries a tenant identifier. The request carries a tenant identifier. The verification layer never checks whether they match. Every request passes through the SDK, through the VPC, through every security layer the operator has deployed — and the core still does not enforce the boundary it was built to represent.

Acknowledged. Declined.

The vendor was notified in March 2026 with full proof-of-concept evidence across 13 findings. The response, in writing, confirmed the behavior exists and classified it as intentional: a “conscious decision” to align session validation with standard JWT library behavior.

The vendor recommended network-level mitigations — deploying behind a VPC with API key protection. This addresses the unauthenticated attack surface. It does not address the cross-tenant session trust flaw, which operates at the application layer within authenticated contexts.

No CVE was filed by the vendor. No advisory was published. No downstream notification was issued. The framework has 15,000+ GitHub stars and had zero CVEs before this engagement.

686 forks. 76 confirmed vulnerable.

Using the GitHub API, we enumerated every fork of the framework’s core repository. Each fork was scored by production-likelihood signals: organizational ownership, recent commit activity, custom descriptions, deployed homepages, sub-forks indicating downstream adoption.

76 forks confirmed vulnerable. Zero had independently patched the flaw. Zero had been notified by the vendor. The confirmed vulnerable set includes publicly traded companies, fintech operators, healthtech platforms, and enterprise authentication deployments.

These operators forked a codebase they believed was secure. They received no signal that a known architectural flaw existed in the session verification layer. The vendor’s silence is the exposure.

Targeted fix. No rebuild.

We mapped the session verification trust model end to end — from token issuance through SDK relay to core validation. The flaw sits at a specific boundary where tenant identity is carried but never enforced. The remediation enforces tenant boundary validation at the exact point where the trust model fails, without requiring a full codebase rebuild.

The vendor declined to remediate — likely because a proper fix touches the session verification trust model across the entire multi-tenant architecture. We have mapped that architecture. We deliver a scoped remediation that enforces tenant boundary validation without disrupting the existing deployment.

From disclosure to remediation.

What you receive.

• Vulnerability validation report specific to your fork and deployment
• Tenant boundary enforcement patch — session verification trust model remediation
• Verification testing confirming cross-tenant session isolation
• Hardening recommendations for related attack surface across the auth layer
• Executive compliance report for auditors, regulators, and board-level disclosure