Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.25.0, HTTPTriggerSpec.Validate() validated Methods, FunctionReference, Host, IngressConfig, and CorsConfig, but silently skipped RelativeURL and Prefix. Those two fields were validated at the CLI level only (pkg/fission-cli/cmd/httptrigger/create.go:83). The post-CRD-modernization webhook for HTTPTrigger was retired in favor of API-server CEL — and CEL had no rules on those fields either — so an HTTPTrigger created via kubectl apply or a direct Kubernetes REST API call bypassed every URL-level check. This issue has been patched in version 1.25.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.25.0, SanitizeFilePath in pkg/utils/utils.go validated that a path stayed under a safe directory by calling strings.HasPrefix(path, safedir). This is a lexical check, not a directory boundary check: /packages-extra/evil starts with /packages, so it passed. The function did not enforce a path-separator boundary, so any sibling directory whose name began with the safe-directory string was accepted. Callers included the builder's Clean handler (pkg/builder/builder.go:208) and the fetcher's Fetch / Upload handlers (pkg/fetcher/fetcher.go). A tenant who could pre-create or control a sibling directory under the fetcher / builder's shared volume could induce a write or read outside the intended safe directory. This issue has been patched in version 1.25.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.25.0, Unarchive in pkg/utils/zip.go joined each archive entry name with the destination directory via filepath.Join and wrote the result without checking whether the resolved path stayed under the destination. A zip entry named ../../tmp/evil therefore landed at /tmp/evil. An attacker who could control a Package.Spec.Source.URL or Deployment.URL archive could induce the fetcher (running as the per-environment pod's fission-fetcher sidecar) to write files anywhere that process could reach: into other tenants' /packages/<ns>/ directories, into mounted secret/config volumes, or into the fetcher's own binary. This issue has been patched in version 1.25.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.24.0, a tenant with environments.fission.io create/update RBAC can run privileged / allowPrivilegeEscalation / dangerous-capability containers in the Fission function or builder namespace, scheduled under the executor's high-privilege service account — enabling container-sandbox escape, host filesystem and network access, and potential node- and cluster-level compromise. This issue has been patched in version 1.24.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.24.0, Fission builder pods were created with ServiceAccountName: fission-builder and no AutomountServiceAccountToken: false, so the kubelet auto-mounted the service-account token into every container in the pod — including the user-supplied builder image. This issue has been patched in version 1.24.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.24.0, Fission's Environment CRD exposes spec.runtime.podSpec and spec.builder.podSpec, which are merged into the Kubernetes pod specs for runtime and builder pods. The merge logic propagated hostNetwork, hostPID, hostIPC, container privileged, and serviceAccountName from the user-supplied podspec with no filtering, and Environment.Validate performed no security-relevant checks on these fields. This issue has been patched in version 1.24.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.24.0, Fission's Container Executor path lets a tenant supply Function.spec.podspec directly; the executor merges it into the executor-built podspec and creates a Deployment whose pods run the user's container image. This issue has been patched in version 1.24.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.24.0, the Environment.spec.runtime.podSpec / spec.builder.podSpec passthrough lacked validation, and MergePodSpec propagated dangerous fields into the generated pods. This issue has been patched in version 1.24.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.24.0, the Fission Function admission webhook (pkg/webhook/function.go) validated that spec.secrets[].namespace and spec.configmaps[].namespace equalled the function's own namespace but performed no equivalent check on spec.environment.namespace. This issue has been patched in version 1.24.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.24.0, a Fission Function spec carries three reference types — Secret, ConfigMap, and Package. The first two were namespace-validated by the admission webhook; PackageRef.Namespace was not. This issue has been patched in version 1.24.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.24.0, a low-privilege developer who could create a KubernetesWatchTrigger (KWT) in their own namespace was able to establish a persistent surveillance channel over any other namespace. This issue has been patched in version 1.24.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.24.0, Fission's buildermgr controller processed Package CRDs without verifying that Package.spec.environment.namespace matched Package.metadata.namespace. This issue has been patched in version 1.24.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.23.0, before the round-1 security sweep, pkg/builder/builder.go passed Environment.spec.builder.command directly into exec.Command(...) after a strings.Fields split, with no validation of the executable path or its arguments. A user who could create or update Environment CRDs in a namespace observed by the buildermgr could thereby point the builder pod at any executable inside the builder image (e.g. /bin/sh -c '...') and execute arbitrary code in the builder pod context. This issue has been patched in version 1.23.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.23.0, Fission runtime pods were created with ServiceAccountName: fission-fetcher, and the fission-fetcher ServiceAccount was granted namespace-wide get on secrets and configmaps (it needs that to load function code, env vars, and config). The runtime pod's automounted token was reachable from inside the user's function container at /var/run/secrets/kubernetes.io/serviceaccount/token, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function's namespace — far beyond the Function.spec.secrets allowlist that the function specification suggests. This issue has been patched in version 1.23.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.23.0, 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. This issue has been patched in version 1.23.0.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.23.0, the Fission storagesvc component registers archive CRUD handlers (/v1/archive GET / POST / DELETE and /v1/archives list) directly on its HTTP router without performing any authentication or authorization. Any caller able to reach the storagesvc ClusterIP — including any other workload in the same Kubernetes cluster — could enumerate archive IDs, download archives belonging to other tenants, upload arbitrary archive content, and delete archives. This issue has been patched in version 1.23.0.

