Daily Cybersecurity News – September 10, 2026

What happened

Proofpoint researchers observed at least four China-aligned espionage groups rapidly chaining three zero-day vulnerabilities in a campaign called BlueMoon starting late August 2026.

TA412 (Violet Typhoon/APT31) struck first on August 28, followed by at least three other groups in subsequent waves. The chain combines two remote code execution flaws in Chromium's V8 JavaScript engine (CVE-2026-85046 and CVE-2026-87491) that allow code execution inside the browser sandbox via crafted HTML, plus a Windows ALPC privilege-escalation flaw (CVE-2026-85880) that elevates to system privileges.

All three were exploited before public patches. Attackers reverse-engineered Chromium source patches to weaponize the browser bugs during the gap. Delivery used same-day or near-day infrastructure, often via phishing lures that installed a malicious browser extension disguised as Google Gemini for surveillance, credential theft, and command execution. Activity continued at least through September 8 and peaked around the Chrome patch window.

Who is affected

Organizations and individuals running unpatched Chromium-based browsers (Chrome and others prior to the relevant 152/153 updates) on Windows systems vulnerable to the ALPC issue.

Proofpoint saw targeting of non-governmental organizations, mining companies, and commodity trading firms in the United States, with a relatively narrow pool exposed to the full chain. Broader Chromium and Windows user bases remain at risk until fully patched. Scale is limited by the need for all three flaws but expanding as more groups adopt the kit.

Why it matters

State-aligned actors moved from zero-day discovery to multi-group exploitation in days, compressing defender response windows. Full chain yields sandbox escape plus SYSTEM-level access, enabling persistent espionage, data theft, and further lateral movement.

Builders and operators face heightened risk from sophisticated, coordinated campaigns that weaponize public patch diffs before vendor releases reach endpoints. This pattern signals that reverse-engineering of open Chromium fixes is now a reliable attacker technique.

How it could have been prevented

Update Google Chrome and other Chromium-based browsers immediately to 153.0.8010.36 or later (and corresponding prior fixes for CVE-2026-85046). Apply the Microsoft September 2026 Windows updates that address CVE-2026-85880.

Enforce rapid patch management for browsers and OS, restrict browser extension installs via policy, monitor for suspicious Gemini-like extensions, and use phishing-resistant authentication plus network controls that limit exploit delivery infrastructure. Prioritize CISA KEV-driven remediation for federal and high-value environments.

What happened

Google released Chrome updates patching 230 security issues, including CVE-2026-87491, an out-of-bounds write in the V8 JavaScript engine that was under active exploitation.

The flaw in versions prior to 153.0.8010.36 lets a remote attacker execute arbitrary code inside the sandbox via a crafted HTML page. Google stated it is aware an exploit exists in the wild. Researcher Jihyeon Jeong of Compsec Lab reported it on August 6 and received a $2,500 bounty. CISA added it to the Known Exploited Vulnerabilities catalog on September 9, 2026, with a September 23 deadline for federal agencies.

This brings Google's 2026 count of actively exploited Chrome zero-days to seven. The same update also fixed several critical WebGL and Cast issues.

Who is affected

Users of Google Chrome prior to 153.0.8010.36/.37 on Windows and macOS, and 153.0.8010.36 on Linux, plus other Chromium-based browsers (Edge, Brave, Opera, Vivaldi) until they ship equivalent fixes.

Hundreds of millions of browser installations worldwide are potentially exposed until updated. Federal Civilian Executive Branch agencies face a hard remediation deadline.

Why it matters

In-the-wild exploitation of a sandbox code-execution bug turns ordinary web browsing into an initial access vector. When chained with privilege-escalation flaws, it enables full device compromise without user interaction beyond visiting a page.

Operators must treat browser updates as emergency patches rather than routine ones, especially given the repeated zero-day cadence in Chrome this year.

How it could have been prevented

Update Chrome immediately via More > Help > About Google Chrome and relaunch. Confirm version 153.0.8010.36 or newer.

