Is CVE-2021-38003 (Google Chromium V8 Memory Corruption) being exploited in the wild?

Yes. CISA added CVE-2021-38003 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Google Chromium V8 Engine has a bug in JSON.stringify, where the internal TheHole value can leak to script code, causing memory corruption.

How KEV status answers the “exploited in the wild” question

For this CVE, the practical answer is not a guess based on a proof-of-concept or a researcher write-up. CISA’s Known Exploited Vulnerabilities catalogue is the strongest public signal that a flaw has credible evidence of active exploitation, so KEV inclusion changes the question from “could this be abused?” to “assume it is already being targeted and verify exposure quickly.”

That matters because browser and JavaScript engine flaws often have a short window between disclosure and broad abuse. If a fleet still runs vulnerable Chromium-based browsers, the issue is not only patch status, but also whether any endpoints may have been exposed long enough for exploit delivery, persistence, or follow-on credential theft to occur.

When teams are triaging actively exploited issues, the answer is best read alongside a vulnerability-management workflow that can separate internet-facing assets, managed browsers, and lagging endpoints from the rest of the estate. NHIMG’s Vulnerability Management Guide is useful here because it frames KEV as a prioritisation input, not a patching conclusion.

What to do if you may still be exposed

The first operational step is to confirm where Chromium versions are actually present, including managed desktops, VDI pools, virtualised browsers, embedded browser components, and any software that ships its own Chromium runtime. Do not assume a system browser inventory is enough, because packaged applications and thin clients can carry a separate affected engine.

If patching is already complete, verify that the fix truly landed everywhere and that no exception path left a subset of users exposed. If patching has not yet occurred, treat the issue as urgent and isolate the highest-risk users or workloads first, especially those that browse untrusted content or handle sensitive sessions.

When a flaw is already known to be exploited, an emergency response often has to balance rapid remediation with business continuity. NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is relevant because it emphasises KEV-driven triage, emergency mitigation, and post-patch hunting rather than waiting for a standard maintenance cycle.

If exposure may have persisted for days or weeks, look for signs of browser compromise, suspicious downloads, injected extensions, unexpected sign-ins, and unusual token use on adjacent systems. For browser-centric exposure, NHIMG’s Enterprise Browser and Browser Security Guide helps frame the assets that typically need inspection after an exploited browser flaw.

Why this CVE deserves post-exploitation checks, not just patching

A memory corruption bug in a browser engine is not only a crash risk. If exploitation succeeded before remediation, the likely concern is that the browser process, session state, or adjacent user context may have been affected, which means follow-on activity can survive after the vulnerable code is gone.

For that reason, remediation should be paired with compromise assessment on the endpoints that mattered most to the attacker. A browser exploit can be the entry point, but the real damage often comes from what it enables next, such as session theft, credential harvesting, malicious extension installation, or access to internal web apps from a trusted browser context.

That is why exploited browser issues should be treated as an access problem as much as a software defect. NHIMG’s The State of NHI & AI Agent Breach Report 2026 is not about Chromium specifically, but it is useful for understanding how attackers convert stolen access material into persistence and lateral movement after the initial foothold.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed browser flaws need urgent discovery and remediation prioritisation.
Recommendation — Prioritize and remediate KEV-listed browser vulnerabilities across all managed endpoints.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	This question hinges on confirming exposure to a known exploited vulnerability.
	RS.MA-01 — Incidents are contained	Actively exploited flaws require containment and rapid mitigation if compromise is suspected.
Recommendation — Identify affected Chromium assets and validate exposure before declaring remediation complete. Contain potentially affected endpoints and isolate systems until exposure is resolved.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Actively exploited CVEs require continuous identification and tracking of affected assets.
	SI-2 — Flaw Remediation	A KEV-listed flaw demands prompt remediation and verification across the fleet.
Recommendation — Scan for vulnerable Chromium versions and track remediation to closure. Remediate the Chromium flaw promptly and verify the fix across all affected systems.

Practitioner Guidance

What to verify: Confirm exact browser build coverage across managed and unmanaged endpoints, then check whether any exception, offline device, or packaged application left the vulnerable engine in place longer than expected.

Decision rule: If the affected browser or embedded Chromium runtime handled sensitive sessions before remediation, prioritise compromise assessment and session review alongside patching, not after it.

What to measure: Track time-to-remediate for the affected browser family, plus the percentage of endpoints that were verified rather than assumed patched.

Common mistake: Treating “browser updated” as sufficient without checking whether other applications bundle their own Chromium build or whether old sessions and tokens remain valid.

Practitioner takeaway: KEV listing means the question is no longer theoretical, the right response is to confirm exposure, eliminate the vulnerable build everywhere, and look for evidence that the browser was already used as an entry point.