Astro is a web framework. Prior to version 10.0.2, the @astrojs/vercel serverless entrypoint reads the x-astro-path header and x_astro_path query parameter to rewrite the internal request path, with no authentication whatsoever. On deployments without Edge Middleware, this lets anyone bypass Vercel's platform-level path restrictions entirely. The override preserves the original HTTP method and body, so this isn't limited to GET. POST, PUT, DELETE all land on the rewritten path. A Firewall rule blocking /admin/* does nothing when the request comes in as POST /api/health?x_astro_path=/admin/delete-user. This issue has been patched in version 10.0.2.

astro

A security vulnerability has been detected in CodeGenieApp serverless-express up to 4.17.1. Affected by this issue is some unknown functionality of the file examples/lambda-function-url/packages/api/models/TodoList.ts of the component API Endpoint. The manipulation of the argument userId leads to authorization bypass. The attack is possible to be carried out remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A weakness has been identified in CodeGenieApp serverless-express up to 4.17.1. This affects an unknown part of the file utils/dynamodb.ts of the component Users Endpoint. This manipulation of the argument filter causes injection. The attack may be initiated remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

UptimeFlare is a serverless uptime monitoring & status page solution, powered by Cloudflare Workers. Prior to commit 377a596, configuration file uptime.config.ts exports both pageConfig (safe for client use) and workerConfig (server-only, contains sensitive data) from the same module. Due to pages/incidents.tsx importing and using workerConfig directly inside client-side component code, the entire workerConfig object was included in the client-side JavaScript bundle served to all visitors. This issue has been patched via commit 377a596.

lyc8503

Nuclio is a "Serverless" framework for Real-Time Events and Data Processing. Prior to version 1.15.20, the Nuclio Shell Runtime component contains a command injection vulnerability in how it processes user-supplied arguments. When a function is invoked via HTTP, the runtime reads the X-Nuclio-Arguments header and directly incorporates its value into shell commands without any validation or sanitization. This issue has been patched in version 1.15.20.

iguazio

Spin is an open source developer tool for building and running serverless applications powered by WebAssembly. When Spin is configured to allow connections to a database or web server which could return responses of unbounded size (e.g. tables with many rows or large content bodies), Spin may in some cases attempt to buffer the entire response before delivering it to the guest, which can lead to the host process running out of memory, panicking, and crashing. In addition, a malicious guest application could incrementally insert a large number of rows or values into a database and then retrieve them all in a single query, leading to large host allocations. Spin 3.6.1, SpinKube 0.6.2, and `containerd-shim-spin` 0.22.1 have been patched to address the issue. As a workaround, configure Spin to only allow access to trusted databases and HTTP servers which limit response sizes.