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.
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.
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).
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.
The behavior described in this post applies to Istio version 1.29.0 and to all versions since the introduction of the mesh gateway option in the VirtualService resource.
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.
The issue is exploitable in Aria’s default configuration. While the user is not an administrator, Aria maps the vCenter users to the PowerUser role, which is a privileged role in Aria and can be used to escalate its privileges to administrative users of other vCenters and connected VMware components.
In this blog post, we provide a brief background on VMware Aria Operations and vCenters, show what we found, and how we exploited this vulnerability in multiple ways to escalate privileges! Later, we talk about the disclosure process and Broadcom’s mitigation of the issue.
Hi there,
like in recent years the popular Hacking 101 workshop will take place on TROOPERS20, too! The workshop will give you an insight into the hacking techniques required for penetration testing. These techniques will cover various topics:
Hi there,
like in recent years the popular Hacking 101 workshop will take place on TROOPERS19, too! The workshop will give you an insight into the hacking techniques required for penetration testing. These techniques will cover various topics:
Hi there,
Like in recent years the popular Hacking 101 workshop will take place on TROOPERS17, too! The workshop will give attendees an insight into the hacking techniques required for penetration testing. These techniques will cover various topics:
Jenkins is a continuous integration server, widely used in Java environments for building automation and deployment. The project recently disclosed an unauthenticated remote code execution vulnerability discovered by Moritz Bechler. Depending on the development environment, a Jenkins server can be a critical part of the infrastructure: It often creates the application packages that later will be deployed on production application servers. If an attacker can execute arbitrary code, s/he can easily manipulate those packages and inject additional code. Another scenario would be that the attacker stealing credentials, like passwords, private keys that are used for authentication in the deployment process or similar.
The HITBSecConf or “Hack In The Box” in Amsterdam is a well known security conference in Europe. We also attended this year too, and there were quite some interesting talks at the HITBSecConf16 conference. One of the talks was about “New Methods for Exploiting ORM Injections in Java Applications” by the security researchers Mikhail Egorov and Sergey Soldatov.
