CVE-2026-32737 is an improper access control vulnerability (CWE-284) found in ctfer-io's romeo tool, which assists in measuring code coverage for Go applications (version 1.20 and above) within GitHub Actions workflows. Romeo versions prior to 0.2.1 include a mis-written Kubernetes NetworkPolicy named with the prefix 'inter-ns' that was intended to enforce namespace isolation by restricting network traffic between Pods in different namespaces. However, due to the misconfiguration, this NetworkPolicy inadvertently allows Pods in a supposedly hardened namespace to communicate with Pods outside that namespace. This breaks the security-by-default principle expected in Kubernetes deployments, enabling an attacker who has compromised a Pod in the hardened namespace to pivot laterally to other Pods across namespaces. The vulnerability does not require any privileges, authentication, or user interaction, and can be exploited remotely over the network. The scope of impact is high because it undermines Kubernetes namespace isolation, a fundamental security boundary. The vulnerability was addressed in romeo version 0.2.1 by removing the problematic inter-ns NetworkPolicy. For environments where immediate upgrade is not feasible, manual deletion of the inter-ns NetworkPolicy in the affected namespaces is advised to mitigate the risk. No known exploits are reported in the wild as of the publication date. The CVSS v4.0 base score is 7.9 (high), reflecting the network attack vector, no required privileges or user interaction, and the significant impact on security isolation within Kubernetes clusters.

This vulnerability enables an attacker who gains access to a Pod within a hardened namespace to bypass Kubernetes network segmentation controls and move laterally to Pods in other namespaces. Such lateral movement can lead to unauthorized access to sensitive workloads, data exfiltration, privilege escalation, and potential cluster-wide compromise. Organizations relying on romeo for code coverage in CI/CD pipelines may inadvertently expose their Kubernetes clusters to increased risk if they use vulnerable versions. The breach of namespace isolation undermines multi-tenant security models and can facilitate advanced persistent threats within cloud-native environments. The impact is particularly severe in environments with sensitive or regulated data, where lateral movement can lead to compliance violations and significant operational disruption. Although no active exploits are known, the ease of exploitation and network accessibility make this a critical risk to address promptly.

The primary mitigation is to upgrade romeo to version 0.2.1 or later, which removes the vulnerable inter-ns NetworkPolicy. If upgrading is not immediately possible, administrators should manually identify and delete any NetworkPolicy resources prefixed with 'inter-ns-' in the affected namespaces to restore proper network isolation. Additionally, organizations should audit their Kubernetes NetworkPolicies to ensure they enforce strict namespace isolation and verify that no unintended network access is permitted between namespaces. Implementing network segmentation monitoring and anomaly detection can help identify suspicious lateral movement attempts. Regularly reviewing CI/CD pipeline tools and their network configurations is recommended to prevent similar misconfigurations. Finally, applying the principle of least privilege to Pod permissions and restricting access to the Kubernetes API can reduce the risk of exploitation.