Is CVE-2022-26485 (Mozilla Firefox Use-After-Free) being exploited in the wild?

Yes. CISA added CVE-2022-26485 to its Known Exploited Vulnerabilities catalogue on 7 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Mozilla Firefox contains a use-after-free vulnerability in XSLT parameter processing which can be exploited to perform arbitrary code execution. Any organisation running the affected product should treat remediation as urgent.

How to read “being exploited in the wild” for this Firefox CVE

For a browser CVE, “in the wild” means more than a plausible proof of concept. It means defenders should assume the weakness is already being used against real targets, often through drive-by delivery, malicious content, or a crafted page that persuades the browser to process attacker-controlled data. That changes the response from normal patch planning to urgent exposure reduction and verification.

CVE-2022-26485 is especially important because the direct path to impact is code execution inside a widely deployed client application. Once exploitation is confirmed by a trusted source such as CISA’s catalog, the practical question is no longer whether the flaw is real, but whether your estate can still be reached before remediation is complete.

That is why vulnerability management guidance for confirmed exploitation should be treated as a live operational control, not a reporting exercise, and why browser hardening belongs alongside patching in any response plan. For prioritisation and verification workflows, use the Vulnerability Management Guide as the broader process reference.

What organisations should confirm first

The first check is simple: which endpoints and user populations still run the affected browser version, and how quickly can they be updated or isolated? For browser CVEs, exposure is usually broad because the software is user-facing, heavily distributed, and often allowed to reach untrusted content by design.

From a response perspective, this is a high-confidence exploitation signal, so the priority is to identify live install base, verify remediation status, and reduce the window in which users can be targeted. If you have an enterprise browser control stack, this is also the moment to confirm whether policy enforcement is actually preventing unsupported or stale versions from persisting.

When organisations need a structured control set for browser policy, extension control, and isolation measures, the Enterprise Browser and Browser Security Guide is the most relevant internal reference.

Because this CVE is about confirmed exploitation, compare your remediation state against the CISA Known Exploited Vulnerabilities Catalog rather than waiting for a generic risk score to drift higher.

Why browser exploitation needs a compromise check, not just a patch

A use-after-free in browser content processing can be used as a foothold for arbitrary code execution, which means the issue is not limited to crash risk or nuisance behaviour. In practice, that creates a need to ask whether a user session, profile, or endpoint was already touched before patching started.

Zero-Day and Exploited Vulnerabilities Guide is useful here because the response pattern for actively exploited flaws should include compromise assessment, not just remediation. For browser exploitation, that usually means checking for unusual downloads, new persistence mechanisms, suspicious browser extensions, abnormal child processes, or signs that the endpoint was used to launch follow-on activity.

If a browser is the initial access point, the blast radius can extend beyond the browser itself. Saved sessions, cookies, and credentials may remain valid after the browser process is closed, so incident response should consider whether credential rotation or session invalidation is needed when compromise indicators are present.

For a broader view of how attackers chain stolen access, session abuse, and lateral movement after initial compromise, the State of NHI & AI Agent Breach Report 2026 provides useful breach-pattern context.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Actively exploited browser CVEs require fast exposure identification and validation.
	SI-2 — Flaw Remediation	The question is about urgent remediation of an actively exploited software flaw.
Recommendation — Prioritise exposed Firefox installs and verify remediation status immediately. Accelerate patching or mitigation for the affected browser across the fleet.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Confirmed exploitation makes vulnerability prioritisation and remediation a core operational control.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Browser hardening and policy enforcement materially reduce exposure while remediation completes.
Recommendation — Use exploit-confirmation to move the CVE to the front of remediation queues. Enforce managed browser configuration and restrict risky browser settings.
MITRE ATT&CK	T1189 — Drive-by Compromise	Browser exploitation commonly occurs through malicious web content or crafted pages.
Recommendation — Hunt for drive-by delivery paths and suspicious browser-triggered activity.

Practitioner Guidance

What to prioritise: Treat confirmed exploitation as an emergency exposure problem. Patch or isolate affected browsers first, then verify which users, endpoints, and browser channels remain exposed before moving on to longer-term hardening.

What to verify: Confirm that remediation is actually present on the device, not merely approved in tooling. For browser CVEs, local version drift, delayed restarts, unmanaged endpoints, and policy exceptions are the most common reasons exposure persists after a fix is available.

Decision rule: If you cannot complete patching immediately, reduce the reachable attack surface with temporary controls such as access restriction, browser isolation, tighter extension governance, or user-workflow changes until the vulnerable population is cleared.

Practitioner takeaway: Once a browser vulnerability is known to be exploited in the wild, the question shifts from “is it dangerous?” to “what is still reachable right now?” The right response is fast exposure reduction plus targeted compromise checking, not patching in isolation.