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: 1. Review your system for potentially leaked credentials. 2. Replace any credentials that might be compromised.
Please consult the associated MITRE ATT&CK - Technique - Stored Data Manipulation and MITRE ATT&CK - Technique - Steal Application Access Token for further information about this category of attack.
To resolve this vulnerability, upgrade to a patched version of Fleet. The patched version of Fleet now requires you to set the helmRepoURLRegex field on the GitRepo. If the helmRepoURLRegex is empty or missing, Fleet won’t send credentials, regardless of the URL specified in fleet.yaml.
When you upgrade, a Helm pre-upgrade job automatically migrates existing GitRepo resources that have helmSecretName or helmSecretNameForPaths configured but lack a helmRepoURLRegex. The migration job performs the following actions:
The job extracts the scheme and host from the Helm repository URLs already stored in the resource's Bundles. For example, a GitRepo with Bundles referencing https://charts.example.com/stable receives helmRepoURLRegex: "^https://charts\.example\.com/". This limits credential forwarding to the origins already in use before the upgrade.
Migrated resources are annotated with fleet.cattle.io/helm-regex-auto-migrated: "true" so you can easily audit them.
If no Bundles with Helm repository URLs exist during the migration (for example, if the GitRepo has never successfully synced), helmRepoURLRegex remains empty and credentials aren't forwarded. You must set this field manually before Fleet will send credentials.
The migration job runs only once per installation and records its status in a ConfigMap named fleet-helm-url-regex-migrated in the Fleet system namespace. Any GitRepo resources you create after the upgrade require an explicit helmRepoURLRegex to forward credentials.
Patched versions of Fleet include releases v0.15.2, v0.14.6, 0.13.11, and v0.12.15.
If you cannot immediately upgrade to a patched version, use the following methods to mitigate the risk and audit your environment.
Set helmRepoURLRegex on all GitRepo resources that use helmSecretName. Ensure the regular expression matches only your legitimate Helm repository URL.
Example configuration:
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
name: my-app
namespace: fleet-local
spec:
repo: https://git.example.com/org/my-app.git
helmSecretName: helm-creds
helmRepoURLRegex: "^https://charts\\.example\\.com/.*"
After upgrading to a patched version, review all auto-migrated GitRepo resources by running the following command:
kubectl get gitrepo -A -o json | \
jq -r '.items[] | select(.metadata.annotations["fleet.cattle.io/helm-regex-auto-migrated"] == "true") | "\(.metadata.namespace)/\(.metadata.name): \(.spec.helmRepoURLRegex)"'
Verify that the auto-derived regular expression matches only your intended Helm repository origins. If a regular expression is broader than necessary, replace it with a more specific pattern.
This security issue was reported by the following collaborators according to our responsible disclosure policy:
If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.
{
"github_reviewed_at": "2026-07-01T20:45:05Z",
"nvd_published_at": null,
"github_reviewed": true,
"cwe_ids": [
"CWE-918"
],
"severity": "MODERATE"
}