The exploitation of CVE-2026-51990 in Tencent’s Sogou Input Method for Windows is a particularly useful example of how apparently ordinary desktop software can become an unexpected initial-access mechanism. Gen Digital discovered the vulnerability while investigating an active UNC3569 intrusion and found that a specially crafted `sgbiz:` link could eventually produce arbitrary code execution under the privileges of the logged-in Windows user. The flaw is now tracked as CVE-2026-51990 and has been actively exploited to install the GRAYRABBIT backdoor. Sogou Input Method is widely used for Chinese-language input and reportedly has hundreds of millions of installations, which makes the vulnerability especially noteworthy because an input method would not normally be regarded by security teams as an internet-facing attack surface. Yet the Windows application includes its own custom protocol handler, configuration components and an embedded Chromium browser, effectively giving what appears to be keyboard software many of the security characteristics of a small application platform. 

The attack chain is more interesting than the CVE number because CVE-2026-51990 is really the result of several security failures interacting with each other. Sogou registers a custom `sgbiz:` URI scheme with Windows so that different components of the software can be launched through special links. When Windows encounters such a link, it passes the request to `biz_helper.exe`, which determines which Sogou executable should run and which command-line parameters should be supplied to it. Gen found that the handler performs meaningful validation on the executable name, including path-traversal protection and checks that the requested binary exists inside the Sogou installation directory. Unfortunately, the command-line argument parameter receives essentially no equivalent validation. This means an attacker cannot simply launch any executable on the machine, but can supply attacker-controlled arguments to legitimate Sogou binaries. The distinction sounds reassuring until one remembers that legitimate applications frequently contain functionality powerful enough to become an attacker’s tool when supplied with unexpected arguments.

UNC3569 exploited exactly that possibility by targeting `SGMyInput.exe`, Sogou’s configuration application. The attackers supplied arguments instructing it to open its skin-center page and load a web address under attacker control. The skin-center component is significant because it is the portion of the configuration interface that creates a Chromium Embedded Framework webview. Gen found that Sogou accepted the supplied destination without validating the URL scheme or restricting it to trusted Sogou domains, allowing the attacker to point the embedded browser directly at a malicious website. The initial argument-injection weakness therefore did not itself have to execute shellcode. It only needed to convince a trusted Sogou component to open an attacker-controlled page inside another trusted Sogou component. That is a recurring theme in modern attacks: instead of injecting malicious functionality directly, attackers manipulate legitimate software until it performs the dangerous operation on their behalf.

The next stage is where the architecture becomes significantly more dangerous. Sogou’s embedded browser was based on Chromium 80.0.3987.163, dating from around March 2020. At the time of Gen Digital’s analysis, this placed it roughly six years and more than 60 major Chromium versions behind the current browser release. An outdated embedded browser is already a substantial security concern because it inherits years of publicly documented browser vulnerabilities, but Gen found something worse: the browser sandbox had been explicitly disabled. The application also disabled important web-security mechanisms, including the same-origin policy, and enabled local file access from file URLs. The sandbox is normally the major containment layer that prevents a compromised renderer from immediately accessing the host operating system. With it disabled, a successful browser-engine exploit can run directly with the privileges of the application user rather than requiring a separate sandbox escape.

UNC3569 used CVE-2021-38003, an older V8 type-confusion vulnerability, against the embedded Chromium engine. That vulnerability was fixed years ago in mainstream Chrome releases, but it remained exploitable because Sogou continued shipping Chromium 80. The malicious page exploited the old V8 weakness, obtained arbitrary memory read and write, reached executable WebAssembly memory and ran embedded shellcode. There was no need for an expensive new Chrome zero-day and no need to defeat the browser sandbox because the application had already disabled it. This is an extremely important security lesson for developers embedding browsers inside desktop software: an embedded browser is still a browser from the attacker's perspective, even if the user never thinks of it as one. Shipping Chromium or CEF inside an application creates an obligation to maintain the browser engine at roughly the same urgency as a standalone browser, because attackers can reuse published Chromium exploits against forgotten embedded copies long after normal Chrome installations have been updated.

The entire chain could therefore be triggered through a crafted link. Gen characterizes CVE-2026-51990 as a one-click remote-code-execution vulnerability because the victim only needed to click the malicious link for Sogou’s protocol handler to take over the remainder of the chain. Tencent has noted that some circumstances may result in a browser prompt requiring user approval before the custom protocol is launched, so “one click” should not be interpreted as a completely interaction-free network exploit. But the operational distinction is relatively modest: a phishing message or chat containing an `sgbiz:` URL can potentially turn what appears to be application-specific navigation into code execution on a Windows endpoint.

