Two things are true at once: the WebKit zero‑day patched in Apple’s December platform updates was exploited in the wild against targeted users, and Google’s Chrome team rushed a fix for a high‑severity ANGLE bug later assigned CVE‑2025‑14174. If your business ships on the web—or runs on fleets of iPhones, Macs, and Chromebooks—this is not a wait‑and‑see moment. It’s a small, focused patch sprint with checks that keep product stable.

Illustration of a security war room tracking browser updates in December 2025

What exactly changed—and when?

Here’s the timeline that matters for planning and compliance conversations. On Friday, December 12, 2025, Apple released iOS/iPadOS 26.2, macOS 26.2, watchOS 26.2, tvOS 26.2, and Safari 26.2. Among the fixes were two WebKit vulnerabilities credited to Apple and Google researchers, one a use‑after‑free leading to code execution and another a memory corruption flaw. Apple’s advisories noted targeted exploitation on versions prior to iOS 26.

Separately, the Chrome Stable channel moved on December 10, 2025 to build 143.0.7499.109/.110, with a security note referencing a then‑restricted bug. By December 13, that issue had a CVE—CVE‑2025‑14174—tied to out‑of‑bounds memory access in ANGLE. And on December 18, Chrome advanced again to 143.0.7499.169/.170, a fast follow that enterprises should treat as the de‑facto baseline.

Bottom line: the December browser patch window isn’t just another Tuesday—there are multiple, coordinated fixes across Apple platforms and Chromium that reduce real exploitation risk.

The business impact in plain language

Why should product and security leaders care when the attack narrative emphasizes “targeted individuals”? Because the exploit class is the point. Memory safety bugs in engines like WebKit and ANGLE are perfect for drive‑by attacks, watering hole compromises, and cross‑platform persistence via embedded webviews. You don’t need broad exploitation to warrant action; you need a reproducible patch path for every runtime your customers and employees touch.

Three areas move the needle fastest:

Employee fleets: iOS/macOS updates close the WebKit path in Safari and any WKWebView‑based enterprise apps.
Customer‑facing apps: embedded browsers (Electron, Capacitor, Cordova, in‑app webviews) inherit engine bugs until you ship the runtime that carries the upstream fix.
Kiosks and managed browsers: Chrome’s ANGLE fix needs a forced relaunch policy to actually take effect on endpoints that run for days.

Fast facts you can paste into a ticket

Use this as your internal note or change request header:

• Apple platform updates: iOS/iPadOS 26.2, macOS 26.2, watchOS 26.2, tvOS 26.2, Safari 26.2 released December 12, 2025. Two WebKit CVEs fixed, with Apple noting exploitation against targeted users on pre‑iOS‑26 builds.
• Chrome updates: Stable 143.0.7499.109/.110 (December 10, 2025) included the ANGLE fix later tracked as CVE‑2025‑14174; Stable updated again to 143.0.7499.169/.170 on December 18, 2025. Treat .169/.170 as required.
• Risk class: memory corruption and out‑of‑bounds access—potential for arbitrary code execution via malicious web content; likely vectors include drive‑by pages and malicious ads.

The 48‑hour patch plan (works for holidays, too)

If you’ve run our “patch and prove” drills for runtime vulns, this will feel familiar. If you haven’t, start here and tighten over time. For a related, runtime‑focused approach, see our 48‑hour patch plan we use with backend teams.

Hour 0–2: Declare scope and owners

Open a short‑fuse incident in your tracker. Define three workstreams and DRI per stream:

Apple endpoints and embedded WKWebView apps
Chromium browsers and Electron/NW.js runtimes
Monitoring and validation (telemetry + canaries)

Set the success metrics up front: 95% of Apple endpoints on 26.2 within 48 hours; 95% of managed Chrome on 143.0.7499.169+ and relaunched; 100% of customer‑facing binaries rebuilt/published with patched runtime or pinned WebView baseline.

Hour 2–12: Push updates and force relaunch where needed

Apple fleets: schedule OS updates via your MDM with deadlines and automatic deferral windows. Prioritize high‑risk personas (execs, researchers, field staff) in the first wave. Because WKWebView ships with the OS, the only safe state is iOS/iPadOS/macOS 26.2+. On macOS, install Safari 26.2 even if your default browser is Chrome.

Chrome fleets: verify the Stable version policy, then send a forced relaunch notification. Patching without a browser restart isn’t patching. Confirm extension compatibility in ring‑0 canaries and widen gradually if your org locks to Extended Stable. If you manage kiosks, treat this as an emergency maintenance window.

Developers: for Electron or NW.js apps, pull the latest security patch line that picks up Chromium 143.0.7499.169/.170. If you ship a mobile app with webviews, publish a hotfix that raises your minimum supported OS or declares 26.2 as required for sensitive flows. If you run a Next.js or React app in a hybrid shell, combine this browser sprint with your framework upgrades; our Next.js security patch playbook lays out sane version targets.

Hour 12–24: Prove coverage with telemetry, not vibes

Dashboards should answer: what percentage of active endpoints are patched, which ones haven’t relaunched Chrome, and which customer sessions are on vulnerable engines? If you can’t see webview versions, add a temporary header from the app shell advertising runtime build ID and surface it in your logs for the next seven days.

Also, add backend checks: reject sessions from versions you deem unsafe for privileged actions (admin consoles, wire transfers, token issuance). Provide a clear UX explaining why and how to update.

Hour 24–48: Sweep the long tail and communicate outward

