CVE-2025-14174: The WebKit Zero-Day That Put Every Apple Device at Risk

In early December 2025, security researchers from Apple and Google were working together on something they did not immediately want the world to know about. A flaw had been found in a low-level graphics component shared across both Apple's WebKit engine and Google's Chromium codebase. Someone was already using it. The target list was short but specific, and the nature of the attacks pointed unmistakably toward sophisticated surveillance operations against carefully chosen individuals.

What followed was a coordinated, cross-vendor emergency patching effort that spanned Apple's entire product ecosystem, Google Chrome, Microsoft Edge, and several other Chromium-based browsers — all within the span of a week. The flaw at the center of it all is tracked as CVE-2025-14174, and it carries a CVSS score of 8.8 out of 10.

What CVE-2025-14174 Actually Is

CVE-2025-14174 is an out-of-bounds memory access vulnerability in ANGLE — the Almost Native Graphics Layer Engine. ANGLE is an open-source graphics abstraction library that translates OpenGL ES calls into platform-native graphics APIs. On macOS, the relevant backend is Metal, Apple's own low-level graphics framework. Google built ANGLE and uses it in Chrome. Apple incorporated it into WebKit. That shared dependency is precisely why a single bug could reach across two competing browser ecosystems simultaneously.

The technical root cause, surfaced through a GitHub commit tied to Chromium issue tracker ID 466192044, was an improper buffer sizing error in ANGLE's Metal renderer. The commit notes that the code was using pixelsDepthPitch — a value derived from GL_UNPACK_IMAGE_HEIGHT — to size buffers, even though that value can be smaller than the actual image height. In plain terms, the code was measuring the container before measuring what needed to go inside it — a classic precondition for a buffer overflow that leads to memory corruption, crashes, or arbitrary code execution.

When an attacker sends a maliciously crafted web page to a vulnerable browser, the ANGLE Metal renderer mishandles the buffer allocation. This allows the attacker to write data outside the boundaries of an allocated memory region. Depending on what data is overwritten, the result can range from a crash to full arbitrary code execution within the browser process. No plugin installation. No file download. No prompt to accept anything. The user only needs to visit the page.

Why WebKit Makes This Worse on iPhone and iPad

On most platforms, browser diversity provides some protection. If Chrome has a vulnerability, Firefox users may be unaffected. On iOS and iPadOS, that calculus does not apply. Apple mandates that every browser on its mobile platforms use WebKit as the underlying rendering engine. Chrome for iPhone is WebKit. Firefox for iPhone is WebKit. Edge for iPhone is WebKit. The browser name on your home screen is a wrapper; underneath, every one of them runs on the same engine.

This architectural reality means CVE-2025-14174 did not just affect Safari users. It affected every person using any browser on an iPhone or iPad running iOS before the patched version. The attack surface was the entirety of Apple's mobile user base, and the entry point was something as routine as loading a webpage.

Apple's December 12, 2025 security advisory stated awareness of a report that the vulnerability had been exploited in an extremely sophisticated attack directed at specific targeted individuals — on iOS versions prior to iOS 26. That language carries deliberate weight: Apple reserves the phrase "extremely sophisticated" for cases tied to commercial spyware operators or state-adjacent actors, not opportunistic mass exploitation. — Apple Security Advisory, December 12, 2025

The companion vulnerability, CVE-2025-43529, is a use-after-free flaw also in WebKit. It carries a Qualys Vulnerability Score of 95. A use-after-free bug occurs when a program continues to use a region of memory after it has been freed, allowing an attacker to place controlled data in that region and redirect program execution. CVE-2025-43529 was discovered separately by Google's Threat Analysis Group and was issued in response to the same report that produced CVE-2025-14174. Security researchers assess the two were likely deployed together as part of a chained exploit: CVE-2025-14174 to corrupt memory and gain a foothold, and CVE-2025-43529 to escalate that foothold into arbitrary code execution.

The Discovery Timeline: Apple and Google Working Together

