- On day one of Pwn2Own Ireland 2026, researchers broke LiteLLM, OpenAI Codex and Oracle's Autonomous AI Database. Seven results used bugs already known, but only one involved an AI product.
- A known bug is not a fixed bug: the Zero Day Initiative noted one Samsung flaw was known to the vendor yet unpatched.
- Ask vendors how fast they patch reported bugs, and how your AI tools handle outside text before it reaches commands.
One way to think about a bug is that it is not only a hole. It is also a clock. That is our interpretation, not the contest organisers'. The clock starts when someone finds the flaw, and it keeps running until the vendor fixes it. On day one of Pwn2Own Ireland 2026, one Samsung result gave that idea a concrete case: a bug known to the vendor, yet unpatched.
Pwn2Own is a hacking contest run by the Zero Day Initiative (ZDI). Researchers attack fully working products on stage and win prizes if they take control. ZDI reported that 21 entries competed on day one. Targets ranged from a Samsung phone to a Sonos speaker, printers, a smart home hub and several AI products.
AI tools were on the target list, and some fell
ZDI listed several AI products among day one's results. Taisic Yun of Xint used an improper input validation bug plus code injection to get a reverse shell on LiteLLM. He earned $40,000. A reverse shell means the target machine connects back to the attacker and takes commands.
Two more AI targets paid the same amount. Ikotas Labs broke OpenAI Codex with one flaw of the argument injection type. Three VinSOC researchers strung five flaws together to get into Oracle's Autonomous AI Database.
Not every attempt worked. A VinSOC team could not get its exploit of Chroma working in the time allowed. Out of Bounds also broke LiteLLM with four bugs, but two were already known. The team took home $15,000.
This is one day of one contest. It does not show a trend. It does show that products sold as AI infrastructure were treated as ordinary targets, and some gave way.
How these attacks work, in plain terms
Argument injection is a flaw in how a program builds a command. When software runs another tool, it passes along text as options. If untrusted text is not checked, an attacker can slip in extra options the designers never meant to allow. ZDI's post says one such bug was enough for Codex. It gives no further detail.
Improper input validation is the wider family. The software accepts data it should have rejected. Code injection means that data is then run as instructions. Together, they gave Xint a shell on LiteLLM.
The pattern in both cases is plain. Software that turns outside text into actions needs strict checks on that text.
Collisions: the part buyers should read twice
ZDI marked seven day-one results as collisions. In these results, at least one bug the researchers used was already known, either to the vendor or to the public. The researchers still earned prizes.
The collisions were not spread across the AI products. Three were on the Samsung Galaxy S26, two on the Philips Hue Bridge Pro, one on the Sonos Era 300 and one on LiteLLM. ZDI reported no collisions for Codex, Oracle's database or Xint's LiteLLM entry.
The numbers vary. Viettel Cyber Security used four bugs on the Galaxy S26, and three were known to the vendor. Interrupt Labs also hit the S26 with four bugs: three collisions and one zero-day. Ikotas Labs hit the same phone with four bugs, one already known to the vendor yet unpatched.
The Philips Hue Bridge Pro shows the spread. VinSOC disclosed seven zero-days on it and won $40,000. Two other teams used five bugs each. For both, four were previously known.
What this shows
The lesson here is that a known flaw is not a fixed flaw. ZDI's post does not say how long vendors had known about these bugs. It does say one Samsung bug was known and unpatched.
What follows is our argument, not something the collisions showed. One Sonos bug was publicly known. A public bug can be read about by anyone, including attackers. A buyer should treat known and unpatched as a live exposure.
That changes what a buyer should ask. How many bugs a product has is hard to answer. How quickly a vendor fixes the ones it knows about is easier to ask, and it matters more.
Questions to put to your team
First, list the AI tools and gateways your teams have connected to company data. Check whether any are named in public contest results or advisories.
Second, ask each vendor how it handles reported bugs. How long from report to patch? Is there a public advisory?
Third, ask how your AI tools handle outside text. Where do they pass it to commands or code, and what checks happen first?
Fourth, ask who patches your smart office devices, such as speakers, hubs and printers. Several of those were broken on day one too.
The contest result worth remembering is not who won the most. A bug the vendor already knew can still open the door.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Zero Day Initiative.
