Chrome 150 and Firefox 152 Fix Critical Bugs

Chrome 150 and Firefox 152 patch critical flaws, including public-exploit Firefox bugs and 15 Chrome fixes.

Firefox 152.0.6 and Chrome 150 are rolling out with urgent security fixes, and the numbers are hard to ignore. Mozilla says two of its bugs already have public exploit code, while Google says it patched 15 vulnerabilities in the latest browser update.

Firefox’s update is the one security teams will notice first

Mozilla’s patch for Firefox is small in count and large in risk. The company fixed two critical flaws, tracked as CVE-2026-15718 and CVE-2026-15719, and both were serious enough to trigger a direct warning about public exploit code.

The first bug is an invalid pointer issue in the JavaScript: WebAssembly component. The second is a site isolation problem in DOM: Navigation. Those are the kinds of flaws that matter because browsers process hostile content all day long, and a bug in that path can turn a normal page visit into a security event.

Mozilla’s wording is worth reading closely. The company says, “We are aware that exploit code for this is public however we are not aware of any attacks in the wild abusing this flaw,” for both weaknesses. That means the code is out there, but Mozilla has not seen live abuse yet.

“We are aware that exploit code for this is public however we are not aware of any attacks in the wild abusing this flaw,” Mozilla says in its advisory.

That distinction matters. Public exploit code often shortens the window between disclosure and real-world exploitation, especially for a browser that ships on desktops used by employees, contractors, and developers. If your organization allows Firefox on managed endpoints, this is a patch-now item, not a patch-later item.

Chrome 150 patches more bugs, but the critical ones are the headline

Google Chrome 150 fixes 15 vulnerabilities in total, and two of them are critical use-after-free flaws in Ozone, tracked as CVE-2026-15764 and CVE-2026-15765. Google also patched 12 high-severity bugs across Skia, Libyuv, HTML-in-Canvas, Linux Toolkit Theming, V8, Media, GPU, Core, and UI.

Those component names tell a familiar browser-security story. Rendering, graphics, media handling, and JavaScript execution are all places where memory-safety bugs tend to pile up. Google lists uninitialized use, heap buffer overflow, insufficient policy enforcement, insufficient validation of untrusted input, and more use-after-free issues among the corrected defects.

• 2 critical Chrome flaws were fixed in Ozone.
• 12 high-severity bugs were patched across graphics, media, and engine components.
• Only 3 of the Chrome bugs came from external researchers.
• The remaining issues were found by Google.

Google has not said whether any of the fixed Chrome bugs were exploited in the wild. That absence of a warning is better than the alternative, but it does not reduce the need to update quickly. When the browser itself is the attack surface, delay is the enemy.

The numbers show how much browser security still depends on memory safety

Chrome’s latest patch set is a reminder that modern browsers still spend a lot of time cleaning up memory bugs. Use-after-free, heap buffer overflow, and invalid pointer issues keep showing up because these code paths are high-performance and high-complexity at the same time.

If you compare the two releases, the difference is clear. Firefox shipped 2 critical fixes and flagged public exploit code. Chrome shipped 15 fixes overall, including 2 critical bugs and 12 high-severity ones, with no mention of active exploitation. That is a lot of security work for one browser cycle, and it shows how much pressure browser vendors are under to keep pace with attackers and researchers.

• Firefox 152.0.6 is the emergency-style release in this story.
• Chrome Releases 150.0.7871.124/.125 covers Windows and macOS.
• Linux gets Chrome 150.0.7871.124.
• The Chrome patch set spans engine, GPU, UI, and media code.

For enterprises, the practical takeaway is simple: browser patching belongs in the same fast lane as endpoint protection and identity fixes. A browser exploit can become a foothold for credential theft, session hijacking, or follow-on malware without needing a separate vulnerability in the operating system.

What admins should do before the next user reboots

Start with version checks. Firefox should be on 152.0.6, while Chrome should be on 150.0.7871.124 or 150.0.7871.125 depending on platform. If your fleet uses managed update rings, this is a good time to tighten the rollout window rather than let browsers sit on older builds for days.

It is also worth separating the risk profile by browser. Firefox has the sharper warning because exploit code is public. Chrome has the larger patch count, which suggests a wider cleanup across rendering and runtime components. Both deserve immediate attention, but the Firefox advisory has the more urgent tone.

Security teams should also watch for signs that browser patch fatigue is creeping into their environment. Users often ignore browser restarts, and IT teams sometimes treat browser updates as background noise. That habit gets expensive when a public exploit lands before the patch does.

The next question is not whether browsers will keep shipping these fixes. They will. The real question is how fast your organization can move from vendor advisory to enforced update, because the gap between those two points is where browser bugs become incidents.

Related reading: Microsoft’s 622-vulnerability Patch Tuesday and CISA’s urgent SharePoint warning.