Is CVE-2013-1675 (Mozilla Firefox Information Disclosure) being exploited in the wild?

Yes. CISA added CVE-2013-1675 to its Known Exploited Vulnerabilities catalogue on 3 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 does not properly initialize data structures for the nsDOMSVGZoomEvent::mPreviousScale and nsDOMSVGZoomEvent::mNewScale functions, which allows remote attackers to obtain sensitive information from process memory via a crafted web site.

What the CVE-2013-1675 KEV listing means operationally

The key point for practitioners is that CISA’s KEV listing is not a theoretical vulnerability note. It is a signal that exploitation has been observed and that the issue should be treated as an active exposure, not just a routine browser bug. For background on how KEV fits into vulnerability triage, see the CISA Known Exploited Vulnerabilities Catalog.

For this CVE, the practical question is whether any Firefox instances, embedded browser components, or legacy endpoints remain in service where the vulnerable code path could still be reached. If the affected browser is present anywhere in your fleet, assume priority review rather than deferred maintenance, because KEV status changes the remediation urgency even when the product looks old or uncommon.

When teams need to decide how to handle an actively exploited browser flaw, the most useful external references are the authoritative vulnerability records themselves. Use the NIST National Vulnerability Database for record context and the CVE Program for the canonical identifier and vulnerability record structure.

What exposure to check first

Start with asset visibility, not incident speculation. Confirm where Firefox is installed, whether it is user-managed or centrally managed, and whether any long-lived enterprise images, kiosk systems, VDI pools, or archived endpoints still carry the vulnerable build. A browser issue can linger in places that standard patch reporting misses, especially where software inventory is incomplete or browsers are bundled with another application.

Also check whether the vulnerable browser is used in contexts that increase impact if content is rendered from untrusted websites, external portals, or embedded web views. The direct answer indicates a crafted website can trigger sensitive information disclosure from process memory, so exposure is about reachable attack surface, not just browser versioning. On the internal side, the Enterprise Browser and Browser Security Guide is useful when you need to review browser hardening, extension control, isolation, and browser policy settings together.

If you are running a vulnerability program, treat KEV-listed browser issues as a separate decision class from ordinary findings. The Vulnerability Management Guide is the most relevant internal reference for prioritisation, exception handling, and verification when exploitation evidence changes the remediation threshold.

How to respond when patching or replacement is delayed

If you cannot remove exposure immediately, the best short-term response is to reduce reachable attack paths and shrink the number of users or systems that can hit the vulnerable browser path. That usually means temporary isolation, tighter web access control, and heightened monitoring around systems that must remain on the old build. The goal is to lower practical exploitability, not to assume that compensating controls fully neutralise the issue.

For a legacy browser flaw, delay should be treated as a bounded exception with an owner and a time limit. If the system is internet-facing or used by high-value users, the exception bar should be much higher than for a non-production or isolated workstation. For this kind of active exploitation signal, the internal Zero-Day and Exploited Vulnerabilities Guide is the best fit for emergency mitigation, hotpatching, and post-patch hunting decisions.

Where browser hardening is available, use it to reduce the chance that process memory exposure becomes a broader compromise. That means reviewing extension exposure, browser isolation options, and credential handling in the browser itself, especially if the same workstation is used for sensitive administrative or business access. The browser security guide is the strongest internal match for those containment decisions.

Standards & Framework Alignment

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

NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	DE.CM-01 — Monitored environment	Actively exploited CVEs require continuous monitoring for exposure and suspicious activity.
	ID.RA-01 — Asset vulnerabilities identified and recorded	A KEV-listed CVE demands identification of where the vulnerable browser still exists.
	PR.IP-12 — Vulnerability management plan implemented	The response depends on prioritising KEV-listed vulnerabilities for remediation or containment.
Recommendation — Monitor exposed browsers and investigate signs of exploitation promptly. Identify all affected Firefox installations and document their exposure. Prioritise KEV-listed browser flaws in your vulnerability management process.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This CVE requires finding exposed systems and tracking remediation status.
	SI-2 — Flaw Remediation	An actively exploited browser vulnerability requires timely fix deployment or mitigation.
Recommendation — Scan for vulnerable Firefox instances and track remediation to closure. Apply vendor fixes or compensating mitigations without delay.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV status makes prioritised vulnerability handling central to the response.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Browser hardening and policy controls help reduce exposure while remediation is pending.
Recommendation — Prioritise and remediate the exploited Firefox vulnerability immediately. Harden browser configuration and reduce exposure until patching is complete.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	Actively exploited browser flaws fall under vulnerability handling and remediation governance.
Recommendation — Track the vulnerability, assign an owner, and remediate or mitigate it.
OWASP ASVS	V16 — Security Logging and Error Handling	If exploitation is suspected, logging and evidence retention help confirm compromise.
Recommendation — Preserve browser and endpoint logs needed to validate or rule out abuse.

Practitioner Guidance

What to prioritise: Treat the KEV listing as the remediation trigger, then verify whether any live endpoint still runs the vulnerable Firefox branch or an embedded component that exposes the same code path. The relevant question is reachability, not whether the browser is “mostly” patched.

What to verify: Confirm inventory, exposure window, and whether the browser is used to access high-value accounts or sensitive internal services. If the same workstation can reach privileged portals, the priority is higher because browser memory disclosure can become a stepping stone to broader compromise.

Decision rule: If the vulnerable browser cannot be patched immediately, isolate it from untrusted browsing, constrain who can use it, and record the exception with an expiry date. If you cannot bound usage, the exception is too risky to leave open.

Practitioner takeaway: Active exploitation changes the question from “is there a bug?” to “where is the exposure still reachable, and how quickly can we remove or contain it?”