[GHSA-wccg-v638-j9q2] karmada vulnerable to arbitrary code execution via a crafted command

[RainbowMango]

Updates

• Affected products

Comments
I am a maintainer of the affected project, karmada-io/karmada (GitHub: @RainbowMango). I am requesting that this advisory be withdrawn.
You can check my ID from https://github.com/karmada-io/community/blob/main/MAINTAINERS.md.

1. The advisory text does not match its only evidence.
   The advisory says "arbitrary code execution via a crafted command". The only reference is a gist by the reporter (https://gist.github.com/HouqiyuA/2b56a893c06553013982836abb77ba50). The gist contains no code execution issue at all. It only points out that the karmada-agent ClusterRole in a member cluster has wildcard permissions (apiGroups/resources/verbs: *).

2. The wildcard permission is an intended design, not a flaw.
   Karmada is a multi-cluster orchestration system. karmada-agent is the control-plane's delegate inside a member cluster. Its job is to create, update, and delete any resource that users propagate to that cluster. It therefore needs cluster-admin-level permissions in that cluster, the same way a push-mode cluster is registered with an admin kubeconfig. This is documented explicitly: "karmada-agent acts as an administrator in member clusters" (https://karmada.io/docs/administrator/security/component-permission). Narrowing it would break the product's core function.

3. The attack chain crosses no trust boundary.
   The gist's scenario requires the attacker to already control a worker node (via a third-party component, hwameistor) and steal the agent's ServiceAccount token. An attacker who already controls a node and can read pod secrets is already inside the trust boundary; nothing in Karmada escalates that.

4. The report bypassed the project's security process.
   The reporter first opened a public issue (A potential risk in karmada that could lead to takeover of the cluster karmada-io/karmada#4846, April 2024, about a different component). We asked for the missing attack details and pointed them to our private security channel (cncf-karmada-security@lists.cncf.io). We never heard back. Instead, the CVE was requested from MITRE directly, without any confirmation from the project. The project was not contacted before or after the CVE was published.

5. Impact on users.
   The advisory lists <= 1.9.0 with no patched version, so govulncheck and Dependabot flag every Karmada version forever (see Address CVE-2024-33396 GO-2024-2817 karmada-io/karmada#7927). There is no fix to assign because there is nothing to fix; the correct correction is withdrawal.

Please withdraw GHSA-wccg-v638-j9q2. We are also asking MITRE to mark CVE-2024-33396 as DISPUTED. Happy to provide any further details.

[Copilot]

🟡 Changes recommended

The advisory remains active because no withdrawn timestamp is added.

1 open finding

• Add OSV withdrawn timestamp and set modified to withdrawal time · New

What changed in this PR

Attempts to withdraw the disputed Karmada advisory, but currently only adjusts its modification timestamp.

Changes:

• Increments the advisory’s modified timestamp by one second.

File	Description
GHSA-wccg-v638-j9q2.json	Updates the advisory timestamp.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.