Fission router exposes /fission-function/<ns>/<name> on its public listener, allowing invocation of any function without an HTTPTrigger
Description
Summary
The Fission router registers an internal-style route — /fission-function/ and /fission-function// — for every Function object, independent of whether any HTTPTrigger exists for that function. The route was mounted on the same listener as user-defined HTTPTriggers (svc/router, port 8888), so any caller who could reach the router could invoke any function by guessing its metadata.name (and namespace), bypassing the host / path / method / method-allow-list restrictions encoded in HTTPTrigger objects.
Affected component
pkg/router/httpTriggers.go:280-284—internalRouteregistration viautils.UrlForFunction(fn.Name, fn.Namespace), bound to the function handler.
Impact
An external caller who reaches the public router could:
- Invoke functions that the operator intentionally did not publish through an
HTTPTrigger(e.g. functions used only as Kubewatcher / Timer / MessageQueue trigger targets, internal helpers, or sample functions). - Bypass
HTTPTrigger-level restrictions: a function published only onPOST /api/v2/foocould still be invoked asGET /fission-function//with arbitrary headers and body. - Enumerate function names by probing the response semantics (404 vs 200 vs 502 from cold start).
In multi-tenant deployments this also crosses tenant boundaries when functions in tenant namespace B are reachable from tenant A's pods (or from anywhere on the internet if the router is ingress-exposed).
Root cause
/fission-function/... was historically used by internal trigger sources (timer, kubewatcher, mqtrigger) that share the cluster network with the router, but the route was registered on the public listener that also serves user HTTPTriggers. The two audiences were never separated.
Fix
Released in v1.23.0:
- PR #3369 (commit
814d232c): the router now runs two listeners — a public listener (port 8888,svc/router) that serves only user-definedHTTPTriggers,/router-healthz, and/_version, and an internal listener (port 8889,svc/router-internal, ClusterIP-only) that exclusively serves/fission-function//. The internal listener is wrapped with thepkg/auth/hmac.ServiceVerifierusing theServiceRouterInternalderived key — internal trigger sources sign their requests with a per-service HKDF-derived key from a cluster master secret. Empty master secret falls back to pass-through (preserves compatibility for clusters not yet rotating in a secret). - PR #3365 (commit
0aa24788): added per-serviceNetworkPolicyresources tocharts/fission-all, ensuringsvc/router-internalis only reachable fromkubewatcher,timer,mqtrigger, andmqt-kedapods inside the release namespace. - The internal-listener path itself is still **
/fission-function//** — only its location moved.
Mitigation (until upgrade)
- Apply a
NetworkPolicyto the Fission namespace that allows ingress tosvc/router(port 8888) only from the consuming project's ingress controller, and blocks/fission-function/...at the ingress layer (path-based filter on the ingress). - Avoid exposing the router directly via LoadBalancer/NodePort; front it with an ingress that path-filters
/fission-function/. - Treat function
metadata.nameas not a secret — names should not be the access control boundary.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
The Fission router exposes internal /fission-function/ routes on its public listener, allowing unauthenticated invocation of any function without an HTTPTrigger.
The Fission router registers an internal-style route (/fission-function/ and /fission-function//) for every Function object, regardless of whether an HTTPTrigger exists. This route was mounted on the same listener (port 8888) as user-defined HTTPTriggers, meaning any caller reaching the router could invoke any function by guessing its name and namespace [1][2].
An attacker can craft HTTP requests to these internal routes, bypassing the host, path, method, and allow-list restrictions enforced by HTTPTrigger objects. Moreover, an attacker can enumerate valid function names by probing response codes (404 vs 200 vs 502 from cold starts) [2][4].
The impact is severe: an external attacker can invoke functions that the operator never intended to expose publicly (e.g., internal helpers, timer-triggered functions), bypass HTTPTrigger-level access controls, and in multi-tenant environments, cross tenant boundaries by reaching functions in other namespaces [4].
The fix has been released in Fission v1.23.0 (PR #3369). The router now runs two separate listeners: a public listener (port 8888) serving only user-defined HTTPTriggers, and an internal listener (port 8889) serving the /fission-function/ routes, with optional HMAC authentication to restrict internal access [1][3].
- Extend HMAC application-layer auth to fetcher, builder, executor, and router-internal by sanketsudake · Pull Request #3369 · fission/fission
- CVE-2026-46614 - GitHub Advisory Database
- Release v1.23.0 · fission/fission
- Fission router exposes /fission-function/<ns>/<name> on its public listener, allowing invocation of any function without an HTTPTrigger
AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
5News mentions
0No linked articles in our index yet.