What is the CVSS score of CVE-2026-50565?

CVE-2026-50565 has a CVSS 3.1 base score of 4.9 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-50565?

Yes, a patch is available for CVE-2026-50565. Update the affected software to the latest version immediately.

Fission CVE-2026-50565

EUVD-2026-36101 MEDIUM

Execution with Unnecessary Privileges (CWE-250)

2026-06-10 GitHub_M

GHSA-8wcj-mfrc-jx5q

Privilege Escalation Kubernetes

4.9

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

4.9 MEDIUM

AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Jun 10, 2026 - 20:01 EUVD

Source Code Evidence Fetched

Jun 10, 2026 - 19:03 vuln.today

Analysis Generated

Jun 10, 2026 - 19:03 vuln.today

DescriptionNVD

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.

AnalysisAI

Kubernetes service account token exposure in Fission serverless framework prior to v1.24.0 allows authenticated high-privilege users to escalate cluster privileges via a malicious builder image. Builder pods were created with ServiceAccountName set to fission-builder but without AutomountServiceAccountToken: false, causing the Kubernetes kubelet to automatically inject the fission-builder service account credential into every container in the pod - including untrusted, user-supplied builder images. An attacker with sufficient Fission privileges to register or modify builder environments can exploit this to read the mounted token and authenticate directly to the Kubernetes API using the fission-builder service account's RBAC permissions. No public exploit identified at time of analysis; vendor-released patch is available in v1.24.0.

Technical ContextAI

Fission is a Kubernetes-native serverless framework (CPE: cpe:2.3:a:fission:fission:*:*:*:*:*:*:*:*) that orchestrates build operations via a builder manager component (pkg/buildermgr/envwatcher.go). When a builder environment is registered, Fission creates a Kubernetes Pod with a user-supplied container image alongside an internal fetcher sidecar. The pod was assigned the fission-builder Kubernetes ServiceAccount without setting AutomountServiceAccountToken: false, which is the mechanism that instructs the kubelet to suppress automatic credential injection. By Kubernetes default behavior, the kubelet mounts the ServiceAccount's JWT bearer token into every container at /var/run/secrets/kubernetes.io/serviceaccount/token. This means the user-supplied builder image - which is external and untrusted by nature - received the same fission-builder token as the privileged fetcher sidecar. CWE-250 (Execution with Unnecessary Privileges) captures the root cause: the builder pod operated with broader credential access than its individual components required. The fix in PR #3390 sets AutomountServiceAccountToken: false at pod spec level and re-mounts the token exclusively on the fetcher container via a projected volume, isolating the credential from user-supplied containers. Additional hardening re-clamps the flag after MergePodSpec calls to prevent a patch-supplied PodSpec from inadvertently re-enabling the auto-mount.

RemediationAI

Upgrade Fission to version 1.24.0, which is the vendor-released patch confirmed by the GitHub release tag at https://github.com/fission/fission/releases/tag/v1.24.0 and the security advisory GHSA-8wcj-mfrc-jx5q. The fix sets AutomountServiceAccountToken: false at pod spec level and restricts the fission-builder service account token mount exclusively to the fetcher sidecar via a projected volume, preventing user-supplied builder images from accessing the credential. For deployments that cannot immediately upgrade, a compensating control is to audit and minimize the RBAC permissions bound to the fission-builder service account - reducing the permissions granted by the token limits the blast radius if the token is read by a malicious builder image, though this does not prevent the token from being mounted and read. Another option is to restrict who can register or modify Fission builder environments at the Kubernetes RBAC level, tightening the PR:H requirement further so fewer principals can trigger builder pod creation. Both workarounds have the trade-off of requiring ongoing RBAC management and do not eliminate the underlying token injection; upgrading to v1.24.0 is the only definitive remediation.