Escalate stragglers with auto‑remediation: schedule overnight installs on power and Wi‑Fi, and suspend risky flows in unmanaged browsers until patched. Publish a short customer note: “We updated our desktop and mobile apps’ embedded browsers and recommend updating your OS and browser to the latest versions.” Keep it factual; no drama.

Does a WebKit zero‑day affect my app if we “only use Chrome”?

Yes, if your macOS users have Safari or any app that embeds WKWebView—which many enterprise tools do. And iOS apps don’t get to choose an alternative browser engine; the system webview is WebKit. That’s why the Apple OS updates matter even if your default browser is something else.

What about Android and enterprise Chromebooks?

Android System WebView typically updates via the Play Store in lockstep with Chrome. If you manage Android devices, verify Chrome/WebView versions and enforce a relaunch. For ChromeOS, push the update and set a session‑timeout relaunch window so browser instances don’t limp along unpatched for days.

Can CSP or sandbox headers blunt these bugs?

Security headers are essential, but they don’t patch memory corruption in a browser engine. However, strict CSP and Permissions-Policy do make post‑exploitation more painful by limiting script injection and powerful APIs. Think of headers as seatbelts; this week you also need the airbag: the patch.

Developers: ship this runtime checklist today

When browsers move, app runtimes must follow. Here’s a practical list teams can run in parallel with the fleet update:

Electron/NW.js: upgrade to the latest security patch series that pulls Chromium 143.0.7499.169/170 or newer. Rebuild, code‑sign, and publish. Add a runtime version banner to diagnostics so support can confirm live.
iOS apps with WKWebView: test on iOS 26.2 and bump your minimum supported iOS for sensitive features (e.g., in‑app payments, admin panels) if you can’t rely on user updates.
Android apps: verify androidx.webkit compatibility, and in QA make sure the System WebView reports the patched Chrome build.
In‑product notices: for admin‑level pages, inject a temporary warning for outdated browsers with a link to update instructions.
Telemetry: log the user agent and a server‑parsed engine version to avoid spoofing by extensions.

Proof it’s fixed: what to measure

Don’t close the incident until you can assert these with evidence:

95%+ of managed iPhones and iPads report 26.2 within your MDM.
95%+ of managed Macs report macOS 26.2 and Safari 26.2; unmanaged Macs show strong uptake in your posture agent.
95%+ of managed Windows/macOS endpoints run Chrome 143.0.7499.169/.170 or newer, with a last‑relaunch timestamp within 24 hours of update deployment.
100% of customer‑facing desktop runtimes rebuilt on a Chromium baseline that includes the ANGLE fix; mobile shells tested against webviews on patched OS versions.

If you don’t have that telemetry, borrow from our earlier “patch and prove” workflows for runtime incidents. The operational ideas in Patch and Prove translate directly to browsers and webviews.

Zooming out: December’s lesson for engineering leaders

This month already gave teams a master class in “layers, not silos.” React2Shell forced framework upgrades, and now engine bugs force OS and browser updates. The practical takeaway: build a standing, cross‑functional playbook for client runtimes the way you already do for backend runtimes. That includes pre‑approved maintenance windows, DRI rotations, and canary cohorts of high‑value personas.

If your team is still juggling dependency upgrades and emergency patches manually, standardize it. Our Next.js hardening notes pair well with a browser patch cadence, and we’re happy to help you design both.

What to do next (today, not next sprint)

Here’s the short action list you can run before lunch:

Push iOS/iPadOS/macOS/watchOS/tvOS 26.2 and Safari 26.2. Verify with MDM.
Update Chrome to 143.0.7499.169/.170 and force a relaunch across fleets.
Rebuild Electron/NW.js apps on a patched Chromium and publish hotfixes.
Add telemetry for browser/engine versions to your login and admin endpoints.
Review CSP and Permissions-Policy for sensitive pages to reduce post‑exploitation blast radius.
Schedule a 30‑minute retro to trim time‑to‑patch for the next event.

If you want a hand tightening your patch workflow without derailing releases, take a look at our security and engineering services or reach out via our contact form. We’ll help you turn this week’s scramble into next quarter’s muscle memory.

Photo of iPhone and Mac updating to latest versions

FAQ for compliance and audits

What version should we cite as our minimum secure baseline?

For Apple platforms: OS 26.2 (iOS/iPadOS/macOS/watchOS/tvOS) and Safari 26.2. For Chrome: 143.0.7499.169/.170 or later. If your app embeds a webview or Chromium runtime, cite the specific app build that includes the patched engine.

How do we handle unmanaged devices?

Block admin actions, payments, or other sensitive flows from outdated engines until the user updates. Present a helpful banner with one‑click update instructions. It’s pragmatic risk reduction while you land the fleet‑wide fixes.

Do we need to rotate credentials?

Engine‑level bugs don’t automatically imply server compromise, but if your threat intel or logs suggest risky browsing on privileged accounts, rotate tokens and keys used from potentially exposed endpoints. We recommend pairing browser updates with a periodic privileged‑account hygiene pass.

A final word before you ship for the weekend

Emergencies like this always arrive at the worst time. The good news: the fixes exist, the upgrade paths are clear, and you’ve got a battle‑tested process. Run the plan, verify with data, and build the muscle so the next patch sprint takes hours, not days. And if you’re juggling multiple fires this month—from framework RCEs to browser zero‑days—our notes in the Bybowu blog and the earlier security primers will keep you pointed at the right fixes first.

Diagram of layered patching across framework, browser engine, and OS

WebKit Zero‑Day + Chrome ANGLE: Patch Now

What exactly changed—and when?

The business impact in plain language

Fast facts you can paste into a ticket