YAML Injection in Migration Script

The newly added POST_RENDERERS block is vulnerable to YAML injection. The script extracts MAC and IP addresses from ip.kubeovn.io resources and interpolates them directly into a string that defines a Flux postRenderers kustomize patch.

Specifically, on lines 494 and 495, ${OVN_MAC} and ${OVN_IP} are used inside double quotes within the patch string. If these values contain a double quote followed by a newline and arbitrary YAML, an attacker can break out of the intended field and inject additional fields or even entire patches into the HelmRelease specification.

Since the migration script is executed with cluster-admin privileges during a platform migration, and MAC addresses can be influenced by users via their VirtualMachine specifications, this allows a tenant to escalate privileges. For example, an attacker could inject a patch that makes their VirtualMachine privileged or mounts host paths, bypassing security isolation.

Remediation:
Avoid using string interpolation to build YAML patches. Instead, use a tool like jq or yq to safely construct the YAML structure, or ensure that the variables are properly escaped for YAML (e.g., using jq -Rs . to escape the strings).

The current logic only creates the postRenderers patch if $OVN_MAC is set. This means if a VM has a static IP ($OVN_IP) but no static MAC, the IP address will not be preserved during the migration. To ensure that the IP address is also preserved in such cases, the condition should be updated to trigger the patch creation if either $OVN_MAC or $OVN_IP is present.

    if [ -n "$OVN_MAC" ] || [ -n "$OVN_IP" ]; then

⚠️ Potential issue | 🟠 Major

#!/bin/bash
set -euo pipefail

echo "Kube-OVN IP CRD fields:"
sed -n '2507,2585p' packages/system/kubeovn/charts/kube-ovn/templates/kube-ovn-crd.yaml \
  | rg -n 'ipAddress|v4IpAddress|v6IpAddress|macAddress'

echo
echo "Current template usage:"
sed -n '35,42p' packages/apps/vm-instance/templates/vm.yaml

Use the canonical Kube-OVN IP field instead of the deprecated ipAddress.

The vendored Kube-OVN CRD marks spec.ipAddress as deprecated and recommends using spec.v4IpAddress or spec.v6IpAddress. Rendering ovn.kubernetes.io/ip_address from the deprecated field risks silently dropping the IP address when ipAddress is empty, even though a valid v4IpAddress exists. This can break IP preservation during VM live migration.

         {{- $ovnIPName := printf "%s.%s" (include "virtual-machine.fullname" .) .Release.Namespace }}
         {{- $ovnIP := lookup "kubeovn.io/v1" "IP" "" $ovnIPName }}
         {{- if $ovnIP }}
         ovn.kubernetes.io/mac_address: {{ $ovnIP.spec.macAddress | quote }}
-        ovn.kubernetes.io/ip_address: {{ $ovnIP.spec.ipAddress | quote }}
+        {{- $ovnIPAddress := coalesce $ovnIP.spec.v4IpAddress $ovnIP.spec.ipAddress }}
+        ovn.kubernetes.io/ip_address: {{ $ovnIPAddress | quote }}
         {{- end }}

Verify each finding against the current code and only fix it if needed.

In `@packages/apps/vm-instance/templates/vm.yaml` around lines 37 - 41, The
template is reading the deprecated Kube-OVN field spec.ipAddress; change the IP
selection logic for the ovn.kubernetes.io/ip_address annotation to prefer
spec.v4IpAddress, then spec.v6IpAddress, and only fall back to spec.ipAddress if
neither v4 nor v6 is present. Locate the variables $ovnIPName and $ovnIP in the
vm.yaml template and update the annotation rendering to choose the first
non-empty of spec.v4IpAddress / spec.v6IpAddress / spec.ipAddress so
live-migration preserves IPs when v4/v6 fields are set.