By NHI Mgmt Group Editorial TeamDomain: Breaches & IncidentsSource: AnomaliPublished November 25, 2025

TL;DR: A high-severity Chrome zero-day, CVE-2025-13223, is being actively exploited through malicious websites to trigger heap corruption and execute arbitrary code after a crafted page loads, with Google shipping fixed builds for affected versions, according to Anomali. Browser patching now sits on the identity and access boundary, because session capture and drive-by execution can bypass user judgment faster than most control loops can react.


At a glance

What this is: Anomali reports active exploitation of a Chrome zero-day that enables arbitrary code execution through malicious websites.

Why it matters: For IAM and security teams, browser exploitation can become an identity problem when it is used to steal sessions, bypass sign-in protections, or seed later credential abuse.

By the numbers:

👉 Read Anomali's Cyber Watch roundup on Chrome zero-day exploitation and related threats


Context

Chrome zero-days are not just browser patching issues. When exploitation can start from a crafted website and require no further user interaction, the browser becomes a fast-moving entry point that can feed session theft, downstream malware delivery, or credential harvesting.

That matters to identity programmes because the first reliable signal is often not a failed login but an unusual session, token, or device event after the browser has already been compromised. In practice, browser hygiene, session telemetry, and identity monitoring now overlap more than many programmes assume.

The pattern also fits broader NHI and IAM risk: a compromised endpoint can expose secrets, tokens, and active sessions that are later abused outside the original browser context.


Key questions

Q: How should security teams respond to browser zero-day exploitation in identity-heavy environments?

A: Treat browser exploitation as both an endpoint and identity event. Confirm patch status, then look for anomalous sessions, token use, and device posture changes that indicate the exploit reached beyond the browser. If privileged access flows depend on the browser, shorten session lifetime and require reauthentication for high-risk actions.

Q: Why do browser security decisions matter for IAM teams?

A: Because the browser is where users enter credentials, approve OAuth grants, and reuse sessions, so it has become an identity control surface. IAM teams need visibility into that layer to reduce credential theft, session abuse, and unauthorized access that bypasses traditional perimeter controls.

Q: What breaks when browser patching is treated separately from identity monitoring?

A: The response window stretches. Endpoint teams may confirm the browser is fixed while attackers continue using stolen sessions or tokens elsewhere. Without identity telemetry, the organisation can miss the part of the attack that matters most: whether the exploit produced usable access.

Q: How can organisations reduce the impact of drive-by browser exploitation?

A: Reduce the value of a compromised browser by tightening session controls, enforcing conditional access, and revoking tokens quickly when compromise is suspected. Combine those measures with aggressive update enforcement and device segmentation for users who access sensitive systems through the browser.


Technical breakdown

Drive-by exploitation in the browser engine

The article describes a type-confusion flaw in Chrome’s V8 JavaScript engine, a bug class where memory objects are misinterpreted during execution. That can lead to heap corruption, which attackers then turn into code execution after a user loads a crafted page. Because the exploit is triggered through normal browsing, the initial access path blends into routine web traffic and can evade controls that focus only on downloaded files or obvious phishing attachments.

Practical implication: treat browser patching as a front-line control and verify that fleet-wide auto-update enforcement is real, not assumed.

Why no extra click changes the defensive model

No additional interaction means the exploit chain does not depend on credential entry or a second-stage prompt. That removes some human friction points that security teams often rely on, such as recognizing a suspicious attachment or rejecting a login form. The control problem shifts from user awareness to execution timing, browser version state, and post-compromise telemetry, especially when the browser is used as the first step in a broader intrusion chain.

Practical implication: monitor for browser-version drift and pair endpoint alerts with identity signals that reveal what happened after the page load.

Browser compromise and identity telemetry

Browser exploitation matters to identity security because modern access often terminates in the browser, where session cookies, tokens, and SSO artifacts live. Once the browser is compromised, attackers may not need to steal a password at all. They can pivot into active sessions, use stolen tokens, or launch follow-on phishing from a trusted device context. That makes browser events, session creation, and token use more relevant to IAM teams than the exploit headline itself.

Practical implication: correlate browser compromise indicators with anomalous session activity and token use to shorten dwell time.


Threat narrative

Attacker objective: The attacker wants reliable code execution from a trusted browser context so they can move into session theft, payload delivery, or follow-on compromise.

  1. Entry occurs when a victim loads a malicious website that triggers the Chrome V8 type-confusion flaw without needing further interaction.
  2. Escalation follows when heap corruption is converted into arbitrary code execution inside the browser process.
  3. Impact is achieved when attackers use the compromised browser context to deliver payloads, steal sessions, or seed broader identity abuse.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Browser compromise is now an identity issue, not just an endpoint issue. The article shows how a drive-by browser exploit can become the first step in session theft, token abuse, or downstream credential capture. Once access is mediated through the browser, IAM teams have to watch for the post-exploit identity artefacts rather than only the exploit itself. The practitioner conclusion is simple: browser compromise belongs in identity risk review.

