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 `known_hosts` 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 known_hosts file, then Fleet will correctly check the authenticity of the presented certificate.
Affected: Go: github.com/rancher/fleet
### 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 `known_hosts` 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 known_hosts file, then Fleet will correctly check the authenticity of the presented certificate.
Please consult the associated [MITRE ATT&CK - Technique - Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1557/) 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 `known_hosts` 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 namespace; 3. If that secret does not exist, in a (new) `known-hosts` config map installed by Fleet, populated statically with public entries shared by a few git providers: Github, Gitlab, Bitbucket, Azure DevOps;
- Git cloner: same as above.
- `fleet apply` command: same as above. The command reads entries from a `FLEET_KNOWN_HOSTS` environment variable. That command is typically run within a container insid…
govulncheck-vulndb-0.0.20250506T153719-1.1 on GA media