In our presentation, we explored the security challenges of namespace-based multi-tenancy in Kubernetes. We demonstrated real-world attacks against Kubeflow, Istio, and Traefik that can break the intended isolation between namespaces and workloads. One of the highlights was demonstrating a privilege-escalation attack we discovered that allowed us to gain cluster-admin privileges.
As part of our Bluetooth Audio security research, we found a
security vulnerability in Apple’s Beats Studio Buds’ pairing mechanism.
The devices were found vulnerable to an insecure Bluetooth pairing
window in which an attacker could pair with the earbuds without user
interaction and establish a valid Bluetooth bonding. This would allow an
attacker to eavesdrop on the victim through the earbuds’ microphone, play
audio on the device, or track the device via Bluetooth Low Energy.
Imagine the following: You visit a webpage with a lot of text you don’t want to
read and ask your AI assistant for a summary. A few moments later, the AI
assistant has extracted one of your emails and sent it to an attacker without
you ever knowing.
In October 2025, we found exactly this vulnerability in Firefox’s AI chatbot
integration1.
Firefox offers a summarization, explaination and proofread AI feature. When a
user makes use of one of these features, Firefox pastes a prompt into the
sidebar AI chat including the page title, the selected text (or, if the whole
page is summarized, a selection is being made by Firefox) and an instruction on
how to process the provided text. The sidebar AI chat is essentially an IFrame
of a third-party chatbot (Claude, Copilot, …).
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.
During a penetration test for a customer, we identified a command injection
vulnerability in Geutebrück security cameras that allows authenticated attackers
to execute arbitrary commands as root through the web interface. The root cause
is unsanitized user input being passed into a sed script (and at least 12
other CGI endpoints). In addition to the injection, we identified an XSS
vulnerability, an exposed system menu leaking configuration and log data, and an
insecure GET-parameter-to-environment-variable mapping that enables abuse of
variables like LD_PRELOAD and LD_DEBUG. We reported the findings to
Geutebrück and a patched firmware was provided. This post walks through how we
got from a sed error message to a root shell.
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.
This blog post describes the journey of how we discovered an interesting
Bluetooth SoC within the Datong NP330, a
Printer Server IoT device.
Our initial goal was to reverse-engineer and analyze the Bluetooth controller
that is included in the device. So we wanted to be able to dump the firmware or,
if possible, get shell access on the printer server. During that journey we
found a few vulnerabilities that ultimately let an attacker fully compromise the
device. This is possible over Bluetooth or network via unauthenticated remote
code execution with root privileges.
AI agents are here, there, and everywhere. Smarter, faster, and more skilled,
they gain greater autonomy and trust. We trust their capabilities to do many
tasks much faster and sometimes better than we can. We trust them as they
usually demonstrate their eagerness to please us and fulfill our commands. Isn’t
that too good to be true, and we might be dealing with a double-edged sword
here? Can attackers use the same capabilities of the AI agents to attack their
own users? Can they exploit their eagerness to please their users to fulfill the
attackers’ intentions? And most importantly: what’s the worst that could happen
if you fully trust some random AI Agent?
During a customer project we identified an issue with the validation of JWT
tokens that allowed us to bypass the authentication by using unsigned tokens
with arbitrary payloads. During analysis we found out that this is caused by a
vulnerability within the library
OpenID Connect Authenticator for Tomcat.
OpenID Connect Authenticator for Tomcat
between versions 2.0.0 and 2.5.0, as well as the current state on branch
master contain a security flaw (introduced with commit 64e9a99) that allows
attackers to bypass JWT signature validation easily.
Today we are releasing a new white paper that delivers a technical analysis of
security weaknesses discovered in WinpMem, an open-source Windows memory
acquisition driver widely used in digital forensics.
After a concise primer on relevant Windows internals (virtual vs. physical
memory, page tables and PTEs, CR3 context switching, and kernel and user memory
separation), the report examines how both the fundamental design of WinpMem and
specific implementation choices create severe risk.