TL;DR: CVE-2025-13223 is an actively exploited Chrome and Chromium zero-day on Windows, macOS, and Linux that can trigger memory corruption through a malicious webpage, according to Wazuh’s analysis. The case shows how browser exposure has become an enterprise access issue, not just an endpoint patching issue.
At a glance
What this is: Wazuh says CVE-2025-13223 is an actively exploited Chrome and Chromium zero-day that can corrupt memory when a user loads a malicious webpage.
Why it matters: It matters because browser exploitation now reaches the same risk tier as endpoint compromise for teams that rely on Chromium-based browsers for access, work, and cloud sessions.
Context
A browser zero-day is a flaw that attackers can exploit before normal patching cycles close the window. In this case, the weakness sits in Chrome and Chromium’s V8 engine, so the issue is not just a browser bug but an access-path problem for users reaching business apps and cloud services through the browser.
The article shows why browser patching has become a governance issue as much as an endpoint issue. When a malicious webpage can trigger memory corruption without extra interaction, organisations need visibility into browser version drift, exploit exposure, and remediation speed across managed endpoints.
Key questions
Q: What breaks when Chrome or Chromium stays on a vulnerable version after a zero-day is disclosed?
A: The browser becomes an exploitable entry point instead of a trusted access layer. A malicious webpage can trigger memory corruption before routine patching catches up, which means the organisation is relying on a known-bad version for normal work, SaaS access, and administrative browsing.
A: Because the attacker has a working exploit before most organisations finish their standard update cycle. Once public exploitation is underway, the risk is immediate and the control objective becomes reducing exposure faster than threat actors can scale it, not simply applying the next scheduled patch.
Q: How do security teams know whether browser zero-day controls are actually working?
A: They should look for verified version coverage, vulnerability scan closure, and removal of active exposure alerts across all managed endpoints. If affected Chrome or Chromium versions still appear in inventory after remediation, the control is not working, even if patch tickets are closed.
Q: What should organisations do when browser access is used for business apps and cloud services?
A: They should manage browser versions as part of access governance, not as a desktop afterthought. When the browser is the session layer for critical work, vulnerable versions can undermine trust in the access path, so remediation, inventory, and monitoring need to sit inside the same operational process.
Technical breakdown
How V8 memory corruption turns a webpage into code execution
The flaw is described as improper handling of object types inside V8, the JavaScript and WebAssembly engine used by Chromium-based browsers. When a malicious page is loaded, the engine can corrupt heap memory, which may destabilise process execution and give an attacker a path toward arbitrary code execution. This is a classic browser-engine failure mode: the content renderer is also a code execution boundary, so a parsing or type-handling bug can become a remote attack surface. In practice, the browser sandbox reduces but does not erase the risk because successful exploitation starts inside a trusted application boundary.
Practical implication: treat browser engines as exploitable code execution surfaces, not just user-facing applications.
Why actively exploited zero-days outpace routine patch windows
A zero-day is dangerous because defenders have no advance patch cycle to rely on, and active exploitation means threat actors can weaponise the flaw before broad remediation lands. In this case, the attack requires only that a user visit a specially crafted HTML page, which lowers attacker cost and increases scale. That combination is especially problematic in organisations where browser access is the entry point to SaaS, admin portals, and internal apps. The vulnerability therefore behaves like a front-door compromise opportunity rather than a conventional endpoint defect.
Practical implication: prioritise emergency browser updates and exposure triage when exploitation is already in the wild.
Why browser inventory and version drift determine exposure
Detection depends on knowing which endpoints run affected Chrome or Chromium versions. Wazuh’s approach combines software inventory with vulnerability matching, which is important because browser risk is often hidden inside general endpoint management. If inventory data is stale, organisations can believe they are patched when vulnerable versions remain installed on workstations or servers. This is why browser governance intersects with identity and access programmes: the browser is now a primary session layer for authenticated work, so unmanaged versions can undermine trust in the access path even when credentials themselves remain intact.
Practical implication: maintain continuous browser inventory and vulnerability matching across all managed endpoints.
Threat narrative
Attacker objective: The attacker aims to execute code on the victim endpoint through a malicious webpage and use the browser as the initial foothold.
- Entry occurs when a victim loads a specially crafted HTML page in Chrome or Chromium.
- The page triggers a V8 object-type handling flaw that causes heap corruption inside the browser process.
- A successful exploit can enable arbitrary code execution on the endpoint and convert browser access into system compromise.
Breaches seen in the wild
- Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Browser exploitation has become an access-governance problem, not just a patching problem. When users reach business systems through the browser, an actively exploited browser zero-day threatens the integrity of the session layer itself. That shifts the governance question from whether endpoints are patched eventually to whether browser exposure is continuously known and controlled. Practitioners should treat the browser as part of identity assurance and access trust.
Exposure visibility is the decisive control gap in browser zero-day response. Organisations cannot remediate what they cannot see, and version drift across Windows, macOS, and Linux makes manual assurance unreliable. The most important failure mode here is not merely vulnerable code, but incomplete inventory of which endpoints still carry that code. Practitioners should close the browser visibility gap before the next zero-day lands.
Malicious webpage delivery makes user interaction the weakest link in the exploit chain. The article’s attack path does not depend on credential theft or privilege escalation at the outset; it depends on a normal browsing action. That means awareness training alone is insufficient if vulnerable browser versions remain deployed. Practitioners should align endpoint controls, browser update policy, and exploit detection around the same risk boundary.
Chrome and Chromium patch discipline now has the same operational weight as endpoint hardening. High-severity browser zero-days increasingly function as enterprise ingress points because modern work is browser-mediated. That makes the browser engine a governance domain in its own right, not a subordinate desktop concern. Practitioners should fold browser risk into their broader vulnerability and access governance model.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Top 10 NHI Issues
What this signals
Browser zero-days now sit inside the same operational risk envelope as endpoint compromise. The practical lesson for programmes is that patch management alone is too slow when exploitation begins through ordinary web content. Teams need continuous visibility into browser version drift and a response model that treats the browser as a managed attack surface, not a passive application.
Chromium exposure has a governance problem hidden inside it: the control only works when inventory is current. If version data lags, vulnerable builds persist after remediation appears complete. That makes browser inventory quality a direct determinant of security outcome, especially where browser sessions are the front door to cloud and admin systems.
For practitioners
- Enforce emergency browser update SLAs Set accelerated patch and verification targets for Chrome and Chromium when active exploitation is confirmed, and track completion by endpoint group rather than by general OS patch status.
- Build browser version inventory into vulnerability operations Use continuous software inventory to identify affected browser versions across Windows, macOS, Debian, and other managed endpoints before remediation depends on user reports.
- Verify exploit exposure with vulnerability detection alerts Correlate browser version data with vulnerability alerts so teams can see which endpoints remain on vulnerable releases and whether remediation has actually removed the risk.
- Treat browser access as part of identity assurance Review whether browser-mediated access to SaaS and admin portals is protected by the same monitoring and risk response expectations as other access paths.
Key takeaways
- Chrome and Chromium zero-days now create enterprise exposure through the browser session layer, not just through the endpoint itself.
- The article ties active exploitation to a high-severity flaw, showing that visibility and response speed matter as much as patch availability.
- Organisations need continuous browser inventory, rapid version validation, and exploit-aware remediation to limit the blast radius of browser-based attacks.
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 NIST CSF 2.0, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001;TA0006 — Initial Access; Credential Access | The article describes web-delivered exploitation leading to code execution on the endpoint. |
| Recommendation — Map browser-delivered exploitation to TA0001 and TA0006 to prioritise detection around malicious content and post-exploit activity. | ||
| NIST CSF 2.0 | DE.CM-01 — Network and Environment Monitoring | Continuous monitoring is needed to detect exposed browser versions and active exploitation. |
| Recommendation — Use DE.CM-01 to monitor endpoint software state and flag vulnerable browser builds before exploitation succeeds. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article is fundamentally about rapidly identifying and remediating an actively exploited browser flaw. |
| Recommendation — Apply CIS-7 to continuously identify and remediate vulnerable browser versions across managed endpoints. | ||
| OWASP ASVS | V12 — Secure Communication | The browser flaw affects the integrity of web-delivered content and the trust boundary around session access. |
| Recommendation — Use V12 as a reminder to harden browser-mediated access paths and validate secure delivery assumptions. | ||
Key terms
- Browser zero-day: A browser zero-day is a flaw in browser software that attackers can exploit before defenders have a patch widely deployed. In enterprise environments, it is especially dangerous because browsers sit in the path of authentication, cloud access, and everyday user activity.
- Heap Corruption: A memory-safety failure where data written by a program damages heap structures or adjacent objects. In security terms, it often causes crashes first and can sometimes be shaped into code execution. For front-door services, heap corruption is especially serious because it can destabilise or compromise the trust boundary.
- V8 Engine: V8 is the JavaScript and WebAssembly engine used by Chromium-based browsers to execute code inside web pages. Because it handles complex object parsing and execution logic, flaws in V8 can become high-impact browser vulnerabilities.
- Vulnerability Inventory: A vulnerability inventory is the current record of which assets, software versions, and configurations are exposed to known weaknesses. For browser risk, it is the difference between assuming patching happened and proving which endpoints are still vulnerable.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps security and identity practitioners align access controls, monitoring, and operational discipline across the systems their programmes depend on.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org