Codex Identifies 40% of Safari’s Vulnerabilities

Codex Security Finds 9 WebKit Vulnerabilities in One Go

Apple’s latest Safari 26.6.1 security update fixes 22 CVE vulnerabilities involving WebKit. Nine of them are credited to OpenAI Codex Security, accounting for approximately 41% of the WebKit fixes in this release.

This is not the first time AI has been used to discover vulnerabilities, but having nine findings listed in a single official Apple security advisory is still noteworthy. In the past, when security teams discussed AI, they were more often referring to code completion, alert classification, and vulnerability explanation. This time, an AI security agent has directly entered the vulnerability discovery pipeline for a browser engine, contributing nearly half of the findings.

According to information disclosed on August 18, these WebKit vulnerabilities could lead to various consequences, including allowing attackers to cause Safari to quit unexpectedly by serving maliciously crafted web content, crashing or terminating related processes, and triggering memory corruption. The advisory also separately lists two issues explicitly capable of causing memory corruption. Another vulnerability in WebKit History could leak sensitive data when a user visits a malicious website.

In other words, these are not issues that affect only peripheral features or require complex local conditions to trigger. WebKit sits between web content and operating system capabilities. It is Safari’s core component for processing HTML, CSS, JavaScript, browsing history, and other data. Simply opening a crafted webpage could send the browser down an abnormal execution path predetermined by an attacker.

What Does the 41% Figure Mean?

First, the scope needs to be clarified: 41% refers to Codex Security’s share of the discovery credits among the 22 WebKit CVEs fixed in Safari 26.6.1. It does not mean that AI discovered 41% of all vulnerabilities addressed in Apple’s security updates, nor does it mean that AI independently completed every step from discovery and reproduction to remediation.

Before a vulnerability appears in a vendor advisory, it typically has to pass through multiple stages: detecting anomalous behavior, creating a minimal proof of concept, assessing the security impact, ruling out duplicate reports, confirming affected versions, assigning a CVE, developing a patch, and conducting regression testing. Codex Security receiving discovery credit indicates, at minimum, that its submissions passed the vendor’s validation threshold. However, the public logs alone do not reveal how much human involvement there was for each vulnerability, how much code it scanned, how long it ran, or how many invalid candidates it generated.

Even so, nine remains a significant result.

WebKit is not a simple codebase suited to demonstrations. Browser engines are enormous, incorporating complex modules such as parsers, JavaScript execution environments, layout systems, media processing, network interactions, and multiprocess isolation. Many security flaws do not manifest as an obviously “incorrect” line of code. Instead, they emerge only through a combination of multiple states, object lifecycles, and boundary conditions.

Traditional static analysis tools are more like airport metal detectors: they excel at identifying suspicious patterns according to predefined rules, but often only raise alarms without explaining whether the issue can actually occur in a real system. The truly time-consuming work for security researchers is tracing call chains and object states, determining whether an alert can be triggered by external input, and establishing whether the result is a crash, an out-of-bounds read or write, or information disclosure.

Agents such as Codex Security aim to take over precisely this labor-intensive middle stage of reasoning. Rather than merely searching files for dangerous functions, they use code context, component boundaries, and threat models to formulate hypotheses, then look for execution paths that support or refute them. Ideally, they must also generate reproduction conditions and validate the issue, avoiding the handoff of large numbers of seemingly dangerous but actually unreachable code paths to security teams.

Memory Corruption Remains One of the Toughest Browser Security Problems

Memory corruption is particularly noteworthy among the issues fixed in this release.

In large systems built with languages such as C and C++, use-after-free errors, out-of-bounds access, invalid type conversions, and confused object lifecycles can all compromise memory safety. At the low end, these flaws may crash a tab or the browser. In more serious cases, attackers may be able to read data they should not have access to, or even attempt to control the program’s execution flow.

Although browsers commonly deploy mitigations such as sandboxes, address space layout randomization, and control-flow protection, these mechanisms do not eliminate vulnerabilities. High-value attacks in the real world often chain multiple vulnerabilities together: an attacker might first exploit a memory flaw in WebKit to gain code execution within the web content process, then combine it with a sandbox escape or operating system component vulnerability to elevate privileges.

For this reason, “a crash after opening a malicious webpage” should not be treated as merely a stability issue. Vendor advisories typically describe security impacts in restrained language. The actual risk depends on whether the vulnerability can be exploited reliably, whether existing mitigations can be bypassed, and whether the attacker has other vulnerabilities available to build an exploit chain.

The sensitive-data disclosure issue in WebKit History represents a different risk path. Browsing history, page state, and referrer relationships may themselves constitute privacy signals. Attackers do not necessarily need to take control of a device. Simply determining which pages a user has visited or which stage of a business process they are in could facilitate account profiling, targeted phishing, or cross-site tracking. In enterprise environments, access records could also indirectly expose administrative console addresses, project names, or business relationships.

AI Security Agents Are Finally Tackling the Hard Problems

The biggest problem with AI code security products in the past was not that they could not find issues, but that they were too good at finding them.

If a tool produces thousands of alerts after a scan, most of which are not exploitable, the security team incurs additional costs to review them one by one. Once the false-positive rate becomes too high, AI merely transforms the problem from “not enough people writing rules” into “not enough people handling alerts.” This is also why many companies ultimately run purchased security scanning tools only during compliance reviews.