The coordinated nature of the disclosure is notable. CVE-2025-14174 was jointly reported to Google on December 5, 2025, by Apple Security Engineering and Architecture (SEAR) and Google's own Threat Analysis Group (TAG). TAG is the team within Google specifically tasked with tracking state-sponsored and commercially operated threat actors — a detail that says much about who may have been behind the attacks.

The sequence matters. Google patched first, quietly, without a CVE number or description. That is unusual — vendors typically withhold technical details but do publish identifiers. The decision to suppress even the CVE number for several days after patching indicates the disclosing parties believed withholding information would limit the attacker's ability to adapt. Apple followed two days after the Chrome patch dropped. The full picture emerged only after Apple's advisories were published on December 12, when the connection between the Chrome fix and the WebKit flaw became clear to the public.

The Threat Actors Behind It

Apple and Google have not named any specific threat actor, and no indicators of compromise have been released publicly. Apple's use of the phrase "extremely sophisticated attack against specific targeted individuals" is a phrase pattern the company employs consistently in cases linked to commercial spyware vendors or nation-state-adjacent groups. It is not language Apple uses for opportunistic cybercriminal campaigns.

The involvement of Google TAG is a significant signal. TAG does not routinely investigate ordinary malware campaigns. Its mandate centers on advanced persistent threats, government-backed actors, and commercial surveillance vendors — the kinds of operations that sell spyware capabilities to governments for use against journalists, activists, dissidents, and political targets. When TAG co-discovers a vulnerability with Apple's SEAR team, the context strongly implies surveillance infrastructure.

Reporting from The Hacker News on December 13, 2025 assessed that both vulnerabilities were likely turned into weapons for narrowly targeted mercenary spyware campaigns — a conclusion grounded in the fact that CVE-2025-14174 and CVE-2025-43529 both reside in WebKit, the engine Apple mandates for every third-party browser on iOS and iPadOS. — The Hacker News, December 13, 2025

Security researchers at SecurityWeek noted separately that commercial spyware vendors are known to target iOS, macOS, Android, Chrome, and messaging applications. The combination of a WebKit zero-day with a use-after-free escalation primitive is the technical fingerprint of a professional exploit chain designed to achieve silent, complete device compromise with no visible indicators to the victim.

The Scope: Every Apple Device, Every Platform

Apple's emergency patches on December 12 were not limited to iPhone. The company released security updates across virtually its entire active product catalog. The following platforms received fixes for CVE-2025-14174 and CVE-2025-43529:

• iOS 26.2 and iPadOS 26.2 — iPhone 11 and later; iPad Pro 12.9-inch 3rd generation and later; iPad Pro 11-inch 1st generation and later; iPad Air 3rd generation and later; iPad 8th generation and later; iPad mini 5th generation and later
• iOS 18.7.3 and iPadOS 18.7.3 — iPhone XS and later; iPad Pro 13-inch; iPad Pro 12.9-inch 3rd generation and later; iPad Pro 11-inch 1st generation and later; iPad Air 3rd generation and later; iPad 7th generation and later; iPad mini 5th generation and later
• macOS Tahoe 26.2
• Safari 26.2 — available for macOS Sonoma and macOS Sequoia users who have not upgraded to Tahoe
• tvOS 26.2
• watchOS 26.2 — Apple Watch Series 6 and later
• visionOS 26.2 — Apple Vision Pro

The breadth of the patch release reflects how deeply embedded WebKit is in the Apple ecosystem. The rendering engine does not live solely in Safari — it powers the rendering layer for system applications, in-app browsers, and other components throughout the OS. Any unpatched Apple device capable of rendering web content was within the potential scope of exploitation.

Outside Apple's ecosystem, Chrome for Mac was patched to version 143.0.7499.110 or later on December 10. Microsoft Edge was patched to version 143.0.3650.80 on December 11. Chromium-based browsers including Vivaldi, Brave, Opera, and others were advised to apply available updates. With these two CVEs, Apple has now patched a total of nine zero-day vulnerabilities exploited in the wild during 2025 — a count that includes CVE-2025-24085, CVE-2025-24200, CVE-2025-24201, CVE-2025-31200, CVE-2025-31201, CVE-2025-43200, and CVE-2025-43300.

