When Pwn2Own introduced an AI products category at Berlin 2026, sceptics questioned whether it would produce meaningful results. Would researchers find exploitable bugs in AI tools, or would the category sit empty while teams focused on the more established Windows and VMware targets?
The answer came immediately. LM Studio fell on Day 2. OpenAI Codex fell on Day 3. Claude Code was successfully exploited. Five AI products were compromised across the three-day competition. The ZDI awarded prizes and the 90-day clocks started.
But the framing around this news has been wrong.
Headlines describing AI tools as “newly vulnerable” or asking whether AI security is “keeping up” miss the point entirely. AI coding tools, local inference platforms, and AI agent frameworks have been running in enterprise development environments for two years. Developers have been granting them access to code repositories, CI/CD pipelines, cloud credential files, and internal APIs for that entire period. The tools were not newly insecure when Pwn2Own pointed a camera at them. They were insecure before and the security industry simply was not looking.
What Pwn2Own Actually Measures
Pwn2Own does not discover whether products are vulnerable. It demonstrates that known-skilled researchers can find exploitable bugs within a time-limited competition window. If a team of three researchers can find a sandbox escape in LM Studio in the weeks before a competition, the same sandbox escape has been findable by a team of analysts at a well-resourced threat actor for the entire duration of LM Studio’s deployment.
The competition category does not create the vulnerability. It creates the structured incentive to look, and the public record that confirms what was found.
The AI tools that were exploited at Pwn2Own Berlin were not patched into security before the competition and then broken. They were deployed into enterprise developer environments months or years ago, where they had access to everything a developer does, and the security community had not applied the same systematic scrutiny it applies to, say, a VPN gateway or a web application framework.
The Deployment Outran the Assessment
The speed of AI tool adoption has been unusually fast even by the standards of an industry that adopts new categories quickly. In 2023, AI coding assistants were novelties used by early adopters. By late 2024, they were standard in most software development organisations. By 2026, AI agent frameworks are running autonomously in CI/CD pipelines, accessing repositories, deploying code, and managing cloud infrastructure.
At each stage of this adoption curve, the security assessment lagged behind the deployment. There was no systematic evaluation of LM Studio’s sandbox security before it was deployed across enterprise developer fleets. There was no structured threat modelling of what an AI coding assistant with repository access means for an organisation’s attack surface. The tools were evaluated on productivity — tokens per second, code quality, model capability — not on whether they could be exploited to pivot from a developer’s machine to production infrastructure.
This is not a novel failure mode. It is the exact same failure mode that characterised the early deployment of cloud infrastructure, mobile device management, and IoT. A new category of technology is deployed at scale, security assessment is treated as a follow-on activity, and by the time the industry starts looking systematically, the attack surface is already everywhere.
What Changes Now
The appearance of an AI category at Pwn2Own creates the structured incentive that was missing. When bugs are found, vendors get CVEs and patch pressure. When patches ship, enterprise teams have a concrete artifact to respond to. The pipeline that makes commercial software incrementally more secure over time — bug bounties, researcher scrutiny, CVE assignment, patch pressure — has now been extended to AI tools.
That is genuinely positive. But organisations that have been deploying AI coding assistants and agent frameworks for the last two years should not wait for that pipeline to produce results. The baseline assumption, now confirmed publicly, should be that these tools have exploitable vulnerabilities and run with significant access to sensitive systems.
Inventory what AI tools run in your development environment. Apply least-privilege to what they can access. Monitor their process behaviour. Patch them when updates are available. Apply the same security posture that you would apply to any privileged developer tool.
That is not overreaction to today’s news. It is the correct response to what has been true for two years and was confirmed at a competition in Berlin.
Share this article