Apply corresponding updates to other Chromium browsers as soon as vendors release them. Enable automatic updates, consider enterprise browser management policies, and monitor CISA KEV for mandatory timelines. Defense-in-depth measures such as site isolation and reduced attack surface help limit impact.

What happened

Anonymous researcher Nightmare Eclipse released a proof-of-concept exploit called ShieldCrash immediately after Microsoft's September 2026 Patch Tuesday.

It bypasses the ShieldBreak elevation-of-privilege fix (CVE-2026-69414) in the Microsoft Malware Protection Engine. Under specific conditions the same underlying problem can still be triggered on fully patched Windows 10, Windows 11, and Windows Server systems, granting arbitrary file read as SYSTEM. The researcher noted it does not yet provide full write access but could be extended.

ShieldCrash continues a series of Defender and Windows component zero-days (RoguePlanet, LegacyHive, and others) published amid a public dispute over Microsoft's bug-bounty and disclosure practices. Several earlier flaws remain unpatched.

Who is affected

All currently supported Windows 10, Windows 11, and Windows Server installations running Microsoft Defender, even after the September 2026 cumulative updates.

Any environment relying on Defender as a primary endpoint protection layer is exposed to local privilege escalation once an attacker has initial code execution or the ability to trigger the engine.

Why it matters

A bypass that survives the latest Patch Tuesday undermines confidence in vendor fixes for security products themselves. SYSTEM-level file read enables credential dumping, configuration theft, and further privilege escalation paths.

Operators who assume "patched equals safe" face residual risk from incomplete remediations, especially when researchers publicly drop working exploits the same day updates ship.

How it could have been prevented

Apply the September 2026 Windows and Defender engine updates promptly, then monitor Microsoft advisories for any follow-up ShieldCrash-specific fix.

Layer additional endpoint detection and response (EDR) controls that do not solely rely on Defender's engine, enforce least privilege, enable attack-surface reduction rules, and restrict local code execution opportunities. Track Nightmare Eclipse disclosures for other unpatched issues still in the wild.

What happened

A cybersecurity startup developed WeWorm, a tool that compromises Android and iOS devices through a simple incoming WeChat call by exploiting a zero-click remote code execution vulnerability in WeChat's voice-over-IP stack.

Researchers at Calif identified the memory corruption issue with help from large language models. An attacker already on the victim's WeChat friend list can gain full control of the targeted account without the user answering or interacting; even declining the call fails to stop it. When chained with operating-system flaws, the tool can achieve full device control.

Tencent confirmed the vulnerability and released patched WeChat versions. The researchers highlighted that AI significantly accelerates creation of such sophisticated tools.

Who is affected

Users of unpatched WeChat on both Android and iOS whose accounts can receive calls from an attacker already present on their friend list.

WeChat's massive user base, particularly in regions where it is the dominant messaging platform, creates a large potential target surface until everyone updates.

Why it matters

Zero-click RCEs in widely used messaging apps turn a single incoming call into remote compromise with no user action required. Full account and potential device takeover enables surveillance, data theft, and further propagation.

The AI-assisted discovery and tooling development shortens the time from vulnerability to usable exploit, raising the bar for both vendors and defenders who must respond faster.

What happened

Cybercriminals are using information-stealer malware logs to harvest and replay authentication tokens for major AI services, creating "stolen keys" that grant direct account access while bypassing passwords and multi-factor authentication.

Okta analyzed a 7 GB stealer dump from a Telegram channel (released August 2, 2026) containing data from 5,871 infected machines across 162 countries. It included thousands of unexpired tokens for Google, Microsoft, Anthropic, Amazon, OpenAI (via NextAuth.js JWEs), Notion, Cursor, and other AI tools. Of 44,791 unique JWTs, 555 related to AI services; 1,843 JWTs and JWEs remained unexpired on release day. 17.7% of JWTs contained plaintext PII.