Drive-by compromise is a runtime trust failure. The security model assumes the browser executes web content safely until the user does something obviously risky. That assumption fails when a crafted page can trigger memory corruption and code execution without a second click. The implication is not just faster patching, but a reevaluation of which runtime trust boundaries the browser still deserves in modern access paths.

Identity blast radius expands when browsers carry session state. Browser cookies, tokens, and SSO artifacts turn a single endpoint compromise into a wider access problem. That is why browser patching, session telemetry, and token monitoring now need to be treated as one control plane. Practitioners should think in terms of how far one compromised browser can extend an account’s effective reach.

Chrome zero-days expose the gap between endpoint control and identity control. Security teams often measure success by whether the endpoint was patched, yet the meaningful outcome is whether the attacker gained a usable session or token. That distinction matters because identity programmes still tend to certify access states, not ephemeral browser runtime conditions. The practitioner conclusion is to align identity monitoring with endpoint exploit intelligence.

From our research:

  • The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
  • 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
  • For related NHI threat patterns, see The 52 NHI breaches Report for breach cases that show how fast identity abuse compounds once credentials or sessions are exposed.

What this signals

Browser exploitation now intersects with identity governance because the browser is where sessions live. Teams that still separate endpoint hygiene from access control will miss the point of drive-by compromise. The practical shift is to treat browser state, token use, and device trust as a single control problem, especially for users with privileged access.

The next maturity step is not more alert volume. It is faster correlation between exploit telemetry and the identity events that follow it, so session misuse can be contained before the attacker moves from browser compromise into broader access abuse.

Identity blast radius is the useful concept here: a single compromised browser can extend far beyond the page that triggered the exploit, especially when SSO and cloud sessions are already active. Practitioners should map which business functions would be exposed if browser session state were lost, then build controls around that exposure rather than around the exploit alone.


For practitioners

  • Enforce browser update compliance Verify that Chrome auto-update is enabled on every managed device and check for version drift against the fixed builds named in the advisory. Prioritise devices that regularly access SSO portals, admin consoles, or cloud dashboards because those browsers carry the highest identity value.
  • Correlate browser compromise with identity telemetry Join endpoint detections with session creation logs, token use, and device posture events so a suspicious browser exploit can be evaluated as an identity event, not just malware execution. Look for new sessions that do not match a legitimate sign-in pattern.
  • Review high-value browser workloads Map which users and service operators rely on browser-based access for privileged actions, then tighten session lifetime, reauthentication, and conditional access checks for those flows. The goal is to reduce the usefulness of any compromised browser session.
  • Test rapid containment for drive-by compromise Run tabletop exercises for a browser zero-day in which the first sign is an anomalous session rather than a malware alert. Include isolation, token revocation, and browser fleet validation in the response sequence.

Key takeaways

  • A drive-by Chrome zero-day becomes an identity problem as soon as the browser carries active sessions, tokens, or SSO state.
  • The defensive gap is not only patch latency. It is the time between browser compromise and the first identity signal that reveals usable access.
  • Teams should link browser update enforcement, session monitoring, and token revocation so one compromised page does not become a wider access event.

Standards & Framework Alignment

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

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

FrameworkControl / ReferenceRelevance
MITRE ATT&CKTA0001 , Initial Access; TA0002 , ExecutionThe article centers on drive-by browser exploitation and code execution.
NIST CSF 2.0PR.AC-4Session and access control are the main identity impacts of browser compromise.
NIST SP 800-53 Rev 5SI-3The issue is active exploitation of a software flaw in a widely used client application.
CIS Controls v8CIS-7 , Continuous Vulnerability ManagementRapid patching is central because the flaw is being actively exploited.

Map browser zero-day exposure to initial access and execution detections, then prioritize containment around compromised sessions.


Key terms

  • Drive-By Compromise: A compromise that occurs when a user visits a malicious or compromised website and code executes without the victim deliberately running a file. In identity-heavy environments, the important question is not just infection, but whether the browser’s session state or tokens can be abused after execution.
  • OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
  • Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full analysis

Anomali's full post covers the operational detail this analysis intentionally leaves for the source:

  • MITRE ATT&CK mapping for each campaign, including the browser exploit, phishing kit, malware, and ransomware items in the roundup.
  • Vendor and analyst commentary on why defenders should expect more browser exploitation and token theft activity.
  • Short-form technical descriptions of the other threats mentioned in the roundup, including Sneaky 2FA, DigitStealer, and BadAudio.
  • Direct comparison of the incident set across drive-by compromise, phishing, infostealer, and espionage patterns.

👉 Anomali's full Cyber Watch post covers the other campaigns, MITRE mapping, and analyst commentary in one place.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org