Listen to this Post
How the CVE works (vulnerability mechanics):
- Fission router automatically registers internal route `/fission-function/
` and `/fission-function/ / ` for every Function object. - This registration occurs irrespective of any existing HTTPTrigger for that function.
- The vulnerable registration code resides in
pkg/router/httpTriggers.go:280-284, where `utils.UrlForFunction` is bound to the function handler. - This route is mounted on the same public listener (port 8888, service
svc/router) that serves all user-defined HTTPTriggers. - Because of this co‑location, any caller with network access to the router can reach any function simply by guessing its `metadata.name` (and namespace).
- The internal route does not honour any of the host, path, method, or allow‑list restrictions defined in an HTTPTrigger.
- An attacker can therefore trigger a function that the operator intentionally kept unpublished (e.g., a Kubewatcher or Timer target).
- Even functions only declared for POST on a specific path can be invoked via an arbitrary GET or POST with any headers and body.
- By probing response codes (404 vs 200 vs 502 from cold start) the attacker can also enumerate all function names.
- In multi‑tenant installations the breach crosses tenant boundaries – pods in tenant namespace A can invoke functions in tenant namespace B.
- If the router is exposed to the internet (via LoadBalancer or NodePort), any remote caller can exploit the issue.
- The root cause is that the internal route was never separated from the public listener.
- Historically the internal pattern was used solely by trusted components (timer, kubewatcher, mqtrigger) on the cluster network.
- Because both audiences shared the same listener, there was no access control between them.
- The fix introduced two separate listeners in v1.23.0:
- Public listener (port 8888) serves only user HTTPTriggers, `/router-healthz` and
/_version. - Internal listener (port 8889, ClusterIP‑only) exclusively serves the `/fission-function/…` routes.
- The internal listener enforces HMAC‑based signatures derived from a cluster master secret (service
router‑internal). - Network policies (added in the same release) restrict the internal listener’s reachability to only the needed internal pods.
- Until an upgrade, an attacker who can connect to port 8888 can invoke any function, bypassing all HTTP‑level restrictions.
DailyCVE Form (3‑words‑max per line):
Platform: Kubernetes Fission Version: < v1.23.0 Vulnerability: Auth bypass Severity: Critical date: 2023‑12‑07 Prediction: v1.23.0 released
What Undercode Say:
Check current Fission version (should be < v1.23.0) kubectl get deploy -n fission fission-router -o yaml | grep image Test exposure of internal route (requires access to router) kubectl run test-pod --rm -it --image=alpine/curl --restart=Never -- \ curl -v http://fission-router.fission:8888/fission-function/default/my-secret-function Apply NetworkPolicy as temporary mitigation cat <<EOF | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: block-internal-route namespace: fission spec: podSelector: matchLabels: app: router ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ingress-nginx ports: - port: 8888 policyTypes: - Ingress EOF Upgrade to v1.23.0 to apply the official fix helm upgrade fission fission/fission --version v1.23.0
Exploit:
An attacker with network access to the Fission router (e.g., from another pod in the cluster or from the internet if the router is exposed) can invoke any function by sending a crafted HTTP request to the internal route. For example:
GET /fission-function/<namespace>/<function-name> HTTP/1.1 Host: fission-router:8888
The request is forwarded directly to the function pod, bypassing all HTTPTrigger restrictions on host, path, method, or allowed‑headers. By enumerating namespace and function names (using response status codes) the attacker can discover and execute every function in the cluster.
Protection from this CVE:
- Immediately upgrade to Fission v1.23.0 or later.
- If an immediate upgrade is impossible, apply a NetworkPolicy that allows ingress to the router (port 8888) only from trusted sources (e.g., the ingress controller) and rejects all requests containing
/fission-function/. - Never expose the router directly via LoadBalancer or NodePort; always place an ingress controller in front with path‑based filtering.
- Treat function names as not secret; they must never be the only access control boundary.
Impact:
- Bypass of intended access controls – unpublished functions become reachable.
- Tenant isolation breach – in multi‑tenant deployments, a user in one tenant can invoke functions belonging to another tenant.
- Function enumeration – an attacker can discover all function names by probing the internal route.
- Unauthorised data access / lateral movement – any function that performs sensitive operations can be triggered by an unauthorised actor, leading to potential data leakage or privilege escalation.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