Stealers such as Lumma and Vidar routinely collect session tokens and API keys. Once replayed, the attacker is effectively logged in. IP allowlisting and emerging Device Bound Session Credentials can block some replays.

Who is affected

Users of AI platforms and related services (Google, Anthropic, OpenAI, Microsoft, Amazon, Notion, Cursor, Character.ai, and others) whose machines were infected by infostealers and whose tokens appeared in the dump or similar logs.

Any organization or individual relying on long-lived session tokens or API keys for LLM access without additional binding or short expiration is exposed. The underground market for stealer logs amplifies reach.

Why it matters

Token replay turns endpoint malware infections into immediate, MFA-bypassing access to high-value AI accounts and data. Stolen keys enable abuse of paid models, data exfiltration, prompt injection at scale, and further social engineering using embedded PII.

Builders of AI applications and identity systems must treat session tokens as high-value secrets equivalent to passwords, not convenient long-lived credentials.

How it could have been prevented

Force re-authentication and revoke existing sessions/tokens for AI services after any suspected infection. Prefer short-lived tokens, implement IP allowlisting or device-bound credentials (such as Chrome DBSC) where available, and monitor for anomalous AI API usage.

Deploy strong endpoint protection against stealers, use phishing-resistant MFA everywhere, avoid storing long-lived API keys on endpoints, and educate users never to reuse or expose tokens. Rotate keys regularly and audit stealer-log marketplaces for corporate exposures.

What happened

Security researchers and practitioners report that AI agents can turn a mere rumor or high-level description of a vulnerability into a working exploit in dramatically less time than traditional methods.

One observer noted that simply knowing roughly what a flaw was about allowed personal AI agents to locate and potentially exploit it well before a public patch. Simon Willison and others highlight that this speed appears incompatible with existing open-source embargo and coordinated disclosure practices.

The observation underscores a broader shift: AI equally accelerates both defensive discovery and offensive weaponization.

Who is affected

Open-source maintainers, software vendors, and any organization that relies on traditional vulnerability embargo windows or delayed public disclosure.

Defenders who previously counted on multi-week or multi-month gaps between private report and widespread exploit now face compressed timelines measured in hours or days.

Why it matters

When rumor alone is enough for AI-assisted exploit development, the classic coordinated-vulnerability-disclosure model breaks down. Attackers gain the same speed advantage as defenders, eroding the window for quiet patching.

Operators and builders must assume that any public hint of a bug can lead to rapid weaponization, requiring faster patch pipelines, better isolation, and revised disclosure norms for open-source ecosystems.

What happened

A database containing approximately 153 million driver's license records is being offered for sale on dark-web forums. Brian Krebs has published additional details on the listing and the underlying data set.

Sellers claimed continuous exfiltration into a private database for over a year. The data appears tied to services that scan or process identity documents, creating a large trove of government-issued ID information now circulating in criminal markets.

Who is affected

Roughly 153 million individuals whose driver's license data appears in the offered database, spanning multiple U.S. jurisdictions and potentially other regions.

Anyone who has used identity-scanning services, DMV-related platforms, or third-party verifiers that retained copies of licenses faces exposure. Downstream victims include financial institutions and services that rely on these IDs for verification.

Why it matters

Driver's licenses are primary identity documents used for account opening, age verification, travel, and government services. Mass availability fuels large-scale identity theft, synthetic identity fraud, and targeted social engineering.

The long-running exfiltration also illustrates the systemic risk of centralized ID-document repositories and the growing ease with which attackers (increasingly AI-assisted) can locate and empty them.

How it could have been prevented

Monitor credit and identity-theft services for misuse of personal details. Organizations that store scanned licenses should minimize retention, encrypt data at rest, apply strict access controls, and audit for unauthorized exfiltration.

Individuals should treat unsolicited requests for ID images with extreme caution, use official channels only, and consider freezes or alerts with credit bureaus. Prefer privacy-preserving identity verification methods where available.