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
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact What kind of vulnerability is it? Who is impacted? Both in karmadactl and karmada-operator, it is possible to supply a filesystem path, or an HTTP(s) URL to retrieve the custom resource definitions(CRDs) needed by karmada. The CRDs are downloaded as a gzipped tarfile and are vulnerable to a TarSlip vulnerability. An attacker able to supply a malicious CRD file into a karmada initialization could write arbitrary files in arbitrary paths of the filesystem. Patches Has the problem been patched? What versions should users upgrade to? From karmada version v1.12.0, when processing custom CRDs files, CRDs archive verification is utilized to enhance file system robustness. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? When using karmadactl init to set up Karmada, if you need to set flag --crd to customize the CRD files required for karmada initialization, you can manually inspect the CRD files to check whether they contain sequences such…
Recommended action: Upgrade to 1.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? The PULL mode clusters registered with the karmadactl register command have excessive privileges to access control plane resources. By abusing these permissions, an attacker able to authenticate as the karmada-agent to a karmada cluster would be able to obtain administrative privileges over the entire federation system including all registered member clusters. Patches Has the problem been patched? What versions should users upgrade to? Since Karmada v1.12.0, command karmadactl register restricts the access permissions of pull mode member clusters to control plane resources. This way, an attacker able to authenticate as the karmada-agent cannot control other member clusters in Karmada. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? Restricts the access permissions of pull mode member clusters to control plane resources according to Karmada Component Permissions Docs. References Are…
Recommended action: Upgrade to 1.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? The Karmada components deployed with karmadactl, karma-operator, and helm chart take Golang default cipher suites as part of the TLS protocol, which includes the insecure algorithm. Referring to https://github.com/golang/go/issues/41476#issuecomment-694914728, the 3DES algorithm vulnerability is very unlikely to be attacked. However, to address the concerns and to avoid being disturbed by the security scanner, Karmada has decided to limit the cipher suites to exclude the insecure 3DES algorithm and accordingly release this security advisory. The components affected are： - karmada-apiserver - karmada-aggregated-apiserver - karmada-search - karmada-metrics-adapter - etcd Patches Has the problem been patched? What versions should users upgrade to? From Karmada v1.8.0, when deploying Karmada with karmadactl, karma-operator, and helm chart, the default minimum TLS version of components(include karmada-apiserver,…
Recommended action: Upgrade to 1.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.