Once code execution was achieved, the attackers used shellcode to download three files from infrastructure hosted on Alibaba Cloud in Hong Kong: a legitimate 7-Zip executable, a malicious DLL, and an encrypted payload containing GRAYRABBIT. The files were written into `C:\Users\Public\Documents\`. The attack then used DLL side-loading, placing the malicious DLL next to the legitimate 7-Zip executable under a name that 7-Zip would load automatically when it started. This allowed a legitimate, signed or familiar application to become the execution host for the malicious loader. The command given to 7-Zip did not need to perform any meaningful archive operation; starting the executable was enough to make Windows load the attacker-controlled DLL.

This part of the attack chain deserves attention because DLL side-loading remains attractive precisely because it abuses normal operating-system behavior. Security products that rely heavily on executable reputation may see the legitimate 7-Zip binary first, while the actual malicious logic enters through the DLL loaded alongside it. Application control therefore needs to understand not simply which executable launched but which modules it subsequently loaded, from what directories, and whether that combination is expected. A legitimate executable running from `C:\Users\Public\Documents\` while loading a similarly located DLL should be considerably more suspicious than the same application running from its standard installation directory with vendor-installed libraries.

The loader also contained relatively mature anti-analysis techniques. Gen found that it counted running processes before decrypting the payload. Systems with fewer than 50 processes, a condition commonly associated with automated malware sandboxes or minimal analysis environments, caused the loader to calculate the wrong decryption key and turn the payload into unusable data. On a normal desktop with a higher process count, decryption succeeded. The malware then executed the decrypted payload using Windows thread-pool APIs rather than the more commonly monitored `CreateThread` path and used an NTFS alternate-data-stream technique to remove its loader from disk without making a conventional `DeleteFileW` call. These features demonstrate that the campaign was designed not merely to gain execution but to reduce the quality of evidence left for automated security tools and investigators.

The final GRAYRABBIT payload is a modular 64-bit backdoor used by UNC3569. Gen says it supports process execution, interactive reverse shells, file upload and download, collection of system and user information, and reflective loading of additional plugins in memory. The backdoor communicates with command-and-control infrastructure using RC4-obfuscated traffic and can receive additional functionality later, meaning the initially observed payload should be treated as a foothold rather than the complete objective of the attacker. Once GRAYRABBIT is installed, the vulnerability that delivered it becomes largely irrelevant because the threat actor has a persistent mechanism for interacting with the compromised endpoint.

Gen attributes the observed campaign to UNC3569, a PRC-nexus threat group that Google researchers have previously tracked across government, education, technology and finance targets, particularly in East and Southeast Asia. Gen notes that the group has potential business connections to i-SOON and describes UNC3569 as an actor that prioritizes operational efficiency and frequently exploits known vulnerabilities rather than relying exclusively on new zero-days. This campaign fits that model remarkably well. The attackers did not need a sophisticated new Chromium exploit. They found a product containing a six-year-old browser engine and reused CVE-2021-38003 against it. From the adversary's perspective, an old vulnerability inside forgotten embedded software works just as well as a zero-day if the target never received the upstream security fixes.

Tencent responded relatively quickly after Gen reported the issue on April 9, 2026. The company completed a fix and distributed Sogou Input Method version 16.3.0.3498 on April 21. The updated `biz_helper.exe` validates URL arguments, permits HTTPS destinations and restricts navigation to approved Tencent- and Sogou-related domains, closing the attacker-controlled navigation route used by UNC3569. Organizations running Sogou Input Method on Windows should therefore verify deployment of version 16.3.0.3498 or a later release rather than assuming automatic updating necessarily reached every endpoint.

However, there is an important residual-security issue that makes this incident more than a conventional “patch and move on” story. Gen reports that the underlying embedded Chromium environment remained unchanged in the patched build it examined. The software still contained Chromium 80, the sandbox remained disabled, and the same weakened web-security configuration was still present. Tencent’s fix blocks the known route through which an attacker could force the webview to an arbitrary internet destination, which materially reduces the immediate vulnerability, but it does not eliminate the risk created by embedding an obsolete, unsandboxed browser engine inside privileged desktop software.

That architectural concern matters because security fixes that close one entrance without addressing a fundamentally weak component can leave future attack opportunities. If another code path is later found that lets untrusted content reach the same CEF component, the outdated engine may again provide attackers with a large catalogue of known exploitable browser vulnerabilities. Defense in depth exists precisely because developers cannot assume every route to a dangerous subsystem has already been discovered. The more robust long-term solution would therefore be to update the embedded Chromium framework to a supported release, restore the browser sandbox and remove unnecessary security-disabling flags rather than relying exclusively on URL allowlisting around the old engine.

Organizations should also consider whether input-method software deserves a higher level of endpoint scrutiny than it traditionally receives. An IME operates extremely close to user interaction and commonly runs across large parts of the desktop estate. It may launch automatically, receive frequent keyboard interaction, integrate with browsers and applications, and maintain update or cloud connectivity. Those characteristics make it an attractive persistence and execution location if compromised. Security inventories that classify Sogou merely as a language utility may therefore underestimate its actual attack surface.

The incident also highlights the security implications of custom URI schemes such as `sgbiz:`. Windows and other operating systems allow applications to register protocol handlers so websites and other programs can launch specific application functions. Examples include meeting links, messaging applications, development tools and remote-access clients. These schemes effectively create a bridge from untrusted web content into local desktop applications. Every parameter accepted by a protocol handler therefore needs to be treated as hostile input. Allowlisting the executable while allowing unrestricted command-line arguments, as happened here, protects the wrong half of the interface.

From a defensive perspective, organizations should first ensure that Sogou Input Method has been updated. Where the software is not operationally required, removing it may be preferable to carrying an additional embedded browser and custom protocol attack surface. Organizations with potential exposure during the period before April 21 should perform compromise hunting rather than relying solely on the update, because installing the fixed version will not remove a GRAYRABBIT backdoor that was already deployed before remediation. Gen has published indicators including malicious files under `C:\Users\Public\Documents\`, command-and-control infrastructure such as `mail.uaiubifas[.]top`, and staging infrastructure associated with the observed campaign.

Network telemetry may provide particularly useful detection opportunities. Gen found GRAYRABBIT communicating over TCP port 443 using RC4-obfuscated data rather than normal TLS. Because port 443 is ordinarily associated with HTTPS, organizations should not automatically assume every connection using that destination port is encrypted web traffic. Protocol-aware network monitoring can identify sessions on port 443 that do not begin with valid TLS negotiation and flag them for investigation. That sort of inspection can detect malware attempting to hide behind familiar port numbers even when the destination domain changes.

Endpoint telemetry should likewise look for suspicious parent-child and module-loading relationships rather than only malware hashes. `biz_helper.exe` launching `SGMyInput.exe` with unexpected skin-center URL arguments, `SGWebRender.exe` interacting with unfamiliar internet destinations, Sogou processes spawning or indirectly triggering unexpected binaries, and `7z.exe` running from public writable directories are examples of behavioral relationships that remain useful even when attackers change filenames or infrastructure. Monitoring module loads from user-writable directories can further expose DLL side-loading techniques.

Application egress controls can provide another layer of protection. There is rarely a legitimate reason for an embedded skin-marketplace browser to connect to arbitrary destinations across the internet. Restricting application components to documented service domains reduces the ability of an attacker to redirect trusted software toward malicious infrastructure. Tencent’s eventual fix essentially introduces this principle inside the application by applying an allowlist, but organizations can reinforce the same boundary at the network layer.

The attack also illustrates why software supply-chain inventories need to account for embedded dependencies, not merely top-level products. Security teams may believe Chrome is fully patched across an organization because managed browsers are current, while completely unrelated applications quietly ship old Chromium libraries that receive no equivalent update cycle. The vulnerability exposure therefore exists even though the user’s actual Chrome installation is secure. Software composition analysis and SBOMs can help identify these hidden browser engines, OpenSSL copies, Java runtimes and other third-party components buried inside desktop products.

This is particularly important for browser engines because their attack surface is enormous and updates are frequent. A vendor embedding Chromium cannot realistically freeze a browser version for six years and still expect the resulting component to remain a safe rendering environment for untrusted content. If maintaining Chromium updates is operationally difficult, the application should reduce or eliminate its ability to navigate to arbitrary external content and preserve the browser sandbox rather than disabling it for convenience.

CVE-2026-51990 therefore provides a strong example of vulnerability chaining. The protocol-handler weakness alone did not immediately compromise Windows. The unrestricted webview alone required a path for an attacker to control its destination. The old V8 vulnerability alone required attacker content to reach the browser. The lack of a sandbox turned browser exploitation into direct host execution. Each weakness amplified the others until clicking one link became enough to install a remote-access backdoor.

This is also why vulnerability assessment based exclusively on individual CVEs can miss real operational risk. Attackers rarely insist on finding one flawless CVSS 10 vulnerability that performs every stage of compromise. They combine whatever primitives a product provides. One weakness controls arguments, another controls navigation, a third executes JavaScript, and an architectural security decision removes the sandbox. The final result is much greater than any single implementation bug viewed independently.

The broader lesson is that trusted applications can become the attacker’s delivery infrastructure without themselves being malicious. Sogou Input Method was legitimately installed, `SGMyInput.exe` was legitimate, the Chromium component belonged to the product, and 7-Zip was a legitimate executable. The malicious behavior emerged from how those trusted components were connected and manipulated. That is why modern endpoint defense cannot rely only on asking whether a binary is trusted. It also needs to ask whether a trusted binary is doing something that makes sense. CVE-2026-51990 turned a Chinese input method into a path from a web link to an obsolete browser, from an obsolete browser to shellcode, from shellcode to DLL side-loading, and from DLL side-loading to a persistent GRAYRABBIT backdoor. 

Threat actors linked to a China-aligned espionage group are exploiting a critical vulnerability (CVE-2026-51990) in Tencent's Sogou Input Method for Windows to deploy the GrayRabbit backdoor. [...]

Source: Hackers exploit Tencent app flaw to deploy GrayRabbit malware via Bleeping Computer — published 13 Sep 2026.