The Broader Pattern: WebKit as a Persistent Target

CVE-2025-14174 does not exist in isolation. It follows a clear and escalating trend of sophisticated actors investing heavily in WebKit exploitation. Earlier in 2025, a separate zero-day tracked as CVE-2025-24201 was discovered in WebKit and was also weaponized via maliciously crafted web content to break out of the Web Content sandbox entirely. The targeting of WebKit is rational from an attacker's perspective: because Apple mandates its use on iOS and iPadOS, a single WebKit zero-day provides access to every browser on the platform. There is no alternative engine to fall back on.

SOC Prime's December 16, 2025 analysis framed WebKit zero-days as evidence of a structural shift — the browser has become the central attack surface of the modern era. A flaw requiring no user interaction, producing no visible trace, and capable of delivering full device control is not a theoretical scenario; it is an active condition that unfolds before defenders have any reason to look. — SOC Prime, December 16, 2025

The ANGLE library's cross-platform role adds another dimension to this pattern. Because ANGLE is shared between WebKit and Chrome's Blink engine, a vulnerability in its Metal renderer represents a rare opportunity for attackers to deploy a single exploit chain against both Apple and Google's browser ecosystems simultaneously. The December 2025 campaign appears to have done exactly that. Google confirmed that its Chrome advisory for the same vulnerability explicitly noted an exploit existed in the wild before the patch was released.

This kind of cross-platform exploitation — leveraging a shared infrastructure component rather than targeting browser-specific code — is a more efficient investment for adversaries. It reduces the number of distinct vulnerabilities they need to maintain and broadens the potential target population while keeping the operational footprint small and the attack chain targeted.

What You Need to Do Right Now

Patching is the only effective mitigation. There are no workarounds that meaningfully reduce exposure to a zero-day of this nature in a browser engine. Apple recommends that users not rely solely on automatic updates in the days immediately following a security release, as automatic delivery may be delayed. Manual verification is the reliable path.

On iPhone or iPad, navigate to Settings > General > Software Update and confirm the device is running iOS 18.7.3 or iOS 26.2 (or later). On Mac, check System Settings > General > Software Update. Safari updates on macOS Sonoma and Sequoia are delivered through the App Store or via the Software Update panel, so verify Safari is on version 26.2 or later if you have not upgraded your macOS version.

For Chrome, navigate to the three-dot menu, select Help > About Google Chrome, and confirm the version is 143.0.7499.110 or higher. Google advises users to fully relaunch the browser after updating — a background update alone may not apply the fix until the process restarts. The same applies to other Chromium-based browsers: Edge users should confirm version 143.0.3650.80 or higher.

For organizations managing fleets of Apple devices, SOC Prime's guidance published December 16, 2025 is direct: enforce immediate OS and browser updates across all Apple devices, verify MDM compliance to prevent patch deferral, and treat any delay in applying updates as a confirmed security exposure. Monitoring for anomalous browser or network behavior following patch deployment is also advised, as exploitation may have occurred prior to patching in environments where updates were delayed.

copy# Verify iOS/iPadOS version from device settings
Settings > General > Software Update
Target: iOS 26.2 / iPadOS 26.2 or iOS 18.7.3 / iPadOS 18.7.3

# Verify Safari on macOS Sonoma or Sequoia
App Store > Updates (or Software Update panel)
Target: Safari 26.2

# Verify Chrome version
chrome://settings/help
Target: 143.0.7499.110 or later

# Verify Microsoft Edge version
edge://settings/help
Target: 143.0.3650.80 or later

Beyond the Patch: Structural Solutions Worth Examining

Patching resolves the immediate exposure. It does not resolve the conditions that produced it. The real conversation around CVE-2025-14174 is a structural one — about platform architecture decisions, shared infrastructure risks, and whether the current model of browser security on mobile platforms can hold against the caliber of adversaries now targeting it.

