Yes. CISA added CVE-2019-5786 to its Known Exploited Vulnerabilities catalogue on 23 May 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Google Chrome Blink contains a heap use-after-free vulnerability that allows an attacker to potentially perform out of bounds memory access via a crafted HTML page.
What “being exploited in the wild” means for this CVE
CISA’s KEV listing is the practical signal that matters here. For the CISA Known Exploited Vulnerabilities Catalog, inclusion means there is reliable evidence of active exploitation, so the question is not whether the flaw is theoretically dangerous, but whether defenders should treat it as an active exposure requiring immediate attention.
For browser bugs like this one, “in the wild” typically means exploitation through ordinary web traffic, not a specialty implant or privileged access path. That makes exposure broad, because a crafted page can be enough to trigger the vulnerable code path when a user visits it.
Chrome users, endpoint teams, and vulnerability responders should also treat the vendor advisory and the NIST National Vulnerability Database as the records of reference for product context and lifecycle tracking, while relying on CISA for exploited-status prioritisation.
Why a Blink use-after-free becomes a high-priority browser exposure
A heap use-after-free in browser rendering is dangerous because the browser processes attacker-controlled content at scale and with high privilege over local user data and session state. In practical terms, this kind of bug can cross from a page render failure into memory corruption, which is why browser memory-safety flaws so often become urgent patch items.
The important operational point is that exploitability is often easier than defenders expect. If an attacker can deliver a malicious HTML page or otherwise influence rendering, the browser becomes the execution environment, and the user’s normal browsing behaviour becomes the attack delivery mechanism.
The underlying weakness is the class, not just this CVE. Teams that want a broader view of how memory-safety flaws map to dangerous software weakness patterns should use the CWE Top 25 Guide alongside browser hardening work, because use-after-free issues are part of the same family of memory-corruption risks that attackers routinely weaponise.
How to respond when patching cannot wait
The first priority is exposure reduction, not deep forensics. If the browser is still present on endpoints, focus on narrowing who can reach it, where it is used, and whether high-risk browsing is isolated from ordinary user activity. For a browser-specific control perspective, the Enterprise Browser and Browser Security Guide is directly useful for policy hardening, extension control, isolation, and reducing the blast radius of browser-based attacks.
Where patching must wait, the practical fallback is containment. Use browser isolation, restrict untrusted browsing on sensitive endpoints, and treat unknown or unreviewed web content as a likely delivery path. If the browser is a shared enterprise tool, the residual risk is not just exploitation, but the speed at which a successful memory corruption bug can become a foothold for session theft or later-stage malware.
For prioritisation discipline, the right response is to combine active-exploitation status with your own asset exposure and remediation workflow. The Zero-Day and Exploited Vulnerabilities Guide is a good match for deciding when to escalate, when to emergency-mitigate, and when to treat a browser flaw as a same-day action item rather than a normal patch ticket.
Risk and Threat Considerations
Browser exploitation is especially risky because the attack surface is large, the delivery path is common, and the victim often only needs to open a page. When a browser memory bug is actively exploited, the main concern is not just crash potential, but whether the exploit chain can be extended into code execution, session theft, or follow-on compromise.
Failure mechanism: A use-after-free can let attacker-controlled input reuse freed memory, corrupting browser state and sometimes creating conditions for arbitrary memory access or code execution.
Impact: The practical impact can include endpoint compromise, browser session abuse, and rapid scaling of attacks against users who have not yet patched.
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 | Actively exploited CVEs require rapid identification and remediation of exposed assets. |
| Recommendation — Prioritise and remediate the affected browser across the asset inventory using continuous vulnerability management. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | This question hinges on confirming exposure to a known exploited vulnerability. |
| PR.PS-03 — Vulnerability exploitation is prevented | Actively exploited browser flaws require preventive hardening and prompt remediation. | |
| Recommendation — Identify exposed endpoints and document the browser vulnerability in the risk register. Apply updated browser builds and containment controls to prevent exploitation. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | An exploited browser CVE requires timely remediation and verification of fixes. |
| RA-5 — Vulnerability Monitoring and Scanning | Confirming exposure and tracking KEV-listed flaws depends on vulnerability monitoring. | |
| Recommendation — Patch the vulnerable browser promptly and verify remediation across affected endpoints. Continuously scan for the vulnerable browser version and track KEV-listed exposure. | ||
Practitioner Guidance
What to verify: Confirm which endpoints still run affected Chrome builds, whether browser auto-update is functioning, and whether users can reach the browser from high-risk or unmanaged contexts. If you cannot prove those three things quickly, assume exposure remains.
Decision rule: If the browser is exposed on business-critical systems, treat the issue as a priority patch-and-verify event; if patching is delayed, move risky browsing into isolation or a constrained profile instead of relying on user caution.
Practitioner takeaway: For an actively exploited browser CVE, the right question is not “can attackers use it,” but “how quickly can we reduce reachability, confirm patch state, and look for signs of prior abuse before the next browsing session.”
Related resources from NHI Mgmt Group
- CVE-2019-5786 (Google Chrome Blink Use-After-Free)
- Is CVE-2022-3038 (Google Chromium Network Service Use-After-Free) being exploited in the wild?
- Is CVE-2024-4671 (Google Chromium Visuals Use-After-Free) being exploited in the wild?
- Is CVE-2019-8605 (Apple Multiple Products Use-After-Free) being exploited in the wild?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org