Pwn2Own Berlin’s first day put AI developer tooling and local inference stacks under the same pressure long applied to browsers and operating systems. That is the useful signal: security operations teams now have fresh evidence about where exploitability is being demonstrated, even before vendor advisories and patches land.
Source: Zero Day Initiative Blog — https://www.thezdi.com/blog/2026/5/13/pwn2own-berlin-2026-day-one-results
What changed#
Zero Day Initiative reported 22 entries on Day One of Pwn2Own Berlin 2026, targeting AI Databases, Coding Agents, Local Inferences, NVIDIA products, browsers, and operating systems. ZDI said it awarded $523,000 for 24 unique zero-days after the first day.
The strongest single result came from Orange Tsai of DEVCORE Research Team, who chained four logic bugs to achieve a sandbox escape in Microsoft Edge. That earned $175,000 and 17.5 Master of Pwn points. DEVCORE ended the day in the lead for Master of Pwn, according to ZDI.
The AI and developer-tooling side was busy. Compass Security exploited OpenAI Codex with a single CWE-150 bug. A separate OpenAI Codex entry by Doyensec was successful on stage, but ZDI said the bug was already known to the vendor. Anthropic Claude Code was also successfully targeted by Viettel Cyber Security, again with a bug ZDI described as previously known to the vendor.
Local inference and AI infrastructure products also took hits. LiteLLM was exploited through a chain including SSRF and Code Injection. LM Studio was exploited through a five-bug chain that also included SSRF and Code Injection. Chroma was exploited through a two-bug chain involving CWE-190 and CWE-362.
NVIDIA-related targets appeared in several entries. IBM X-Force Offensive Research exploited NV Container Toolkit with a single bug. NVIDIA Megatron Bridge was exploited through an overly permissive allow list issue, a CWE-470 issue, and later a path traversal bug in separate attempts.
Traditional platform targets did not disappear. Microsoft Windows 11 saw multiple privilege escalation demonstrations, including improper access control, a heap-based buffer overflow, and chained use-after-free bugs. Red Hat Enterprise Linux for Workstations was exploited through a race condition. Some entries failed within the time allowed, and several were withdrawn.
Why this security advisory signal matters#
Pwn2Own is not a normal security advisory feed. It does not give defenders CVE numbers, patch links, or exploit details on the day of the contest. The value is different: it shows which classes of products can be broken by skilled researchers under contest conditions, and which attack surfaces are mature enough to reward serious exploit work.
This year’s Day One result makes that signal harder to ignore for teams using AI development assistants, local inference tools, AI databases, or NVIDIA-adjacent infrastructure. These systems are no longer side experiments in many environments. They touch source code, secrets, model files, internal APIs, plugin ecosystems, and developer workstations.
That changes the operational risk. A coding agent with broad repository access is not just another SaaS tab. A local inference stack running with loose network exposure is not just a productivity tool. A container toolkit or AI framework component can sit close to build systems, GPU workloads, and privileged host boundaries.
The exploit chains also matter. SSRF and Code Injection in AI-adjacent products are not exotic failure modes. They are familiar web and application security problems showing up in newer orchestration layers. Path traversal, access control failures, race conditions, and unsafe type or reflection behavior are not new either. The novelty is the context: these bugs are appearing in systems that organizations may have adopted faster than they hardened.
For open source security, the lesson is not that open source is uniquely weak. It is that source availability does not replace operational checks. Teams still need asset inventory, patching discipline, exposure review, dependency tracking, and a clear trust model for tools that execute code or touch developer data.
For more on turning security artifacts into operational work, see GigaTap’s earlier note: OpenSSF’s April signal: make security artifacts operational.
What to check before acting#
Treat the ZDI post as an early warning, not a complete remediation guide. The immediate job is to map exposure.
Start with inventory. Check whether your environment uses any products named in the Day One results: Microsoft Edge, Microsoft Windows 11, Red Hat Enterprise Linux for Workstations, OpenAI Codex, Anthropic Claude Code, LiteLLM, LM Studio, Chroma, NV Container Toolkit, NVIDIA Megatron Bridge, and Oracle Autonomous AI Database. The ZDI list also includes attempts that failed or were withdrawn, so do not convert every target mention into a confirmed vulnerability.
Then separate usage from exposure. A developer running a tool locally on an isolated test machine is a different risk from a shared service reachable from internal networks. A coding agent with read-only access is different from one that can write code, run commands, or access credentials. A GPU container stack on a workstation is different from one in production CI or shared research infrastructure.
For security operations, useful checks include:
- Identify whether affected products are deployed, tested, or allowed by policy.
- Check whether they run with elevated privileges or broad filesystem access.
- Review network exposure for local inference services and AI databases.
- Look for SSRF-relevant paths: URL fetchers, connectors, plugins, model importers, and proxy features.
- Review secrets exposure from coding agents, build scripts, local config files, and environment variables.
- Track vendor advisories after Pwn2Own disclosures move through coordinated disclosure.
- Prepare patch windows for products with confirmed vendor fixes, but avoid emergency changes based only on contest target names.
For developer teams, the most practical question is simple: what can this tool read, write, execute, and send over the network? If that answer is vague, the risk model is vague too.
This is especially important for local AI tooling. Many teams treat local inference as safer because data does not leave for a cloud model provider. That can be true for privacy risk in one direction. It does not automatically reduce exploitability, host compromise risk, or lateral movement risk if the local service is exposed or overprivileged.
What not to overclaim#
The ZDI post does not mean all named products are currently exploitable in the wild. It does not provide public exploit code. It does not prove that every issue is unpatched. Some successful demonstrations used bugs already known to the vendor. Some entries failed within the time allotted. Some were withdrawn.
It also does not give enough information to assign severity inside a specific organization. A sandbox escape in a browser, a privilege escalation in an operating system, and code injection in an AI orchestration tool have different consequences depending on deployment, user behavior, privilege boundaries, and compensating controls.
The right posture is neither panic nor dismissal. Pwn2Own compresses months of security research into a public scoreboard. That scoreboard is not a patch plan, but it is a strong prioritization hint. When a product category repeatedly appears on that stage, defenders should assume capable researchers are looking there because the attack surface is worth the time.
Practical takeaway#
Security teams should use Day One as a trigger for operational checks around AI tooling, developer agents, local inference services, and NVIDIA-linked infrastructure. Confirm what is deployed. Reduce unnecessary privileges. Limit network exposure. Watch vendor channels for CVE assignments and patches. Document which tools can access code, credentials, models, and internal services.
The broader lesson is sharper: AI infrastructure is now ordinary infrastructure. It needs the same patching, exposure management, and security operations discipline as browsers, operating systems, and container platforms. The contest results do not close the case. They show where to start looking.