Ad
 
Learn More

Supergraph JWT reuse is the Important line in Tyk 5.15.1

Tyk Gateway v5.15.1 is flagged Important as a security fix. The partner-break line is federated GraphQL supergraph reusing the first caller's JWT across users (TT-17921), not the dependency CVE bump list.

Written by Watch Changelog Team

•3 min read

Supergraph JWT reuse is the Important line in Tyk 5.15.1

So Tyk Gateway put v5.15.1 on the feed, dated October 2, 2026. We flagged it Important as a security fix. Recency wants the calm opener: patch tag, golang.org/x/text and gRPC bumps, OpenTelemetry exporter pins, kin-openapi upgrade, a named CVE in the OTLP path (CVE-2026-81870). Fine. Those are the lines people paste into an API platform channel when they skim a gateway release.

The line that matters, to the best of my understanding, is TT-17921 (merged into the 5.15 line via #8644): federated GraphQL supergraph and related GraphQL modes could reuse the first caller's JWT across users, and could share HTTP responses via single-flight. Request-scoped values (round tripper, resolved upstream headers, upstream response) were sitting on state that outlived the request: the shared per-API http.Client, the plan cache, and the upstream connection-reuse key. Under concurrency, which request's credentials a fetch used depended on timing.

That is the partner ticket shape. Someone already thought "we terminate auth at the gateway, upstream only sees what we intend." Then a second subscriber or supergraph caller lands on a pooled upstream connection keyed from unresolved headers, and the first caller's Authorization (or custom auth header) is still attached. Scope is Tyk installs that run GraphQL in proxy-only (including WebSocket subscriptions), subgraph, Universal Data Graph, or supergraph, especially when strip_auth_data is false so consumer auth headers are meant to forward upstream. If every GraphQL client shares one service account and you never mix tenants on one gateway process, this specific path is quieter. If partners, tenants, or end users present distinct JWTs or API keys through the same GraphQL API, treat credential isolation as the reason this patch is not optional.

What operators should check first is not the Docker tag on the release page. It is which GraphQL APIs still sit on a 5.15.0 (or earlier 5.15) image with concurrent subscriptions or federated supergraph traffic. Confirm strip_auth_data settings, whether WebSocket or SSE subscriptions are enabled, and whether upstream auth is expected to differ per caller. After upgrade, expect subscriptions to end on API reload (they previously outlived reload on context.Background()). That is a behavior change worth a status note, not a reason to skip the fix.

The same release also carries the dependency CVE train (x/text, gRPC, opentelemetry, avro replace path, kin-openapi, OTLP exporters including CVE-2026-81870). Those matter for supply-chain and scanner noise. They are not the hero. The hero is request-scoped GraphQL transport state so one caller's JWT stops riding another caller's upstream fetch.

I keep almost filing Tyk under "gateway patch train, ignore until the Helm chart bumps." Kind of the wrong habit when you sell into teams that put Tyk in front of multi-tenant GraphQL and treat the gateway as the auth boundary. Tracking product change here means reading past the CVE laundry list and asking which line changes a partner ticket. Let's say the talking point is not "5.15.1 shipped dependency bumps." It is federated supergraph could reuse the first caller's JWT across users (TT-17921), and 5.15.1 closes that isolation hole, then yes mention the OTLP and gRPC CVE pins. We pull it into a uniform entry shape at /sources/tyk.releases. Same JSON as everything else. Recency still wants the patch tag. Recency is not the supergraph JWT reuse.

Official notes: Tyk Gateway release notes. Tag: v5.15.1. Fix PR: TT-17921 / #8602.