GHSA-3g33-6vg6-27m8 is a critical-severity (CVSS 9.8) CWE-284 vulnerability in github.com/fission/fission. O3 Security confirms whether GHSA-3g33-6vg6-27m8 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Fission router exposes /fission-function/<ns>/<name> on its public listener, allowing invocation of any function without an HTTPTrigger
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-3g33-6vg6-27m8.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-3g33-6vg6-27m8 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 358,265 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/fission/fissionReal-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
The Fission router registers an internal-style route — /fission-function/<name> and /fission-function/<ns>/<name> — 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/<ns>/<name>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/<ns>/<name>. 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/<ns>/<name>— 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/fission/fission | all versions | 1.23.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/fission/fission. 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.
Fix
Update github.com/fission/fission to 1.23.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3g33-6vg6-27m8 is resolved across your whole dependency graph.
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.
How O3 protects you
O3 pinpoints whether GHSA-3g33-6vg6-27m8 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-3g33-6vg6-27m8. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-3g33-6vg6-27m8 in your dependencies?
O3 detects GHSA-3g33-6vg6-27m8 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.