---
id: "CVE-2026-115517"
kind: "vulnerability"
aliases: ["CVE-2026-115517"]
title: "KNIME Business Hub: unrestricted network access between execution contexts"
severity: "medium"
cvss: 6.4
epss: 0.00431
exploited: false
status: "open"
category: "other"
products: []
ecosystems: []
tags: ["knime", "kubernetes", "other", "self-hosted"]
not_affected_if: ["no-open-executor-ports", "version-1.19.0-or-later"]
published_at: "2026-10-22T19:17:48+00:00"
first_seen_at: "2026-10-23T21:57:31+00:00"
updated_at: "2026-10-25T03:59:15+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-115517", "first_seen_at": "2026-10-23T21:57:31+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-115517", "first_seen_at": "2026-10-24T07:15:51+00:00"}]
---

# KNIME Business Hub: unrestricted network access between execution contexts

KNIME Business Hub before 1.19.0 does not isolate network access between execution contexts. An authenticated user can reach open ports on executors in other contexts, which matters only if the target IP is known and a workflow has opened a port without authentication.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the KNIME Business Hub version in the installation; affected versions are those before `1.19.0`.
- Review whether network policies restrict traffic between execution contexts (unknown whether the sources list a specific command or setting).

## Fix

- Upgrade KNIME Business Hub to `1.19.0` or later.
- Until upgraded, create network policies manually to block traffic between execution contexts, as the advisory suggests.

## Timeline

- 2026-10-23T21:57:31+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-115517
- 2026-10-24T07:15:51+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-115517

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_