Google has patched CVE-2026-85046, a high-severity type-confusion vulnerability in the V8 JavaScript and WebAssembly engine, and says an exploit exists in the wild. The fixed desktop versions are 152.0.7977.82/.83 for Windows and macOS and 152.0.7977.82 for Linux. Google's September 3 update contains twelve security fixes.
The confirmed public description is deliberately narrow: a remote attacker can use a crafted HTML page to execute arbitrary code inside Chrome's sandbox. Google has not identified the attacker, targets, victim count, delivery path or a companion sandbox escape. That means active exploitation is confirmed, but complete device compromise and theft of browser-stored credentials are not confirmed outcomes of this CVE.
What Google and CISA confirm
Google's Stable Channel notice identifies CVE-2026-85046 as a high-severity V8 type confusion, credits researcher Salvatore Gulizia with reporting it on August 4 and states that an exploit exists in the wild. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on September 4, independently raising the remediation priority for organizations that use risk-based patching.
The Canadian Centre for Cyber Security and CERT-FR also issued current advisories pointing users to the patched Chrome builds. Newsrooms including BleepingComputer, SecurityWeek and Help Net Security corroborated the release and exploitation status, but they do not add a public victim list or a separate forensic account of the attacks.
Google may restrict bug details while the update reaches users and other affected projects. That is normal coordinated-disclosure practice. It is not evidence for speculative claims about who is using the exploit or what data they obtained.
For browser-delivered secrets, the endpoint is part of the channel
End-to-end or client-side encryption protects a value while it crosses systems that do not need to read it. The recipient's browser eventually must decrypt and display that value. At that moment the browser and device are part of the trusted computing base. A secure transport cannot make an untrusted endpoint safe.
CVE-2026-85046 does not prove that an attacker can read a Secretus page, escape Chrome's sandbox or access another origin. The practical lesson is more disciplined: when a browser vulnerability is being exploited, verify the patched build before using that browser for credential recovery, privileged administration or opening a one-time secret.
Patch the running browser, not the inventory record
- Check the exact running version. Chrome 152 alone is not enough; the relevant desktop floor is 152.0.7977.82, with .83 also listed for Windows and macOS.
- Complete the restart. An updater may download a build while existing browser processes continue to run the previous one.
- Verify managed fleets. Confirm version telemetry after rollout and identify devices that are offline, pinned, update-disabled or outside normal management.
- Update Chromium-based products through their own vendor channels. Do not assume Chrome's version number or package proves that a different browser or embedded runtime has received the same fix.
- Separate suspicion from confirmation. A vulnerable build establishes exposure, not compromise. Escalate based on evidence such as known malicious browsing, endpoint detections or vendor-provided indicators.
- Recover from a clean endpoint. If investigation indicates compromise, isolate the device and revoke reachable sessions before generating replacement credentials elsewhere.
Do not rotate secrets into the suspected browser
Incident response can make exposure worse when administrators reset passwords, mint API keys or display recovery codes on the same endpoint under investigation. First determine what identities and secrets the browser session could reach. Revoke active sessions and old credentials, create replacements on a known-clean managed system, and verify the recipient through a separate channel.
Keep the response ticket useful without turning it into a secret archive. Record the owner, scope, revocation time, approver and completion status, but do not paste the replacement value, recovery code or live one-time URL into the ticket or incident chat.
Where Secretus helps—and where it stops
Secretus can reduce persistent plaintext copies by encrypting a value in the sender's browser and delivering it through an expiring one-time workflow. That addresses transport and retention risk between verified parties. It does not patch Chrome, attest the device, remove malware or prevent code already running in the recipient's environment from seeing information after legitimate decryption.
The safe order is therefore endpoint verification, identity verification, narrowly scoped delivery and prompt revocation—not simply moving a credential into a different browser tab. For high-impact recovery, use a dedicated clean administrative device and confirm its browser build immediately before the handoff.
What remains unknown
Google has not disclosed the observed attack chain, targeted regions or sectors, successful victim count, exploit samples, indicators of compromise or whether CVE-2026-85046 was paired with another vulnerability. Public evidence does not support claims that this flaw alone escapes the sandbox, takes over an entire device or steals stored passwords. Those limits should remain explicit until Google or another primary investigator publishes more.
Sources
- Google Chrome Releases: fixed versions, vulnerability list and in-the-wild exploitation statement
- CISA: CVE-2026-85046 added to the Known Exploited Vulnerabilities catalog
- Canadian Centre for Cyber Security: affected version and update advisory
- Help Net Security: independent reporting on the patch and disclosure limits
- BleepingComputer: independent reporting on exploitation and fixed builds