Remus Stealer Claims Gmail Access Survives Password Resets

Developers of the Remus Stealer infostealer claim that access to Gmail can survive a password change and session revocation. Hudson Rock has reviewed the malware’s commercial offer, but no Google vulnerability has been confirmed. This article separates the claims from the verified facts and outlines the steps users and administrators should take.

A commercial offer built around persistent access

According to an investigation by cybersecurity firm Hudson Rock, Remus Stealer’s developers market an “Enterprise” offer priced at $1,000 per month. Remus Stealer belongs to the infostealer family, malware designed to steal personal data and credentials. Based on the reporting, the offer promises durable access to compromised mailboxes, email browsing without retrieving browser cookie files, and continued access after a password change or session revocation.

Hudson Rock obtained screenshots showing an interface that allows operators to browse messages, search emails and share access to a compromised inbox. The researchers say they spoke directly with the developer and with an individual who publicly recommends the service.

“We spoke directly with the developer and with a person who publicly recommends the service”

Alon Gal, Co-founder and CTO, Hudson Rock

Gal says the program interacts with browser memory before leaving the system, which could make the intrusion particularly hard to detect. The table below separates the developers’ claims from what has actually been verified.

Zero-day: a precise term, an unproven claim

Google Cloud defines a zero-day exploit as the exploitation of a vulnerability still unknown to the vendor, often before a patch is available. The term refers to the window between exploitation and correction, which can last days, months or even years. Once a patch is published and applied, the exploit is no longer considered a zero-day.

Remus Stealer’s creators present their discovery as a Gmail zero-day. Gal qualified that position in a LinkedIn post: “The developer talks about a Gmail zero-day. We have not established that.” Hudson Rock has also not confirmed access to new emails after a full account recovery.

Researchers favor a different technical hypothesis: the malware could retrieve or establish a reusable authorization from an already compromised browser, then use it remotely without keeping the malicious software active on the computer. This would explain why some access persists after the browser is closed, but it does not show that access survives an effective revocation of authorizations. The real scope of the technique therefore remains unknown.

A risk that extends beyond Gmail

If the claims were confirmed, the access would extend well beyond email content. Gmail is commonly used to receive password reset links and verification codes, which can be used to take over other services, including financial platforms and accounts tied to cryptocurrencies. Gal summarizes the problem this way:

“A single infected computer can endanger the recovery channel of several accounts”

Alon Gal, Co-founder and CTO, Hudson Rock

Cryptoast says it asked Google for comment, with no response published as of the article’s date. The sources report no measurable market movement, trading volume, price change or financial reaction tied to the story. The only documented reaction is the attention of cybersecurity players, with Hudson Rock having examined the offer and contacted its promoters.

Chrome: an exploited flaw, distinct from the Gmail claim

A Chrome flaw that is actually being exploited is documented. Le Monde Informatique describes the first Chrome zero-day of 2026, identified as CVE-2026-2441. It is a use-after-free vulnerability caused by improper handling of dynamic memory in the processing of CSS stylesheets: the engine frees a memory region before it has finished using it. According to the vendor’s alert, visiting a malicious HTML page could allow arbitrary code execution inside the browser sandbox.

Cryptoast also mentions another Chrome update fixing nine security flaws, including CVE-2026-125350, a memory management vulnerability presented as the eighth zero-day exploited and fixed by Google since the start of 2026. The two sources disagree on the ranking: first for one, eighth for the other. The different identifiers and this timeline suggest successive campaigns, although the sources do not explicitly establish a link.

Gene Moody, field CTO at Action1, explains that the exploit frees an object in browser memory while that location remains referenced. An attacker able to control heap layout can replace its contents with malicious data. He notes that the flaw sits in the rendering engine and can be reached through standard web content, giving it a very broad attack surface.

“In practice, it may be enough for a vulnerable user to visit a malicious page to trigger exploitation”

Gene Moody, Field CTO, Action1

Expert reactions and recommended measures

Johannes Ullrich, research director at the SANS Institute, believes many other Chrome zero-days are probably already in use but have not been discovered or fixed. He points out that the Chromium codebase contains roughly 36 million lines of code and that adversaries use automated tools too.

“A project of that scale inevitably contains vulnerabilities”

Johannes Ullrich, Research Director, SANS Institute

Ullrich adds that malicious extensions are often a bigger problem than zero-days. David Shipley, head of Beauceron Security, considers the current fix to be partial and says Google remains quiet about the severity of the flaw. He also stresses that patch deployment remains complex and costly, especially for small organizations. Google nonetheless recommends installing updates as soon as possible.

Procedure for a compromised Gmail account

• Clean the infected device, then change credentials from a clean device.
• Review active sessions, authorized apps, recovery methods and linked accounts.
• Check mailbox delegation, auto-forwarding, filters, sending addresses and IMAP or POP access.
• Enable two-step verification combining the password with a hardware element such as a phone or security key.
• Verify bank and administrative accounts if a third party requests transfers or account openings.

For Google Workspace administrators

1. Temporarily suspend the account, which resets login cookies and OAuth tokens.
2. Review audit logs, mobile devices and successful or failed logins over a period of up to six months.
3. Reset the password, revoke OAuth 2.0 tokens and delete app passwords.
4. Reactivate the account with a unique temporary password, enable two-step verification with U2F keys, and check filters, forwarding, messages and contacts.

Conclusion: a claim to watch, a threat already documented

Remus Stealer’s claim has not been demonstrated. The conditions for persistent access after an effective revocation of authorizations remain unverified and should not be treated as fact. By contrast, the combination of commercially sold infostealers, exploited Chrome flaws and email accounts serving as recovery channels justifies heightened vigilance.

Three scenarios remain open. If Google or an independent test confirms a flaw, the patch and recommendations will need to be revised accordingly. If the claim remains unverified, the main risk will still be the theft of credentials and sessions by malware. If verification shows real persistence after revocation, the standard response centered on changing passwords will need to be supplemented by a full purge of authorizations.

Sources

• Cryptoast, Google zero-day allegation (French)
• Google Cloud, what is a zero-day exploit
• Actu Crypto, podcast episode, 11 November 2026
• Google, Google Account help: compromised account
• Google Workspace, identify and secure compromised accounts
• Le Monde Informatique, Chrome zero-day fix

Cet article est publié à titre informatif et éducatif. Il ne constitue en aucun cas un conseil en investissement. Faites vos propres recherches (DYOR) avant toute décision.