Google has linked four previously unknown browser vulnerabilities — two in Chrome, one in Safari's WebKit engine, and one in Internet Explorer — to targeted attack campaigns, with at least two government-backed threat groups among the exploit users. A commercial surveillance-software vendor is believed to have built three of the exploits, and all four flaws have since been patched. The findings landed alongside Google's count of 33 publicly disclosed zero-day exploits in the first half of 2021, already 11 more than the entire previous year.

Four flaws, three campaigns

Google security researchers Maddie Stone and Clement Lecigne described the activity in a blog post, framing it as the latest sign of escalating zero-day exploitation. The set breaks down into two Chrome renderer bugs, one WebKit bug, and one Internet Explorer bug. All were remotely reachable and all received fixes before the disclosure.

The commercial angle is central to Google's account. Investigators concluded that a seller of commercial surveillance software developed three of the four exploits. Those capabilities were then acquired and deployed by at least two state-sponsored groups — one of them Russian — before the affected vendors shipped patches.

The Chrome chain aimed at Armenia

Google found the first Chrome flaw, CVE-2021-21166, in February, and the second, CVE-2021-30551, in June. Both live in the Chrome renderer and allow remote code execution. In each case, the exploit was sent as a one-time link in an email to specific individuals, all located in Armenia.

Clicking the link took the target to a landing page built to fingerprint the machine. It collected details such as screen resolution, time zone, language settings, and installed browser plug-ins, then encrypted that profile and shipped it back to the operators' control server. That first pass let the attackers judge whether a visitor was interesting enough to justify the next stage. Google also observed an intermediate step in which the exploit chain gathered additional host data, including the CPU and OS version along with CPU and BIOS details.

While analyzing CVE-2021-21166, Google determined that the same vulnerable code existed in components shared with Apple's WebKit engine as used on iOS — the bridge that connects the Chrome research to the Safari-side flaw.

WebKit, credential theft, and a SolarWinds-linked actor

The WebKit vulnerability, CVE-2021-1844, was used in a separate operation focused on stealing credentials from government bodies and nongovernmental organizations across Western Europe. Google attributes that campaign to a Russian threat actor it believes is the same group behind the SolarWinds intrusion.

Internet Explorer and malicious Office documents

The fourth flaw, CVE-2021-33742, affected Internet Explorer. Google's researchers found it while examining a campaign in which booby-trapped Office documents caused content to load inside IE. That operation also concentrated on users in Armenia, and Google assessed that its exploit was probably the work of the same commercial vendor that supplied the Chrome exploits. Across the campaigns, the exploits appear designed to enable surveillance of the targeted organizations and individuals.

Why the zero-day count keeps climbing

Stone and Lecigne attribute part of the surge to structural shifts in the exploit market. The spread of mobile platforms has raised demand for mobile-specific exploits, and more commercial vendors are now selling access to zero-day capabilities. At the same time, detection and disclosure have improved: the researchers pointed to changes by Google and Apple that surface vulnerabilities known to be exploited in the wild even when a vendor has not publicly acknowledged the activity itself.

Yaniv Bar-Dayan, CEO and co-founder at Vulcan Cyber, frames the trend in economic terms. As defenders get better at closing off known vulnerabilities, he argues, attackers shift toward engineered, never-before-seen intrusion methods rather than competing head-on with patching programs — a rebalancing of attacker cost versus defender cost.

Technical background

The browser flaws in this story belong to a well-understood family: memory-safety bugs inside a browser's rendering engine. When a renderer mishandles an object — for example, freeing memory and then continuing to use it, or confusing one object type for another — an attacker who controls the JavaScript or markup the renderer processes can sometimes redirect execution. Because the renderer is supposed to be sandboxed, a full compromise usually requires a second flaw to escape that sandbox and reach the operating system.

The delivery pattern described above is equally familiar. A convincing, single-use URL avoids leaving a reusable payload on a public server, and a lightweight fingerprinting page filters out researchers, sandboxes, and other uninteresting visitors before the expensive exploit is served. Staged collection — browser properties first, then CPU, OS, and firmware details — keeps the noisy work away from the target until the operator commits.

The Internet Explorer case illustrates a different composition problem: an application that hosts or invokes a browser engine inherits that engine's attack surface. Documents that pull remote content into an embedded browser control can therefore turn a file-opening action into a browser exploitation primitive.

Illustrative checks — these are generic examples, not indicators tied to this campaign:


# Check the installed Chrome build on Linux
google-chrome --version

# Check it on macOS
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --version


# Illustrative hunting logic: find browser processes spawned by Office applications
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} |
  Where-Object { $_.Message -match 'iexplore\.exe' -and $_.Message -match 'WINWORD\.EXE|EXCEL\.EXE' } |
  Select-Object TimeCreated, Message -First 20

Detection and mitigation

  • Keep Chrome, Safari, and any remaining Internet Explorer dependencies current; the four flaws here were fixed, so unpatched builds are the primary exposure.
  • Treat unsolicited one-time links as hostile. Mail gateways can flag or rewrite single-use URLs, and users should report unexpected messages rather than opening them.
  • Watch for Office applications spawning browser processes. That parent-child relationship is unusual in normal document workflows and is a practical detection hook for the IE-style chain.
  • Inventory embedded browser usage in line-of-business applications. Any component that renders web content needs the same patch cadence as a standalone browser.
  • Hunt for the reconnaissance pattern: a short-lived landing page followed by a second-stage request carrying host and firmware details. Correlating those two events can expose an attack before the exploit is delivered.
  • Limit the value of fingerprinting by hardening browser configurations and reducing plugin surface where policy allows, and segment high-risk users — government, NGO, and diplomatic staff — behind additional monitoring.

The broader lesson from Google's tally is that browser patches are necessary but not sufficient. The campaigns here paired freshly patched bugs with targeted, low-volume delivery, which is exactly the profile that signature-based defenses struggle to catch.