CVE-2026-115517 in Business Hub
Summary
by MITRE • 10/22/2026
Unrestricted network access between execution contexts in KNIME Business Hub before version 1.19.0 allows an authenticated remote user to access open network ports on executors in different execution contexts. This only poses a security issue if the IP address of the attacked executor is know and there are open network ports that provided access without further authentication. By default no network ports are open. However, depending on the running workflows, ports may be opened and provide an attack surface. As a workaround, network policies can be created manually.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in KNIME Business Hub prior to version 1.19.0 represents a critical flaw in network isolation between execution contexts, specifically categorized under CWE-284 Improper Access Control and aligned with the MITRE ATT&CK technique T1563 Remote Service Tool Installation or lateral movement via internal network access. This issue stems from an unrestricted network communication pathway that exists by default among executor nodes within the platform architecture. In a properly secured multi-tenant environment, execution contexts must be strictly isolated to prevent cross-context data leakage and unauthorized resource consumption. However, in this version of KNIME Business Hub, authenticated users can exploit these open internal channels to reach executors operating under different security boundaries or tenant identities.
The technical mechanism involves the exploitation of exposed network ports on executor nodes that are not adequately firewalled from one another within the cluster. While the platform does not expose services directly to the public internet by default, it facilitates inter-node communication for workflow distribution and result aggregation. The flaw lies in the lack of strict access control lists or micro-segmentation policies between these internal execution contexts. Consequently, an attacker who has obtained valid credentials for one user context can perform network reconnaissance against other executor nodes within the same cluster. If those target executors have specific ports open due to running workflows that require external connectivity or inter-node communication, the attacker may establish a direct connection without further authentication checks from the application layer.
The operational impact of this vulnerability is contingent upon several factors, primarily the knowledge of the internal IP addresses of the targeted executor nodes and the presence of vulnerable services listening on those ports. By default, KNIME Business Hub does not open any network ports that would facilitate such an attack vector, meaning many installations may remain unaffected if they adhere to strict baseline configurations. However, as workflows are deployed dynamically, certain processes may require opening specific ports for data ingestion, API calls, or inter-process communication. These dynamic port openings create a significant attack surface. An authenticated user could potentially use these open channels to exfiltrate sensitive data processed by other tenants, inject malicious code into the execution environment of another context, or pivot further into the internal network infrastructure if those executors are connected to broader corporate networks.
Mitigation strategies must focus on enforcing strict network segmentation and access controls at both the application and infrastructure levels. The primary recommendation is to upgrade immediately to KNIME Business Hub version 1.19.0 or later, where this unrestricted access pattern has been addressed through improved isolation mechanisms. For organizations unable to patch immediately due to operational constraints, a manual workaround involves implementing network policies that restrict inter-executor communication. This can be achieved by configuring firewall rules or container network policies to deny traffic between executor pods unless explicitly required for specific workflow functions. Additionally, administrators should audit running workflows to identify any that open unnecessary ports and disable them if not strictly needed. Implementing zero-trust principles within the cluster environment, where every request is verified regardless of its origin within the internal network, will further reduce the risk associated with this vulnerability. Regular security assessments and penetration testing focused on lateral movement techniques are also advised to ensure that no residual attack vectors remain in the execution environment.