OpenAI’s bug hunt rattled Chrome, Safari, Firefox

OpenAI researchers found exploitable bugs in Chrome, Safari, and Firefox within a week.

OpenAI’s security team reported five exploitable bugs in Chrome’s V8 engine, more than ten in Safari’s WebKit, and a WebAssembly flaw in Firefox during roughly a week of work. Mozilla patched the Firefox issue two days before Pwn2Own Berlin, and five of six registered Firefox entries withdrew after that fix landed.

What the week-long bug hunt says about browser security

The headline number is hard to ignore: a small research effort turned up serious issues across all three major browser engines. That matters because browser engines are some of the most audited codebases in software, yet they still keep producing memory-safety bugs, sandbox escapes, and parser edge cases that attackers can turn into real-world exploits.

Chrome, Safari, and Firefox all ship massive amounts of code that process untrusted input every second of the day. A single weakness in V8, WebKit, or Firefox’s WebAssembly stack can become a path from a malicious webpage to code execution, data theft, or a full browser compromise.

That is why this kind of research gets attention outside the security community. It shows that even mature browser engines still have room for highly productive offensive testing, especially when researchers focus on the parts of the engine that handle complex binary formats and JIT compilation.

• Chrome V8: 5 exploitable bugs reported
• Safari WebKit: more than 10 bugs reported
• Firefox: 1 WebAssembly flaw patched before the contest
• Pwn2Own Berlin: 5 of 6 Firefox entries withdrew after the fix

Why Firefox’s patch changed the contest

The Firefox finding had a direct effect on Mozilla’s competition planning. According to the source summary, Mozilla patched the WebAssembly flaw two days before Pwn2Own Berlin, and that timing forced most Firefox contestants to back out. In contest terms, that is a big deal: if the target changes before the event, the attack surface changes too, and the prize hunt loses momentum.

That detail also says something about disclosure speed. Security teams that can confirm and patch a flaw quickly reduce the chance that a public demo becomes a practical exploit path. The flip side is that a rapid patch can also reshape the incentives around live hacking contests, where researchers often prepare for weeks against a specific version.

“Security is about reducing risk, not eliminating it.” — Mozilla Manifesto

That line fits this story well. The Firefox patch did not prove the browser is safe in some absolute sense. It showed that a known weakness was removed before attackers could use a public stage to demonstrate it.

Chrome and Safari still gave researchers plenty to find

The bigger technical signal may be the volume of issues in Chrome and Safari. Five exploitable bugs in V8 and more than ten in WebKit during about a week suggests that modern browser engines still have dense bug surfaces, especially in code paths tied to just-in-time compilation, object modeling, and complex input parsing.

Researchers often concentrate on areas where a small logic mistake can become a memory corruption bug. Browser engines are full of those areas because they must balance speed, compatibility, and isolation. The result is software that is heavily tested and still surprisingly fertile for skilled security teams.

• V8 is the JavaScript engine used by Chrome and other Chromium-based browsers
• WebKit powers Safari and other Apple browser components
• WebAssembly adds another high-risk execution path because it is designed for near-native speed
• Contest-driven disclosure can force vendors to patch before a public exploit chain is demonstrated

For developers, the lesson is simple: browser security is still a moving target. Even when vendors ship frequent patches, the next serious issue can already be sitting in the engine’s optimizer, garbage collector, or binary decoder. That is why browser teams keep investing in fuzzing, memory-safety work, and exploit mitigations, even when the public conversation has moved on to AI tools and app frameworks.

What developers should take from this report

If you build software that runs in the browser, this story is a reminder to treat browser updates as urgent, not optional. Chrome, Safari, and Firefox patch different classes of engine bugs on different schedules, and a flaw in any one of them can affect a large share of users within hours.

It is also a reminder that security research still pays off. A week of focused work surfaced enough findings to pressure three browser ecosystems at once. That is a strong argument for more fuzzing, more code auditing, and more attention on engine components that process untrusted content.

For teams that ship web apps, the practical move is to keep browsers current, test across engines, and assume that a bug in a rendering or script engine can become your problem even if your own code is clean. For browser vendors, the question is whether the next round of hardening can shrink these bug counts faster than researchers can find them.

My bet is that the next Pwn2Own-style event will keep focusing on engine internals, because that is where the payoff still is. The real question is which vendor closes the gap fastest when the next batch of bugs lands.