The inaugural AI products category at Pwn2Own Berlin 2026 yielded immediate results: both LM Studio and OpenAI Codex were successfully exploited on the third day of competition, with demonstrations of code injection and environment variable abuse that allowed attackers to break out of their intended sandboxes. The results confirm what security researchers have argued for over a year — AI coding and inference tools are running in enterprise environments with significant access to sensitive systems, but are not being evaluated or secured to the same standard as other internet-facing developer tooling.
LM Studio: Code Injection via Crafted Model Metadata
OtterSec’s exploitation of LM Studio targeted the application’s handling of model metadata — structured data embedded in model files that LM Studio parses to configure the model before inference. By crafting metadata fields with injected content, the team achieved code execution within the LM Studio process, which on a developer machine typically runs with the user’s full privileges and has access to the local file system, credential stores, and any development environment the user has open.
LM Studio is widely used by developers to run large language models locally without sending data to cloud APIs. It is increasingly deployed in enterprise air-gapped environments where local inference is required for compliance reasons, meaning the attack surface is often inside a network perimeter rather than on an internet-facing machine.
OpenAI Codex: External Control via Environment Variable Injection
The OpenAI Codex exploitation demonstrated by the STARLabs SG team used environment variable injection to achieve external control of the Codex execution environment. Codex is an AI coding assistant that runs within development environments and has integration with code editors, CI/CD pipelines, and build tools. By injecting malicious values into the environment that Codex reads at runtime, the researchers were able to direct the tool to execute attacker-controlled commands.
This is a particularly significant result for the enterprise development pipeline. An AI coding assistant that can be directed to execute arbitrary commands has full access to whatever the developer’s build environment has access to — source code repositories, authentication tokens, deployment keys, and any external services the CI/CD pipeline connects to.
A New Attack Surface in Every Developer Environment
The appearance of AI coding tools at Pwn2Own reflects a market shift that has outpaced the security industry’s assessment of these tools. In 2024, enterprise deployment of AI coding assistants was limited; by 2026, AI coding tools are standard in most software development organisations. They run with elevated privileges, access code and secrets, and are trusted implicitly because they are perceived as productivity tools rather than attack surfaces.
The security model for these tools is inconsistent. Some run fully locally with no network access; others route user prompts and code context to external APIs; others are integrated into cloud-hosted development environments with access to cloud credentials and deployment infrastructure. In none of these cases has the security community conducted the level of systematic evaluation applied to, say, a web application framework or a network appliance.
Immediate Actions for Organisations Using AI Development Tools
Organisations deploying AI coding assistants should apply the same security posture as any other developer tool with privileged access:
Inventory AI tools in use: Catalogue all AI coding, inference, and assistant tools deployed in the development environment. Include both approved enterprise tools and developer-installed local tools.
Apply the principle of least privilege: AI tools should run with the minimum permissions required for their function. Local inference tools that do not need network access should be firewalled from outbound connections. Tools that access code repositories should use short-lived tokens rather than persistent credentials.
Patch and update aggressively: AI tools are updated frequently, often with security fixes that are not prominently disclosed in changelogs. Apply updates within 24 hours when available — the Pwn2Own results demonstrate that exploitable vulnerabilities exist in current production versions.
Monitor for anomalous process behaviour: AI tools running in development environments should not be spawning unexpected child processes, making network connections to addresses outside their documented API endpoints, or accessing credential store locations. Configure endpoint monitoring to alert on these patterns.
The Pwn2Own AI category will grow. The next generation of these tools integrates more deeply with enterprise systems and has greater autonomous capability. The security models need to catch up before that capability is deployed at scale.
Share this article