How do I fix CVE-2026-0881?

Update Firefox to 147 or later and Thunderbird to 147 or later. Use the built-in updater (Help, About) or your managed-deployment channel. There is no configuration workaround for a sandbox escape; the patched build is the fix.

● Critical · CVSS 10.0

How to fix CVE-2026-0881: sandbox escape in Firefox and Thunderbird

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚡ At a glance

Severity	Critical, CVSS 3.1 base 10.0 (`AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`)
Product	Mozilla Firefox and Mozilla Thunderbird
Affected	All Firefox and Thunderbird builds before version 147
Fixed in	Firefox 147 · Thunderbird 147
Type (CWE)	CWE-693 Protection Mechanism Failure / CWE-284 Improper Access Control (sandbox escape)
Actively exploited?	No. CISA SSVC Exploitation: none; not in CISA KEV
Attacker requirement	Network reachable, no privileges, no user interaction (per CVSS vector)

Exploitation status

Here is the part people get wrong on a CVSS 10.0 score: the number is bad, but the field telemetry is calm. CISA's SSVC vulnrichment for CVE-2026-0881 records Exploitation: none, and the CVE is not listed in the CISA Known Exploited Vulnerabilities catalog. So there is no federal due date and no confirmed in-the-wild abuse as of the record's last update. The SSVC entry does flag Automatable: yes and Technical Impact: total, which is exactly why Mozilla rated it Critical: if a working exploit ever surfaces, it scales.

The Mozilla credit goes to Andrew McCreight, and the bug was disclosed and fixed in the same advisory cycle (mfsa2026-01 for Firefox, mfsa2026-04 for Thunderbird). No public proof-of-concept or Metasploit module is referenced in the CVE record. Treat that as "not yet," not "never." A sandbox escape that needs no user interaction is the kind of primitive that gets chained into a full browser compromise once a memory-safety bug pairs with it.

Authoritative references:

What is CVE-2026-0881?

CVE-2026-0881 is a sandbox escape in the Messaging System component shared by Mozilla Firefox and Mozilla Thunderbird. That is the vulnerability in one sentence, taken straight from Mozilla's own description. The sandbox is the wall that keeps untrusted web or message content boxed off from the rest of your machine. A sandbox escape means content that was supposed to stay inside that box can climb out of it.

Mozilla assigned it CWE-693 (Protection Mechanism Failure) and CWE-284 (Improper Access Control), which is the formal way of saying a security control that was meant to contain the process did not hold. The CVSS 3.1 base score is the maximum, 10.0, with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Read that vector left to right and it tells the whole story: reachable over the network, low attack complexity, no privileges needed, no click required, and (the part that pushes it to a perfect 10) a changed scope, meaning the impact crosses out of the sandboxed component into the rest of the system. Confidentiality, integrity, and availability all take a high hit.

The fix landed in Firefox 147 and Thunderbird 147. The CVE record marks version 147 and later as unaffected in both products, so every build below 147 carries the flaw. Andrew McCreight is credited with the discovery.

Why this CVE matters

A browser sandbox escape is not the same kind of bug as a typo in a config file. The sandbox is the last line of defence after a renderer-process bug. Researchers chain a memory-safety crash in the content process with a sandbox escape like this one to turn "the tab crashed" into "code is now running on your account." On its own, this flaw is a building block. Paired with the right partner bug, it is a full compromise.

Two details make CVE-2026-0881 worth jumping on even though nobody has weaponised it yet. First, the CVSS vector says no user interaction is required, so there is no "do not click suspicious links" advice that helps here. Second, CISA's own assessment marks it Automatable: yes with a total technical impact. That combination is shorthand for "if an exploit appears, it will be mass-scannable." The good news is that the patch is trivial to apply and ships through Mozilla's normal update channel.

Am I affected?

You are affected if you run Firefox or Thunderbird at any version below 147. Checking takes about ten seconds, and you do it inside the application, not from a Linux package manager, because this is desktop software, not a server daemon.