The WebKit Mandate and Browser Engine Diversity on iOS

The single most consequential structural factor in this vulnerability's reach is Apple's requirement that all iOS and iPadOS browsers use WebKit. This is not a security-neutral policy. It collapses browser diversity into a monoculture, which means any single WebKit zero-day simultaneously affects every browser on the platform regardless of which name is on the icon. The attack surface is total, not partial.

The EU's Digital Markets Act has already begun forcing Apple to allow alternative browser engines on iOS within the European Economic Area. The security implication is significant: a user running a Gecko-based Firefox or a Blink-based Chrome on iOS with native engine support would not have been exposed to a WebKit flaw. Engine diversity does not eliminate risk — it distributes it. An attacker who wants broad iOS coverage would need to develop and maintain separate exploit chains for each engine rather than one chain that works everywhere. That additional cost meaningfully raises the bar for mass exploitation, even if it does not eliminate targeted attacks against a single engine.

Whether Apple should face regulatory requirements to permit alternative engines globally — not just in the EEA — is ultimately a governance question about platform control, user choice, and systemic security risk. CVE-2025-14174 is a concrete data point for that policy debate.

Shared Library Risk in Open Source Infrastructure

ANGLE is open source and maintained primarily by Google. Apple incorporated it into WebKit. That decision produced real benefits — shared performance improvements, cross-platform rendering consistency, and reduced maintenance overhead. It also produced shared vulnerability exposure. When a bug lands in ANGLE, it does not discriminate between the browser ecosystems that depend on it.

The structural response to shared library risk is not to avoid shared libraries — the alternative is fragmentation, duplication, and likely more bugs from each team independently solving the same problems. The structural response is to invest in security review proportional to the exposure a shared component creates. ANGLE's Metal renderer, GPU memory handling, and boundary checking logic deserve resources commensurate with the fact that a single flaw there reaches billions of devices across two competing ecosystems. Concrete mechanisms worth evaluating include memory-safe rewrites of the highest-risk GPU path components, continuous fuzzing campaigns specifically targeting Metal and Vulkan backends, and cross-vendor security review agreements that formalize the kind of coordination that worked well for disclosure here but happened ad hoc rather than by design.

Spyware Vendor Accountability and the Exploit Broker Market

CVE-2025-14174 was not discovered and exploited by an opportunistic attacker. The involvement of Google TAG, the surgical targeting profile, and Apple's advisory language all point toward commercial surveillance operators who either paid professional researchers to find and weaponize this flaw or acquired a ready-made exploit chain from a vendor in the commercial spyware market.

The commercial spyware industry operates by acquiring zero-day exploits and packaging them into deployable surveillance products sold to governments and intelligence services. As long as that market exists and remains largely unregulated, the incentive structure driving research into flaws like CVE-2025-14174 remains intact. Patching one bug does not change that incentive. It redirects it to the next one.

Structural responses that operate at a different level than patching include legal accountability frameworks for spyware vendors operating across jurisdictions, export control regimes that treat commercially developed surveillance exploits as controlled dual-use technology, and financial sanctions against entities whose tools have been documented in human rights abuses. The civil litigation Apple and Meta pursued against NSO Group established that this pathway exists and can succeed. Using it consistently and internationally changes the economics of the spyware industry in ways that no individual patch can replicate.

OS-Level Browser Isolation as a Platform Feature

Modern browsers run multiple process isolation layers — renderer processes, GPU processes, network service processes — specifically to contain the damage from a renderer exploit. On iOS, these protections are constrained by Apple's own platform restrictions on what background processes can do and how deeply third-party browsers can implement their own isolation architectures. Chrome on iOS cannot implement the full multi-process model it uses on macOS or Android because of restrictions on how Apple permits apps to use multiple processes.

