Chrome 0-Day Flaw Exploited in the Wild to Execute Arbitrary Code
Google has issued an urgent security update for its Chrome browser, addressing a critical zero-day vulnerability that is being actively exploited by attackers. The flaw, tracked as CVE-2025-6554, is a type confusion vulnerability in Chrome’s V8 JavaScript engine, which underpins the browser’s ability to process web content across Windows, macOS, and Linux platforms. The vulnerability was discovered by Clément Lecigne of Google’s Threat Analysis Group (TAG) on June 25, 2025. According to Google, attackers have already developed and deployed exploits targeting this flaw in the wild, prompting the company to act quickly.
How I used o3 to find CVE-2025-37899, a remote zeroday vulnerability in the Linux kernel’s SMB implementation
In this post I’ll show you how I found a zeroday vulnerability in the Linux kernel using OpenAI’s o3 model. I found the vulnerability with nothing more complicated than the o3 API – no scaffolding, no agentic frameworks, no tool use. Recently I’ve been auditing ksmbd for vulnerabilities. ksmbd is “a linux kernel server which implements SMB3 protocol in kernel space for sharing files over network.“. I started this project specifically to take a break from LLM-related tool development but after the release of o3 I couldn’t resist using the bugs I had found in ksmbd as a quick benchmark of o3’s capabilities. In a future post I’ll discuss o3’s performance across all of those bugs, but here we’ll focus on how o3 found a zeroday vulnerability during my benchmarking. The vulnerability it found is CVE-2025-37899 (fix here), a use-after-free in the handler for the SMB ‘logoff’ command. Understanding the vulnerability requires reasoning about concurrent connections to the server, and how they may share various objects in specific circumstances. o3 was able to comprehend this and spot a location where a particular object that is not referenced counted is freed while still being accessible by another thread. As far as I’m aware, this is the first public discussion of a vulnerability of that nature being found by a LLM. Before I get into the technical details, the main takeaway from this post is this: with o3 LLMs have made a leap forward in their ability to reason about code, and if you work in vulnerability research you should start paying close attention. If you’re an expert-level vulnerability researcher or exploit developer the machines aren’t about to replace you. In fact, it is quite the opposite: they are now at a stage where they can make you significantly more efficient and effective. If you have a problem that can be represented in fewer than 10k lines of code there is a reasonable chance o3 can either solve it, or help you solve it. Benchmarking o3 using CVE-2025-37778 Lets first discuss CVE-2025-37778, a vulnerability that I found manually and which I was using as a benchmark for o3’s capabilities when it found the zeroday, CVE-2025-37899. CVE-2025-37778 is a use-after-free vulnerability. The issue occurs during the Kerberos authentication path when handling a “session setup” request from a remote client. To save us referring to CVE numbers, I will refer to this vulnerability as the “kerberos authentication vulnerability“.
For the third time in as many months, Apple has released an emergency patch to fix an already exploited zero-day vulnerability impacting a wide range of its products. The new vulnerability, identified as CVE-2025-24201, exists in Apple's WebKit open source browser engine for rendering Web pages in Safari and other apps across macOS, iOS, and iPadOS. WebKit is a frequent target for attackers because of how deeply integrated it is with Apple's ecosystem.
