Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact A vulnerability in Fleet for Rancher Manager affects multi-tenancy environments where different tenants share the same downstream clusters (e.g., different privileged or untrusted teams inside the same organization). On unpatched versions, tenants could bypass restrictions to access any config map or secret across all namespaces on the downstream cluster. They can create cluster-wide resources using HelmOp or Bundle without authorization. Specifically, an attacker can exploit this vulnerability in the following ways: 1. Use valuesFrom in fleet.yaml(through a GitRepo resource) or a HelmOp resource to read the contents of any secret an on the downstream cluster, provided they know or can guess the name, namespace, and key. 2. Deploy HelmOp and Bundle resources without being restricted to a specific service account for the Fleet agent. If you use Fleet in a multi-tenant environment, it's recommended that you: - Review your cluster and Fleet deployments logs for indicators of…
Recommended action: Upgrade to 0.15.2, 0.14.6, 0.13.11 or 0.12.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerability has been identified in Fleet when the helmRepoURLRegex field isn't set on a GitRepo resource. Fleet's bundle reader forwards Helm authentication credentials (BasicAuth) to any URL specified in the helm.repo field of a fleet.yaml file. An attacker with git push access to a Fleet-monitored repository can exploit this behavior by specifying a malicious URL in helm.repo. This causes the Fleet controller to send the configured Helm repository credentials to the attacker’s server. As a result, the attacker can capture the username and password that an administrator configured to access a private Helm chart repository. However, the response body from the attacker's server isn't included in the error message (this behavior was fixed in Fleet v0.13.3 and later), which prevents additional internal data from leaking through the status condition. The final severity of this vulnerability depends on the specific permissions of the leaked credentials. Fleet recommends you to:…
Recommended action: Upgrade to 0.15.2, 0.14.6, 0.13.11 or 0.12.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerability has been identified in Fleet when the webhook endpoint is configured without a secret; an attacker can forge webhook requests. The attacker doesn't need to know the specific repository or path configured in the GitRepo resource to make Fleet process these requests. An attacker can exploit this vulnerability to cause the following impacts: 1. Trigger continuous repository re-cloning, which increases network traffic and can deplete resources on the management cluster. 2. Downgrade running services to any historical revision available in the remote Git repository. This risk applies if the attacker has read access to the target Git repository and knows its configured path. Please consult the associated MITRE ATT&CK - Technique - T1499.004: Endpoint Denial of Service for further information about this category of attack. Patches To resolve this vulnerability, upgrade Fleet to a patched version. This upgrade version escapes the URL and path to the remote repository…
Recommended action: Upgrade to 0.15.2, 0.14.6, 0.13.11 or 0.12.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerability has been identified in Fleet's agent-side deployer, which did not filter security-sensitive keys from namespaceLabels in fleet.yaml (or BundleDeployment.spec.options.namespaceLabels) when applying them to the target namespace. An attacker with git push access to a Fleet-monitored repository could overwrite Pod Security Standards (PSS) enforcement labels on a target namespace. This allows the attacker to weaken admission controls and deploy workloads that PSS policies would otherwise block. Important: The final impact on confidentiality, integrity, and availability depends on the specific permissions of the leaked credentials. Fleet team recommends you: 1. Review your system for potentially leaked credentials. 2. Replace any credentials that may be compromised. Please consult the associated MITRE ATT&CK - Technique - Disable or Modify Tools for further information about this category of attack. Patches To fix this issue, upgrade to a patched version. The updated…
Recommended action: Upgrade to 0.15.2, 0.14.6, 0.13.11 or 0.12.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
0.15.10.14.50.12.140.13.100.11.13· Vendor fix available
Issue
Impact Fleet's Helm deployer did not fully apply ServiceAccount impersonation in two code paths, allowing a tenant with git push access to a Fleet-monitored repository to read secrets from any namespace on every downstream cluster targeted by their GitRepo. Helm lookup bypass: The Helm template engine ran Kubernetes API queries with the fleet-agent's cluster-admin credentials instead of the impersonated ServiceAccount. A chart template could therefore access resources beyond the tenant's RBAC scope. valuesFrom bypass: Secret and ConfigMap references in fleet.yaml helm.valuesFrom were read using the fleet-agent's cluster-admin client. A tenant could reference resources in namespaces the impersonated ServiceAccount has no access to. Both issues break Fleet's multi-tenant impersonation boundary. The leaked credentials may belong to external services, making the full impact non-deterministic. Single-tenant deployments where all users are trusted are not affected. Important: - For the…
Recommended action: Upgrade to 0.15.1, 0.14.5, 0.13.10 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
0.11.100.13.1-0.20250806151509-088bcbea7edb0.12.6· Vendor fix available
Issue
Impact A vulnerability has been identified when using Fleet to manage Helm charts where sensitive information is passed through BundleDeployment.Spec.Options.Helm.Values may be stored in plain text. This can result in: 1. Unauthorized disclosure of sensitive data: Any user with GET or LIST permissions on BundleDeployment resources could retrieve Helm values containing credentials or other secrets. 2. Lack of encryption at rest: BundleDeployment is not configured for Kubernetes encryption at rest by default, causing sensitive values to remain unencrypted within the cluster datastore. This behavior differs from Helm v3’s default approach, where chart state — including values — is stored in Kubernetes secrets, benefiting from built-in protection mechanisms. In affected scenarios, credentials and other sensitive information are exposed both at rest and in responses to API calls. Please consult the associated MITRE ATT&CK - Technique - Credentials from Password Stores for further…
Recommended action: Upgrade to 0.13.1-0.20250806151509-088bcbea7edb (pre-release), 0.12.6 or 0.11.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerability has been identified within Fleet where, by default, Fleet will automatically trust a remote server’s certificate when connecting through SSH if the certificate isn’t set in the knownhosts file. This could allow the execution of a man-in-the-middle (MitM) attack against Fleet. In case the server that is being connected to has a trusted entry in the knownhosts file, then Fleet will correctly check the authenticity of the presented certificate. Please consult the associated MITRE ATT&CK - Technique - Adversary-in-the-Middle for further information about this category of attack. Patches Patched versions include releases v0.10.12, v0.11.7 and v0.12.2. The fix involves some key areas with the following changes: - Git latest commit fetcher sources knownhosts entries from the following locations, in decreasing order of priority: 1. Secret referenced in a GitRepo’s clientSecretName field; 2. If no secret is referenced, in a gitcredential secret located in the GitRepo’s…
Recommended action: Upgrade to 0.12.2, 0.11.7 or 0.10.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.