Codex Security’s product positioning clearly targets this pain point: understanding project context and threat models, validating candidate vulnerabilities, and proposing fixes. For engineering teams, genuinely useful output should not merely say, “There may be a problem here.” At a minimum, it should answer four questions:

• Where does the external input enter?
• Through which calls and state transitions does it reach the dangerous location?
• Under which versions, configurations, and runtime conditions can it be reproduced?
• After remediation, how can it be proven that the vulnerability has been blocked without introducing regressions?

The nine credits in this Safari release indicate that AI agents have at least had the opportunity to complete the first half of this work in a real, complex, and high-value codebase. However, it is still too early to declare that AI can replace browser security researchers.

Public information does not disclose Codex Security’s precision, recall, compute consumption, or number of duplicate reports, nor does it reveal the severity distribution of the nine vulnerabilities. If a system consumes substantial computing resources scanning for months and ultimately finds nine low- or medium-severity issues, it still has technical value, but its commercial return must be reassessed. By contrast, if it can run reliably on every commit or before each release freeze, identifying issues that human reviewers are likely to miss while maintaining a low false-positive rate, the implications are entirely different.

This is also one of the most frequently overlooked considerations when evaluating AI security tools: the number of discoveries is an outcome metric, not an efficiency metric. Without scan cost, code coverage, and human review time as denominators, comparing tools solely by “how many vulnerabilities they found” can easily turn into a leaderboard game.

More Practical Implications for Development Teams

For most developers, the value of this event does not lie in immediately purchasing an agent. Rather, it shows that code security workflows are changing.

First, security audits may shift from centralized checks before releases to continuously running asynchronous tasks. Agents can follow code changes while retaining context and propose testable hypotheses involving new entry points, privilege boundaries, and memory operations. Such an agent is more like an auditor who continuously participates in a project than a scanner that runs once per quarter.

Second, vulnerability reproduction and fix validation will become key competitive differentiators. General-purpose large language models can already generate plausible-sounding vulnerability descriptions. What truly sets products apart is whether they can build a project in an isolated environment, generate test inputs, observe crashes and memory anomalies, and revalidate the attack path after changes are made. This requires not only model capabilities, but also compilation, testing, fuzzing, and sandbox infrastructure.

Third, security teams will not disappear, but their focus will shift. Researchers will need to design threat models, assess exploitability, handle complex attack chains, and review AI-generated patches. Developers, meanwhile, must ensure reproducible builds, clear testing entry points, and well-described component privilege boundaries. Otherwise, no matter how much context an agent receives, it will struggle to produce reliable conclusions.

Fourth, AI tools themselves will become a new source of supply chain risk. Agents capable of reading an entire codebase, executing commands, and submitting patches possess extensive privileges. When deploying them, enterprises must restrict credential access, network egress, and execution environments; retain operation logs; and subject automatically generated fixes to normal code review processes. A tool’s responsibility for “security” does not make its own actions inherently secure.

The Impact on Apple’s Ecosystem Extends Beyond Safari

The real-world impact of WebKit vulnerabilities is usually broader than the Safari application itself.

On Apple platforms, many applications use system WebViews to load webpages, login screens, help centers, and hybrid interfaces. Vulnerabilities in the underlying WebKit engine could affect more application scenarios through these entry points. The exact scope of impact must still be determined from Apple’s security advisories for the relevant versions of iOS, iPadOS, macOS, and Safari, but developers should not limit their checks to whether desktop Safari has been updated.

Enterprise device management teams should push operating system and browser upgrades. Application teams using WebViews should check whether they load untrusted content, whether unnecessary JavaScript bridge interfaces are exposed, and which local capabilities the web process can access. WebKit patches address internal engine flaws, but overly broad interfaces exposed by applications still need to be handled separately.

As of August 19, public reporting has focused primarily on the number of vulnerabilities and who discovered them. There is no indication that the nine issues found by Codex Security have been exploited in the wild. However, the absence of evidence of exploitation does not mean updates can be postponed. After a security advisory is published, attackers can reverse-engineer the location of a vulnerability by analyzing patch differences. The release of a patch often marks the beginning of large-scale vulnerability analysis.

This Is a Report Card, Not the Final Verdict

Safari 26.6.1’s security release notes provide Codex Security with a striking report card: nine of 22 WebKit CVEs, or approximately 41%. Compared with a model’s score on a vulnerability benchmark, CVEs confirmed and fixed by a real vendor are far more convincing because they involve complex code, real product constraints, and rigorous validation processes.

However, the industry still needs more comparable data. Whether AI security agents are truly mature depends on whether they can repeatedly achieve results across different codebases, control false positives and costs, provide reproducible evidence, and generate patches that withstand regression testing. A single release with a high share of credited discoveries cannot answer these questions.

What is clear is that AI’s role in security engineering is moving beyond the stage of “explaining alerts.” It is beginning to participate in discovering real vulnerabilities that vendors are willing to confirm, assign identifiers to, and fix. For security teams, this represents a new productivity tool. For developers, it also means that future code reviews will cover not only functionality and performance, but also attack hypotheses continuously proposed by agents and accompanied by validation paths.

That matters far more than having yet another code assistant that can chat.

References

• ITHome: Safari 26.6.1 Fixes 22 WebKit Vulnerabilities, 9 Discovered by Codex Security: The primary source for the number of vulnerabilities, the share credited to each discoverer, and the main categories of impact discussed in this article.