Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

GHSA-hx4v-cxpf-vh8m

MEDIUM

GHSA-hx4v-cxpf-vh8m is a medium-severity (CVSS 5) Server-Side Request Forgery (SSRF) vulnerability in github.com/rancher/fleet. O3 Security confirms whether GHSA-hx4v-cxpf-vh8m is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Rancher Fleet has SSRF in Bundle Reader via Unvalidated Helm Repository URL in fleet.yaml

Also known asCVE-2026-44936GO-2026-5873
Published
Jul 1, 2026
Updated
Jul 7, 2026
Affected
4 pkgs
Patched
4 / 4
Exploits
None indexed
Exploitation data as of Jul 7, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Real-World Exposure

4 pkgs affected
🐹github.com/rancher/fleet🐹github.com/rancher/fleet🐹github.com/rancher/fleet🐹github.com/rancher/fleet

Real-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

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:

  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.

Patches

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.

Workarounds

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.

Credits

This security issue was reported by the following collaborators according to our responsible disclosure policy:

  • Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC).
  • FluentLogic's security team.

References

If you have any questions or comments about this advisory:

Affected Packages

4 total 4 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/rancher/fleet0.15.0&&< 0.15.20.15.2
🐹Gogithub.com/rancher/fleet0.14.0&&< 0.14.60.14.6
🐹Gogithub.com/rancher/fleet0.13.0&&< 0.13.110.13.11
🐹Gogithub.com/rancher/fleet0.12.0&&< 0.12.150.12.15

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/rancher/fleet. 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.

  2. Fix

    Update github.com/rancher/fleet to 0.15.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hx4v-cxpf-vh8m is resolved across your whole dependency graph.

  3. 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-hx4v-cxpf-vh8m 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-hx4v-cxpf-vh8m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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 admini
O3 Security · Impact-Aware SCA

Is GHSA-hx4v-cxpf-vh8m in your dependencies?

O3 detects GHSA-hx4v-cxpf-vh8m across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-hx4v-cxpf-vh8m: fleet (Medium 5) | O3 Security