In Firefox, open the menu (the three lines, top right), choose Help, then About Firefox. The version sits right under the logo, and that same dialog triggers an update check automatically. In Thunderbird, open the menu, choose Help, then About Thunderbird. If either reads 147 or higher, you already have the fix. Anything from 146.x down is vulnerable.

Managing a fleet? Check your deployment channel rather than poking each desktop. The relevant question is which build your ESR or Rapid Release packages are currently pinned to.

How to fix CVE-2026-0881

There is no registry tweak, no about:config flag, no firewall rule that closes a sandbox escape. The only real fix is the patched build: Firefox 147 or later and Thunderbird 147 or later. Pick the path that matches how the software got onto the machine.

Self-managed desktop (the common case)

Open Firefox. Go to menu → Help → About Firefox. Firefox checks for updates the moment that window opens.
When it reports a newer version, click Restart to update Firefox. The download and install happen on their own; you just need the restart.
Do the same in Thunderbird via menu → Help → About Thunderbird, then restart it.
Reopen the About dialog and confirm it now reads 147 or higher.

If your build does not see the update, common on a locked-down or air-gapped machine, download the current installer directly from mozilla.org/firefox or thunderbird.net and run it over the existing install. It keeps your profile.

Enterprise / managed deployments

If your organisation manages Firefox or Thunderbird centrally, push the update the way you push every other one, and do not let users self-serve a critical patch on their own schedule.

Windows (MSI + Group Policy): deploy the 147 MSI through your usual GPO or Intune package. The Mozilla ADMX templates let you force DisableAppUpdate=false so background updates stay on between rollouts.
macOS (MDM): ship the 147 .pkg through Jamf or your MDM and let the app's built-in updater handle increments after that.
Linux desktops: if Firefox or Thunderbird came from your distribution's repository, update through that repository's normal channel and confirm the packaged version is 147 or later. Distributions sometimes lag Mozilla's release by a day or two, so verify the actual version string rather than assuming the latest package is patched. If you use Mozilla's own tarball or a Flatpak/Snap build, update that source instead.

Confirm the running version

The honest verification for a desktop app is the version number, not a network scan. On any platform, the About dialog is authoritative. If you want a scriptable check on Windows for fleet reporting, read the installed version from the binary metadata:

# Windows: report the installed Firefox version across a fleet
(Get-Item "C:\Program Files\Mozilla Firefox\firefox.exe").VersionInfo.ProductVersion

# Thunderbird equivalent
(Get-Item "C:\Program Files\Mozilla Thunderbird\thunderbird.exe").VersionInfo.ProductVersion

Anything that returns 147.0 or higher is patched against CVE-2026-0881. There is no service to restart and no daemon to reload; closing and reopening the application after the update is all that is required for the patched binary to be the one in memory.

If you cannot patch immediately

There is no supported workaround that neutralises a sandbox escape, so do not let anyone sell you a half-measure as a substitute for the update. Disabling the Messaging System component is not a documented, supported option in the advisory, and turning off the sandbox would make things worse, not better.

If a maintenance freeze genuinely blocks the upgrade for a few days, reduce exposure in the meantime: keep the affected machines off untrusted networks, hold users to known-good sites and message sources, and prioritise patching anyone whose browser regularly opens attachments or links from outside the organisation. None of that fixes the bug. It only buys hours. Schedule the real update as soon as the window opens.

Operational guidance for browser and mail-client patching

A few things I keep in mind whenever a 10.0 browser or mail-client CVE crosses my desk, grounded in how Firefox and Thunderbird actually ship updates rather than generic server playbooks.

