Firefox and Chrome fixes turn browser patching into this week's urgent control

Mozilla and Google both shipped important browser security updates this week, and the Firefox side deserves special attention: Mozilla says exploit code is already public for two critical Firefox vulnerabilities fixed in version 152.0.6.

The Mozilla issues are CVE-2026-15718, an invalid pointer flaw in the JavaScript WebAssembly component, and CVE-2026-15719, a critical site-isolation issue in DOM Navigation. Mozilla says it is aware that exploit code for both flaws is public, although it is not aware of in-the-wild attacks abusing them.

Google's Chrome update landed in the same patch window. The Stable channel moved to 150.0.7871.124/.125 for Windows and macOS, and 150.0.7871.124 for Linux, with 15 security fixes. Two of those are critical Ozone use-after-free bugs tracked as CVE-2026-15764 and CVE-2026-15765.

For defenders, the story is bigger than two browsers. It is a reminder that browsers remain one of the most exposed enterprise runtimes: always online, constantly handling untrusted content, heavily integrated with identity, SaaS, file downloads, password managers, and endpoint policy.

What Mozilla fixed

Mozilla Foundation Security Advisory 2026-67 was announced on July 14, 2026 and fixes two critical vulnerabilities in Firefox 152.0.6.

The first issue, CVE-2026-15718, is an invalid pointer bug in the JavaScript WebAssembly component. WebAssembly is a legitimate browser technology used by modern web applications, but bugs in this area are high-value because they live close to complex execution paths that process attacker-controlled web content.

The second issue, CVE-2026-15719, affects site isolation in the DOM Navigation component. Site isolation is one of the browser defenses meant to limit how web content from different origins can interact. When that boundary fails, the risk can move beyond a simple tab crash into the kind of cross-site or sandbox-adjacent behavior defenders take seriously.

Mozilla's most important operational note is that exploit code is public for both vulnerabilities. Public exploit code does not automatically mean mass exploitation, but it does change the clock. Once working proof material is available, scanning, adaptation, and weaponization usually become easier for attackers.

What Google fixed in Chrome

Google's July 14 Chrome Stable update includes 15 security fixes. The most severe are:

• CVE-2026-15764 - critical use-after-free in Ozone
• CVE-2026-15765 - critical use-after-free in Ozone
• CVE-2026-15766 - high-severity uninitialized use in Skia
• CVE-2026-15767 - high-severity heap buffer overflow in libyuv
• CVE-2026-15770 - high-severity uninitialized use in V8
• CVE-2026-15776 - high-severity type confusion in V8

Ozone is Chromium's platform abstraction layer for interacting with native windowing systems. That may sound obscure, but the risk is practical: memory corruption bugs in browser components can become part of remote code execution chains when a user visits or interacts with a crafted page.

The Center for Internet Security's advisory says there are currently no reports of these Chrome vulnerabilities being exploited in the wild. That is useful context, but it should not lower urgency too much. Browser patching is one of the few controls where delay directly increases exposure to common browsing activity.

Why exploit code changes the priority

Security teams often triage browser updates differently from server-side vulnerability alerts. That can be a mistake.

Servers may have clear internet exposure, but browsers expose every endpoint user to hostile input through normal work: email links, SaaS apps, documentation portals, search results, customer sites, ad networks, and compromised legitimate pages. If a browser flaw has public exploit code, the defensive window gets narrower.

Public exploit code affects risk in three ways:

• it reduces the effort needed for low-skill attackers to test the bug
• it gives more capable actors a starting point for exploit-chain development
• it increases the chance that defenders will see opportunistic probing before official patch adoption is complete

Mozilla says it has not observed exploitation in the wild. That is good news. But the right response is not to wait for exploitation to appear in telemetry. The right response is to close the window before public code turns into field activity.

Enterprise impact: browsers are identity-adjacent

Modern browsers are not just content viewers. They are where users authenticate, approve MFA prompts, access cloud consoles, download files, open documents, manage password vault extensions, and administer SaaS platforms.

That makes browser compromise strategically useful. A successful chain may let attackers steal session material, read sensitive data in active SaaS sessions, abuse delegated identity, or pivot into local host compromise depending on the bug, sandbox state, and endpoint controls.

This is why browser patch management should be measured in hours or days for critical issues, not vague monthly cycles. If automatic updates are enabled but endpoints do not restart, the fleet may still be functionally exposed.

What defenders should do now

1. Confirm Firefox is at 152.0.6 or later

Prioritize endpoints with Firefox installed, especially developer workstations, administrators, high-risk users, and systems that browse untrusted content. Confirm both application version and restart state.

2. Confirm Chrome is on the fixed Stable build

For Chrome, verify 150.0.7871.124/.125 or later on Windows and macOS, and 150.0.7871.124 or later on Linux. Because Google rolls out updates over time, enterprise-managed update policies should be checked rather than assumed.

3. Watch for update lag

The most common failure is not that updates are unavailable. It is that browsers are waiting for a restart, managed devices are pinned to older channels, or endpoint software inventory lags behind reality.

Useful checks include:

• browser version inventory by host and user group
• pending browser restart indicators
• update policy status for managed Firefox and Chrome deployments
• endpoints that have not checked in recently
• high-privilege users running outdated browser builds

4. Reduce exploit blast radius

Browser patching should be paired with layered controls:

• keep OS and GPU drivers current
• restrict unnecessary browser extensions
• isolate high-risk browsing from privileged administration
• avoid using privileged accounts for routine web activity
• use DNS and URL filtering for known malicious infrastructure
• enable endpoint exploit protections where available

None of those controls replaces patching. They reduce the damage if a browser exploit lands before every endpoint is current.

5. Treat suspicious browser activity as an investigation trigger

If security tools show browser crashes, unusual child processes, strange script execution, unexpected downloads, or identity alerts near browsing sessions, move quickly. A browser exploit may not look like a classic malware infection at first.

Strong incident response should correlate:

• browser crash telemetry
• endpoint process creation after browser activity
• suspicious downloads or temporary files
• unusual SaaS session behavior
• impossible travel or anomalous identity events
• alerts involving browser extensions or credential stores

The question is not only "was the browser exploited?" It is also "what did the user have access to when the browser became untrusted?"

Why this deserves board-level hygiene, not panic

There is no public evidence in the reviewed advisories that these Firefox or Chrome vulnerabilities are being actively exploited at the time of writing. That matters. This is not a confirmed mass-compromise story.

But it is still a useful test of operational maturity. Critical browser bugs with public exploit code should not require heroic manual effort. Mature teams should already have a repeatable play:

1. identify affected browsers
2. force or accelerate update policy
3. confirm restarts
4. isolate systems that cannot patch quickly
5. monitor for suspicious browser-to-host behavior
6. report fleet coverage to security and IT leadership

If that process is manual, unclear, or split across teams, this week's patch window is a good reason to fix it.

Strategic takeaway

The browser is one of the most important attack surfaces in the enterprise because it lives where identity, cloud data, and untrusted content meet.

Mozilla's public-exploit-code warning for Firefox and Google's critical Chrome memory fixes should push browser updates into the urgent lane. Do not wait for KEV inclusion or confirmed exploitation to act. When a critical browser bug is patched and exploit code is public, the lowest-risk move is fast update verification across the fleet.

Which Firefox vulnerabilities are critical?

Mozilla fixed CVE-2026-15718, an invalid pointer issue in JavaScript WebAssembly, and CVE-2026-15719, a site-isolation issue in DOM Navigation. Both are rated critical.

Is Firefox being actively exploited?

Mozilla says exploit code is public for both fixed flaws, but it is not aware of attacks in the wild abusing them.

Which Chrome vulnerabilities are most severe?

Google listed two critical Ozone use-after-free issues: CVE-2026-15764 and CVE-2026-15765. The Chrome update also fixes several high-severity issues in components including Skia, V8, GPU, Core, UI, and Media.

What versions should organizations deploy?

Firefox should be updated to 152.0.6 or later. Chrome should be updated to 150.0.7871.124/.125 or later on Windows and macOS, and 150.0.7871.124 or later on Linux.

What is the highest-priority action?

Confirm update coverage and restart status across managed endpoints, especially for administrators, developers, finance users, executives, and anyone regularly handling untrusted web content.

References

1. Mozilla Foundation Security Advisory 2026-67
2. Mozilla Foundation Security Advisories
3. Stable Channel Update for Desktop
4. Multiple Vulnerabilities in Google Chrome Could Allow for Arbitrary Code Execution
5. CVE-2026-15764 Detail