Yes. CISA added CVE-2018-17480 to its Known Exploited Vulnerabilities catalogue on 8 June 2022, 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 contains out-of-bounds write vulnerability that allows a remote attacker to execute code inside a sandbox via a crafted HTML page.
What “being exploited in the wild” means for this CVE
For this issue, the key question is not whether the bug exists, it is whether defenders should treat it as an active exposure. Once CISA places a CVE in the Known Exploited Vulnerabilities catalog, the operational assumption changes: exposure is no longer theoretical, and prioritisation should move from normal backlog handling to response-oriented triage.
That matters because an out-of-bounds write in a browser engine can be reachable through ordinary web content, which makes the attack surface broad and hard to police by user behaviour alone. For confirmation and tracking, use the CISA Known Exploited Vulnerabilities Catalog and the NIST National Vulnerability Database as the authoritative sources for record details and prioritisation context.
When a browser flaw is already exploited, the practical concern is not only code execution in the browser process, but also whether that initial execution can be chained into credential theft, session abuse, or lateral movement if the browser is trusted too broadly inside the environment.
Why browser-engine memory corruption is high-value to attackers
Browser engines sit at the junction of untrusted content and high-trust user activity. A memory corruption flaw such as an out-of-bounds write can give an attacker a reliable route from a crafted page to code execution inside the browser sandbox, which is often enough to launch a second-stage exploit, steal data from the session, or trigger a broader compromise chain.
That is why active exploitation of browser engine bugs is especially important in enterprise environments where the browser is a primary access path to SaaS, admin portals, and internal apps. A single successful exploit can become a springboard into authenticated sessions, cached tokens, or privileged workflows if the endpoint is poorly isolated or insufficiently monitored.
For broader context on how exploitation trends are tracked and why exploitability drives urgency, see the FIRST EPSS model and the CVE Program record structure that underpins vulnerability identification.
What to do while patching and validation are underway
For exploited browser issues, the correct response is to verify exposure, apply the vendor fix as soon as it is available, and shorten the time the vulnerable build remains in production. If patching cannot happen immediately, reduce exposure by limiting browser reach to untrusted content, tightening extension control, and isolating high-risk browsing from business-critical workflows.
If there is any sign the flaw may have been exercised before remediation, treat the endpoint as a potential compromise point, not just a patching task. Review browser crash telemetry, suspicious downloads, anomalous script execution, and unusual post-browser activity, then decide whether session revocation, credential rotation, or endpoint reimaging is warranted based on the blast radius.
The most useful operational reference is Zero-Day and Exploited Vulnerabilities Guide, which aligns well with KEV-driven triage, emergency mitigation, and post-patch hunting. For browser-specific hardening and isolation choices, Enterprise Browser and Browser Security Guide is the more relevant internal reference.
Risk and Threat Considerations
Once a browser engine weakness is known to be actively exploited, the main risk is that untrusted web content becomes a reliable delivery path for initial execution. That can bypass user awareness controls because the trigger is a normal browsing action, not an obviously malicious file transfer or login prompt.
Failure mechanism: The attacker supplies crafted HTML or script content that triggers memory corruption in the browser engine, then uses the resulting code execution to continue the attack from inside the user’s browser context or sandbox boundary.
Impact: The likely outcomes are session theft, payload delivery, privilege abuse through the user’s authenticated browser state, and further compromise if the endpoint or browser session has access to sensitive internal resources.
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 CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS 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 prioritisation. |
| Recommendation — Prioritise and remediate KEV-listed vulnerabilities first. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | KEV status changes remediation priority and response timing for the organisation. |
| Recommendation — Escalate KEV-listed browser flaws into risk-based remediation workflows. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Actively exploited software flaws require timely patching and mitigation. |
| Recommendation — Apply fixes or mitigations quickly for software flaws with active exploitation. | ||
| MITRE ATT&CK | T1203 — Exploitation for Client Execution | A crafted web page triggering browser-engine execution matches client-side exploitation. |
| Recommendation — Map browser exploitation indicators to client-execution detections and hunting. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | Post-exploitation validation depends on logs and telemetry from browser-related failures. |
| Recommendation — Retain and review security logs that reveal exploitation attempts or crash patterns. | ||
Practitioner Guidance
What to prioritise: Treat KEV inclusion as a timing signal, not a scoring exercise. If the affected browser version is present on endpoints that access email, SaaS, admin consoles, or developer tooling, move those assets to the front of the remediation queue.
What to verify: Confirm whether the browser is managed, auto-updating, or running in a hardened configuration with isolation and extension controls. If you cannot prove those controls are in place, assume the exposure window is larger than the patch window.
Decision rule: If there are signs of pre-patch exploitation, investigate compromise before or alongside patching. If not, patch first, then hunt for signs of abuse so you do not miss a short-lived intrusion that happened before remediation.
Practitioner takeaway: For an actively exploited browser CVE, the real control objective is to reduce the attacker’s time-to-impact, because the browser is both the delivery mechanism and the access gateway.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2018-17480 (Google Chromium V8 Out-of-Bounds Write)?
- Is CVE-2025-5419 (Google Chromium V8 Out-of-Bounds Read and Write) being exploited in the wild?
- Is CVE-2024-4761 (Google Chromium V8 Out-of-Bounds Memory Write) being exploited in the wild?
- Is CVE-2019-5825 (Google Chromium V8 Out-of-Bounds Write) 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