A structural path worth considering: Apple could expose a first-class process isolation API for browsers on iOS — one that would allow any browser, not just Safari, to implement a hardened sandbox for its rendering pipeline equivalent to what Safari uses internally. This would not require allowing alternative engines. It would require allowing alternative isolation architectures. The practical effect would be to reduce the damage from a successful renderer exploit even when the exploit itself cannot be prevented. The GPU process boundary that ANGLE's Metal renderer sits behind is precisely the kind of isolation boundary that, if robustly enforced on third-party browsers, limits the lateral reach of a memory corruption flaw.

Lockdown Mode as a Model for High-Risk Profiles

Apple's Lockdown Mode, introduced in iOS 16, is the most underused mitigation for the population CVE-2025-14174 targeted. It restricts a wide set of attack surfaces — including JIT compilation in WebKit, certain web technologies, and incoming connection requests from unknown devices — specifically to reduce exposure to sophisticated exploit chains of the kind used against journalists, dissidents, and political targets.

The structural opportunity is a tiered model: a moderate-restriction profile that disables the highest-risk attack surfaces while preserving most user-facing functionality, positioned between full Lockdown Mode and the default unprotected state. Organizations managing devices for high-risk individuals — press freedom organizations, human rights NGOs, legal firms handling sensitive cases — should be treating Lockdown Mode as a mandatory configuration for their members rather than an optional hardening step. Recommending it is not enough. Policy-level enforcement through MDM profiles is the mechanism that actually produces adoption at scale.

Post-Exploitation Detection as a First-Class Capability

Every mitigation strategy above operates before exploitation. The uncomfortable reality of zero-day attacks is that by the time a patch exists, the targeted individuals may already be compromised. The patch closes the door. It does not remove whoever came through it.

Mobile forensics for spyware detection has been largely confined to specialized organizations — Citizen Lab, Access Now's Digital Security Helpline, and Amnesty Tech's Security Lab. These groups have produced tools like the Mobile Verification Toolkit (MVT) that allow forensic examination of iOS backups and filesystem images for indicators of compromise associated with known spyware families. The structural gap is that this capability does not scale to individuals who lack organizational security support.

Closing that gap requires investment in accessible, automated post-exploitation detection tools that do not require forensic training to operate — and that can identify anomalous behavior patterns even when specific indicators of compromise for a new spyware variant have not yet been published. The forensic pipeline that runs from exploit delivery to post-compromise persistence leaves detectable traces if you know how to look. Making that capability widely available, not just accessible to researchers, is the missing layer in the current defense ecosystem.

Key Takeaways

1. This is not a theoretical risk: CVE-2025-14174 was confirmed exploited in the wild before either Google or Apple released patches. Real attacks against real targets had already occurred. The CISA KEV listing confirms this.
2. WebKit's mandatory status on iOS is a systemic risk: Because Apple requires all iOS and iPadOS browsers to use WebKit, a single WebKit vulnerability reaches every browser on the platform simultaneously. There is no browser choice that provides protection against a WebKit zero-day on iPhone or iPad.
3. Shared infrastructure creates shared exposure: The ANGLE library's presence in both WebKit and Chrome's Blink engine meant that a flaw in one graphics backend created an attack surface spanning two competing browser ecosystems. Cross-vendor coordination patching is increasingly necessary — and in this case, it worked.
4. The targeting pattern points to surveillance operations: Google TAG's involvement, the highly targeted nature of the attacks, the absence of mass exploitation, and Apple's specific language in its advisory all align with the known operational profile of commercial spyware vendors or state-adjacent threat actors.
5. Patch immediately, verify manually: Automatic updates are not a guarantee. Confirm patch status manually on every Apple device and every Chromium-based browser in your environment. Do not wait for the automatic update cycle to catch up.

The convergence of a shared graphics library flaw, mandatory WebKit usage on iOS, and a confirmed in-the-wild exploit chain represents exactly the kind of systemic risk that makes browser-layer security so consequential. CVE-2025-14174 is a reminder that the most dangerous entry point into a device is often the most ordinary one: a webpage loading in a browser you trust.