Chall-Manager is a platform-agnostic system able to start Challenges on Demand of a player. In versions prior to 0.6.5, due to a miswritten NetworkPolicy, a malicious actor can pivot from an instance to any Pod out of the origin namespace. This breaks the security-by-default property expected as part of the deployment program, leading to a potential lateral movement. In the specific case of sdk/kubernetes.Kompose it does not isolate the instances. This issue has been fixed in version 0.6.5.

Affected: Go: github.com/ctfer-io/chall-manager/deploy, Go: github.com/ctfer-io/chall-manager/sdk

### Impact

Due to a mis-written NetworkPolicy, a malicious actor can pivot from an instance to any Pod out of the origin namespace. This breaks the security-by-default property expected as part of the deployment program, leading to a potential lateral movement. In the specific case of `sdk/kubernetes.Kompose` it does not isolate the instances.

### Patch

Removing the `inter-ns` NetworkPolicy patches the vulnerability. If updates are not possible in production environments, we recommend to manually delete it and update as soon as possible.

### Workaround

Given your context, delete the failing network policy that should be prefixed by `inter-ns-` in the target namespace. You can use the following to delete all matching network policy. If unsure of the outcome, please do it manually.

```bash for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}' | tr ' ' '\n' | grep '^cm-target-'); do kubectl -n "$ns" get networkpolicy -o name \ | grep '^networkpolicy.networking.k8s.io/inter-ns-' \ | xargs -r kubectl -n "$ns" delete done ```