Lorin Lehawany on Insinuator.net - Bold Statements

CVE-2026-47237 – Overly Permissive Istio Permissions Allow Kubeflow Authorization Token Stealing

Wed, 20 May 2026 00:00:00 +0000

Kubeflow is vulnerable to the theft of authorization tokens by any user of the Kubeflow UI or APIs, such as the Dashboard, Pipelines API, or Notebooks. With this token, the attacker can take over the user’s account and the data that is processed by that user. The attacker needs a valid user with the kubeflow-edit or Contributor role in a random Kubeflow namespace to perform this attack. This is given if Automatic Profile Creation is enabled. A setup based on the official manifests prior to version 1.10, and on most other packaged Kubeflow distributions, is vulnerable.

The Istio edit permissions were removed by Kubeflow in a timely manner. Affected users should update to the latest version to mitigate this issue.

KubeCon + CloudNativeCon Europe 2026

Wed, 01 Apr 2026 00:00:00 +0000

Exactly one week ago, Sven and I had the incredible opportunity to give our very first talk at KubeCon + CloudNativeCon 2026: How To Break Multi-Tenancy Again and Again …and What We Can Learn From It. We discussed the challenges of namespace-based multi-tenancy and presented real-world exploits in Kubeflow, Istio, and Traefik that bypass threat boundaries between namespaces and workloads. Based on these problems, we developed a methodology to assess and address them. You can find the methodology discussed in the talk in detail in another blog post or on GitHub. You can also find the slides here.

Methodology for Assessing Kubernetes Namespace-Based Multi-Tenancy Setups

Thu, 26 Mar 2026 00:00:00 +0000

This page introduces our structured methodology for assessing security risks in Kubernetes environments that use Namespace-based Multi-Tenancy. It addresses weaknesses that break Namespace-based isolation that not well studied, yet. We found this issues during our research and presented them together with this methodology in our Talk at KubeCon + CloudNativeCon Europe 2026.

The methodology assumes that industry best practices, such as NetworkPolicies, Role-Based Access Control (RBAC), and Pod Security Standards, are already in place. These measures provide a necessary baseline level of protection against well-known isolation threats. However, they are insufficient to address a class of more subtle attack vectors arising from interactions between tenants and shared components. Such attack vectors may still compromise the confidentiality, integrity, and availability (CIA) of the cluster and its workloads, even in well-hardened environments.

Security Considerations on Istio’s CRDs with Namespace-based Multi-Tenancy

Wed, 25 Mar 2026 00:00:00 +0000

We reported a possible Man-in-the-Middle (MitM) attack scenario in which a VirtualService can redirect or intercept traffic within the service mesh. This affects Namespace-based Multi-Tenancy clusters where tenants have the permissions to deploy Istio resources (networking.istio.io/v1).

In collaboration with Istio, we published a guest submission in Istio’s blog (as well as below), a Security Bulletin, and an update to their Security Model to address this issue.

This blog post highlights the risks of using Istio in multi-tenant clusters and explains how users can mitigate these risks and safely operate Istio in their deployments.

Vulnerabilities in Broadcom VMware Aria Operations: Privilege Escalation (CVE-2025-41245 / CVE-2026-22721)

Wed, 18 Mar 2026 00:00:00 +0000

During a customer project, we identified privilege escalation vulnerabilities in Broadcom VMware Aria Operations. It is possible to escalate the privileges of an administrative vCenter user to an Aria administrator and take over systems integrated in Aria. Meaning, the vCenter user can gain privileged access to systems they have no access to. While both users might sound similarly privileged, this is not true in most environments – especially not in complex corporate environments: An insignificant vCenter user in a development environment can take over all other vCenters in a complex corporate environment.