The version number is ground truth. For desktop software, "did the patch land" is answered by the About dialog or the binary's version metadata, not by a network vulnerability scanner. A scanner that probes ports tells you nothing useful about a client-side sandbox escape.
Restarts matter more than people expect. Firefox and Thunderbird stage an update but only swap to the patched binary on restart. A fleet that downloaded 147 but never restarted is still running the vulnerable code. Confirm the version after the relaunch, not before.
Two products, one bug. It is easy to patch Firefox and forget Thunderbird, because the mail client opens far less often. Both share the Messaging System component here, so both need 147. Track them as one task.
Trust the vendor advisory over aggregators. Mozilla advisories mfsa2026-01 and mfsa2026-04 are the source of truth for the fixed-in version. Third-party trackers sometimes list the affected version as if it were the fix; the CVE record is explicit that 147 is the first unaffected release.
Re-enable background updates after a managed rollout. If you froze auto-updates to control the rollout, turn them back on once 147 is deployed, so the next critical fix does not wait on a manual cycle.

Frequently asked questions

Which Mozilla products does CVE-2026-0881 affect?

Both Firefox and Thunderbird. The CVE record lists Firefox 147 and Thunderbird 147 as the first unaffected releases, so any build below 147 in either product is vulnerable. The shared culprit is the Messaging System component.

Is CVE-2026-0881 being exploited in the wild?

No. CISA's SSVC assessment records Exploitation as none and the CVE is not in the CISA Known Exploited Vulnerabilities catalog. Because the CVSS score is 10.0 and the bug is automatable, update promptly anyway rather than waiting for exploitation to be confirmed.

Will antivirus or a firewall protect me until I patch?

Not reliably. A sandbox escape lives inside the browser process itself, so network filters and signature-based antivirus have nothing clean to block. The patched build is the only durable fix; outside controls only reduce the odds of encountering the trigger content.

Do I need to patch Thunderbird even if I rarely use it?

Yes. The same Messaging System flaw is present in Thunderbird below 147. A mail client that opens infrequently is easy to forget, which is exactly why it tends to stay unpatched the longest. Update it to 147 alongside Firefox.

How long does the update take?

For a single desktop, a couple of minutes; the built-in updater downloads in the background and applies the change on the next restart. Your saved tabs, profile, and add-ons survive the update. For a managed fleet, the limiting factor is your deployment cadence, not the update itself.

References

Official vendor advisory: https://bugzilla.mozilla.org/show_bug.cgi?id=2005845
NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2026-0881
CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Additional vendor or research reference: https://www.mozilla.org/security/advisories/mfsa2026-01/
Additional vendor or research reference: https://www.mozilla.org/security/advisories/mfsa2026-04/

This guide was assembled from the official vendor advisory, the NVD record, and the CISA KEV catalog entry on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Rolling 147 out without missing a machine

The trap on a bug like this is not the patch itself, which is genuinely a two-minute job per desktop. The trap is coverage. I have watched a "done" rollout sit at 90 percent for a week because nobody tracked the machines that download an update but never restart. Firefox stages 147 quietly in the background and then keeps running the old binary until someone closes the window. A laptop that lives in suspend for ten days never gets that restart.

So the metric I report on is not "147 pushed." It is "147 confirmed running." Those are different numbers, and the gap between them is where a CVSS 10.0 sandbox escape lingers. Pull the version string off each machine after the relaunch and reconcile it against your asset list. The PowerShell one-liner higher up the page is what I feed into that report.

Thunderbird is the quiet half of this. People open Firefox forty times a day and the mail client maybe twice, so its update prompt gets dismissed or simply never appears. Because the same Messaging System component carries the flaw in both products, a fleet that is fully patched on Firefox and stale on Thunderbird is still exposed. I treat the two as a single line item on the rollout sheet rather than two tasks, precisely so the mail client does not slip.

One more habit worth keeping: if you froze automatic updates to control the rollout window, schedule the un-freeze the same day you confirm 147. The next Mozilla critical will land on its own cycle, and you do not want it waiting behind a manual gate you forgot to reopen. A browser that updates itself is the cheapest security control you own; turning it off should always be temporary and always have an end date on the calendar.

Other defects in the same area that deserve attention during this patch cycle: