EUVD-2025-209603Severity by source
AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Lifecycle Timeline
5DescriptionCVE.org
IBM watsonx.data 2.2 through 2.3 IBM Lakehouse does not properly restrict communication between pods which could allow an attacker to transfer data between pods without restrictions.
AnalysisAI
IBM watsonx.data versions 2.2 through 2.3 fail to enforce proper network segmentation between Kubernetes pods in the Lakehouse component, allowing attackers with network access to the cluster to transfer data between pods without authentication or authorization controls. This integrity vulnerability has a moderate CVSS score of 5.3 and requires adjacent network access and specific configuration conditions to exploit.
Technical ContextAI
IBM watsonx.data is a data lakehouse platform that runs on Kubernetes clusters. The vulnerability stems from improper implementation of Kubernetes network policies (CWE-923: Improper Restriction of Communication Channel to Intended Endpoints). In containerized Kubernetes environments, inter-pod communication is controlled through NetworkPolicy objects and service-to-service authentication mechanisms. The absence of proper network segmentation allows pods to communicate directly without enforcing least-privilege access controls, enabling lateral movement and unauthorized data exfiltration within the cluster boundary. This affects the Lakehouse subcomponent, which typically handles data storage and retrieval operations across multiple pod instances.
RemediationAI
IBM has released a patch available from vendor at https://www.ibm.com/support/pages/node/7270593. Administrators should apply the vendor-provided patch to upgrade watsonx.data to a version beyond 2.3. As an interim compensating control, implement strict Kubernetes NetworkPolicy objects to enforce egress/ingress rules between pods in the watsonx.data namespace-deny-all by default with explicit allow rules for required pod-to-pod communication only. Additionally, deploy a Kubernetes service mesh (Istio or Linkerd) to enforce mutual TLS (mTLS) authentication and authorization policies between all pod communications, which prevents unauthorized data transfer even if pods can communicate at the network layer. Enable network traffic monitoring and alerting on inter-pod communications within the watsonx.data namespace to detect lateral movement attempts. Note that these compensating controls add operational complexity and may impact performance; the vendor patch is the recommended primary remediation.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today