Chrome DevTools Abuse Hijacks Logged In Sessions

Start with the part that is not scary: nobody reaches your Chrome from a web page, and no patch is pending. Now the part that is. For an attacker already running code on a Windows box, the browser in the taskbar stops being a locked box of encrypted cookies and becomes a live remote control. Every tab you left open, Gmail included, is a room they walk into without seeing your password.

Key Takeaways

• SpecterOps consultant Andrew Gomez published a technique on 13 August 2026 that turns on the Chrome DevTools Protocol inside a running chrome.exe or msedge.exe, no command line flag involved.
• No CVE is claimed and no Chrome bug is exploited; the technique assumes code execution on the Windows host and the ability to inject into the browser process.
• Chrome 136 was meant to close this route by ignoring --remote-debugging-port against the default profile.
• The companion toolkit reads cookies with Storage.getCookies, streams tabs, and proxies requests through the authenticated browser, so multi factor authentication is already behind it.
• Google says no software alone can stop cookie theft once malware is on a machine, which is why Device Bound Session Credentials in Chrome 146 targets replay rather than theft.

What Is the Chrome DevTools Protocol?

CDP is the JSON messaging interface the DevTools panel itself speaks to the browser. Google's protocol documentation describes it as a way for tools to "instrument, inspect, debug and profile Chromium, Chrome and other Blink-based browsers," across more than sixty domains covering Page, Network, Storage, DOM and Input.

Is This a Vulnerability or Intended Behavior?

Intended behaviour, abused. The SpecterOps writeup claims no CVE and exploits no memory corruption bug. It reaches into a browser that is already running, resolves Chromium's internal symbols with masked byte signatures, and gets the browser's own user interface thread to call an internal function named StartRemoteDebuggingServer on a port of the attacker's choosing.

The preconditions matter more than the mechanics. The attacker needs code execution on the Windows host, x64, and injection rights into the browser process such as PROCESS_CREATE_THREAD and PROCESS_VM_READ. Nothing here is remote and nothing is drive by. If somebody can do this to you, they were already on your machine.

The clever part is what it declines to do. Google announced in March 2025 that Chrome 136 would ignore the --remote-debugging-port and --remote-debugging-pipe switches unless paired with a non standard --user-data-dir, forcing a fresh profile and a fresh login. Its reason: "Since App-Bound Encryption was enabled we've seen an increase in attackers using Chrome Remote Debugging to extract cookies." This technique does not beat that check. It never presents a command line for the check to read.

What Can an Attacker Actually Reach?

Everything the browser can reach while you are logged in. Once the debugging server is listening, the toolkit in the SpecterOps research drives ordinary protocol commands:

• Storage.getCookies hands over session cookies without ever opening the encrypted cookie database on disk.
• Page.captureScreenshot and Page.screencast take stills or stream the session live.
• Chromium's autofill workflow can be walked to surface saved passwords, plus history, bookmarks and installed extensions.
• Requests proxied through the authenticated browser arrive at their destination looking exactly like yours.

The technique targets Windows x64, and it is Chromium behaviour rather than a Chrome quirk, so Edge and other Chromium builds sit in scope alongside Chrome itself. SpecterOps does not publish the exact builds it verified against, so treat the affected range as Chrome 136 onward rather than any single version.

Why Is Hijacking a Session Worse Than Stealing a Password?

Because a password still has to get past your second factor, and a live session already did. MFA is a gate you pass once, at the front. Everything after it is a cookie the server trusts. Ride the session and the gate is behind you, unasked.

A stolen password announces itself: new device, unfamiliar location, an alert in your inbox. A session driven from inside your own browser produces none of those signals, because nothing anomalous happened. We saw the same weakness when adversary in the middle kits started hijacking Outlook inboxes past MFA, reached from the other side: that attack steals the token in transit, this one borrows the browser holding it.

Which is the framing most coverage misses. Chrome is not broken. "The endpoint is compromised" and "the session is compromised" have collapsed into one sentence, and every defence assuming cookies must be exfiltrated first is guarding a border nobody needs to cross.

What This Means for Your Open Gmail Tab

Webmail sits open all day, which makes it the most valuable tab on the machine. An operator with CDP access to a browser holding an authenticated Gmail session can screenshot the thread on screen, read messages by driving the page, and send requests Google sees as coming from your own browser. Password reset links for every other account you own land in that same tab.

Nothing installed inside the mail client changes that, and any tool promising to protect your mail from it is selling you something. This is a browser process problem, not an inbox content problem. The nearest comparison here is the Claude for Chrome flaw that let rogue extensions read Gmail: whatever holds your session is your real mail security boundary.

One consequence follows. Changing your Gmail password does not by itself end an attacker's access, because the hijacked session was never authenticated by that password. Only signing out of all devices invalidates the sessions themselves.

Does Chrome's Hardware Binding Stop It?

Not this one, and Google never claimed it would. Device Bound Session Credentials, which reached Chrome 146 on Windows in April 2026, tie a session's refresh to a key held by that device, so exfiltrated cookies expire into uselessness anywhere else. We covered it in Chrome 146 ties your login to your hardware.

That defence targets replay elsewhere. This technique runs on the original machine, inside the browser that legitimately holds the key, so there is nothing to replay. Google is candid about the limit: "once sophisticated malware has gained access to a machine, it can read the local files and memory where browsers store authentication cookies. As a result, there is no reliable way to prevent cookie exfiltration using software alone."

How Do You Reduce the Risk?

The technique begins after compromise, so the useful moves are keeping code off the machine and catching the injection when it lands.

• Alert on injection into the browser. Microsoft's Sysmon Event ID 8 records CreateRemoteThread, a technique Microsoft describes as "used by malware to inject code and hide in other processes," and Event ID 10 records one process opening another. SpecterOps flags access mask 0x143a against chrome.exe and msedge.exe.
• Stop installing software you did not go looking for. Cracked applications, fake installers and extensions with sweeping permissions are how the foothold arrives.
• Sign out of sensitive sessions rather than closing the tab. A closed window can leave the session valid. Banking, admin consoles and password vaults deserve an explicit sign out.
• After any suspected compromise, end sessions before rotating credentials. Google's sign out of all devices control and the Microsoft 365 equivalent come first; the other order leaves the hijacked session alive.
• Keep Chromium current. Chrome 136 removed the easy command line path, and older builds still hand attackers the cheap route.

A browser is an authentication device nobody designed as one. Roughly sixteen months after Google locked the debugging switches, the same capability came back through the process itself, and no version number fixes an interface behaving exactly as specified.