The researchers conducted an end-to-end experiment involving an attacker-controlled Worker and a victim Worker, with the JWT deliberately stored in the victim's memory. According to the research paper, the experiment did not involve accessing any customer information.
Cloudflare said it has already addressed the issue in its production environment by strengthening Dynamic Process Isolation (DyPrIs), integrating the V8 Sandbox and introducing Memory Protection Keys (MPK)-based in-process isolation. The company also said it found no evidence of active exploitation related to the issue during the past three years.
"We demonstrate that the production implementation of DyPrIs was insufficient," the researchers said in the paper.
Cloudflare Workers executes code belonging to multiple tenants using separate V8 isolates within the same operating-system process. Rather than relying solely on strict process-level separation, the platform uses language-level isolation to help maintain faster startup times.
According to Cloudflare, a memory-read attack within a shared Worker process could potentially enable information to leak across tenants. However, the attack requires both the attacker and victim Workers to be placed in separate V8 isolates within the same Worker process.
The researchers said the attacker must control legitimate code within its own isolate. The technique does not rely on native code execution, a V8 vulnerability or a sandbox escape.
Cloudflare Workers also limits access to local timing mechanisms by freezing or reducing the precision of timers during CPU execution. Worker scripts do not have access to shared memory or multithreading. However, the researchers discovered that WebSocket communications could act as a remote timing channel.
They also found that Durable Objects could keep a Worker isolate running continuously for periods ranging from five hours to more than 20 hours. Under DyPrIs, suspicious scripts are moved into a separate process after an invocation ends. The researchers found that long-running Durable Object invocations could remain active before this isolation mechanism was triggered.
Another weakness involved WebSocket-intensive input/output activity. The researchers observed that such activity increased instruction translation lookaside buffer (iTLB) activity, weakening the normalized branch-misprediction signal monitored by DyPrIs and pushing it below the mechanism's detection threshold.
Cloudflare characterized the problem as a limitation in how DyPrIs was implemented. The research paper, however, argued that the weaknesses represented more fundamental limitations of the detection methodology rather than simple implementation errors. The researchers recommended monitoring for such activity during execution and using signals that cannot be suppressed through I/O activity.
The researchers conducted their production testing on Linux servers powered by AMD EPYC Zen 2 and Zen 3 processors. Measurements were intentionally performed at night, when CPU utilization was between 10% and 25%, to determine the highest achievable leakage rate.
According to the paper, heavier system workloads reduced the amount of data that could be leaked, although the attack remained possible at slower speeds under greater CPU load.
The study recorded a peak leakage rate of 12 bits per second with 99.16% accuracy. By comparison, the earlier attack achieved approximately 2 bits per minute.
The latest disclosure arrives nearly five years after Cloudflare and Graz University of Technology (TU Graz) published research detailing a remote Spectre attack against Workers. That earlier work demonstrated a leakage rate of 120 bits per hour and introduced DyPrIs as a defense mechanism.
The 2021 research reported a false-positive rate of 0.61% and concluded that DyPrIs offered, statistically, security guarantees comparable to strict process isolation against the Spectre attacks evaluated at that time.
Cloudflare subsequently outlined additional security hardening measures for Workers in September 2025. The company's mitigations include:
Enhanced DyPrIs: Improvements designed to strengthen the detection capabilities of the existing isolation mechanism.
V8 Sandbox: A security layer designed to restrict transient access to 64-bit pointers.
MPK-based in-process isolation: Worker heaps are placed behind hardware-enforced Memory Protection Keys. Cloudflare said modern x64 systems provide approximately 12 keys that can be used for this purpose. Its architecture combines MPK with the V8 Sandbox and a rotating memory layout to prevent neighboring sandboxes from being assigned the same protection key.
Cloudflare's September 2025 documentation noted that randomly assigning MPK keys would block roughly 92% of cross-isolate access attempts because two isolates could receive the same key. The company said its stricter rotating memory layout eliminates that remaining gap within the threat model covered by the in-sandbox protections.
Microsoft Copilot Personal contains three vulnerabilities that could allow an attacker to execute a malicious prompt with one click and exfiltrate data from connected applications, according to Varonis Threat Labs.
The researchers collectively named the flaws CoSnitch and reported them to Microsoft in December 2025. Microsoft patched the vulnerabilities on August 18, 2026, with the issue tracked as CVE-2026-24301. Varonis said it found no evidence of exploitation in the wild. The research concerns the consumer Copilot service at copilot.microsoft.com and does not establish that the same behavior affected Microsoft 365 Copilot.
Copilot Revealed Its Own Attack Path
Varonis discovered the vulnerability through what it calls "meta-hacking," repeatedly asking Copilot why a prompt could not execute without user interaction. After several refusals containing technical explanations, Copilot eventually disclosed an undocumented "autorun=1" URL parameter, including the conditions and safeguards associated with it.
Researchers constructed the URL as described and found that the supposedly disabled parameter still executed. They combined "autorun=1" with Copilot's existing "q" parameter, which pre-fills the prompt. While "q" alone requires user interaction, the combination automatically triggered the prompt when the page loaded.
Varonis said the prompt then continued executing even if the victim immediately closed the Copilot tab. Its earlier Reprompt research had also used "q" as a one-click Parameter-to-Prompt mechanism.
Existing Permissions Enable Data Theft
The first two CoSnitch flaws form the one-click exfiltration chain. The injected instruction operates with the same capabilities available to a legitimate user prompt and does not grant Copilot additional permissions.
Researchers demonstrated access to connected mail messages, subject lines and sender and recipient metadata; calendar titles, attendees, times and locations; Google Drive filenames and metadata summaries; previous Copilot conversations; and stored memory instructions and user-defined rules.
The retrieved information could be encoded, including with Base64, and transmitted through Copilot's built-in URL-fetching capability to an attacker-controlled webhook. Varonis said the resulting request could resemble Copilot's ordinary web retrieval traffic, potentially making network-level detection difficult.
Separate Memory Poisoning Path
The third vulnerability involves indirect prompt injection through web summarization. A malicious webpage could contain attacker-controlled instructions that Copilot processed and wrote into its persistent memory.
Varonis said such injected memories could survive password changes, session revocation and device re-enrollment until manually removed. The modification reportedly generated no process, file or network activity that conventional security tooling would necessarily flag, although the change remained visible in Copilot's memory interface.
The finding follows earlier Microsoft 365 Copilot memory research by Håkon Måløy and Johann Rehberger. Microsoft has separately said M365 Copilot applies sanitization and prompt-injection checks to memory writes, performs Task Adherence checks on explicit memory updates, and records those changes for security monitoring through audit data and the "MemoryUpdated" field.
Varonis recommends reviewing connected applications, disconnecting unnecessary services, monitoring AI assistants as privileged systems and exercising caution with links that open AI assistants.
The disclosure follows Varonis's RovoBlast research, which identified another one-click attack involving Atlassian's Rovo assistant. Together, the findings demonstrate how URL handling, authorized application access, external content and persistent AI memory can combine into an attack chain without directly compromising the victim's underlying accounts.
Google’s Chrome Incognito mode can keep browsing history off a device, but it was never designed to make users anonymous online. A class-action lawsuit over the feature exposed how far that distinction could be misunderstood, with Google agreeing to delete or remediate billions of private-browsing records and change how it explains Incognito to users.
The lawsuit, Brown v. Google, was filed in 2020 and alleged that Google continued collecting information about users while they browsed through Chrome’s Incognito mode and other browsers’ private-browsing modes.
The plaintiffs initially sought billions of dollars in damages, with their claims eventually putting at least $5 billion at stake. However, Google did not ultimately agree to pay $5 billion. Under the settlement, there was no class-wide monetary payout. Instead, Google agreed to data deletion and remediation measures, changes to its privacy disclosures, and additional restrictions on data collection. Plaintiffs’ lawyers valued the settlement’s non-monetary relief at more than $5 billion, with estimates reaching $7.8 billion.
The case nevertheless exposed a fundamental problem with private browsing: preventing a browser from retaining a user's history is not the same thing as preventing websites, network operators or online services from observing that user's activity.
Google employees raised concerns about Incognito
The legal dispute became particularly notable after internal Google communications surfaced during litigation.
In one email, Google Chief Marketing Officer Lorraine Twohill told CEO Sundar Pichai that the company should make Incognito "truly private." She also warned that Google could not market the feature too strongly because it was "not truly private," requiring what she described as "fuzzy, hedging language."
Other internal communications were even more critical of the feature. According to material cited in the litigation, Google employees described Incognito as "misleading" and "effectively a lie," while another employee argued that Google should stop using the Incognito name and its spy-themed icon because users could misunderstand the protection it provided. Another recommendation suggested replacing the messaging with a warning that users were not protected from Google.
These discussions mattered because the lawsuit was not simply about whether Incognito stored browsing history locally. It questioned whether users were being given a sufficiently accurate understanding of what happened to their data after it left the browser.
Google disputed the allegations and maintained that the limitations of Incognito had been communicated to users. A Google spokesperson said the company believed the lawsuit was without merit and argued that Incognito was intended to provide a private browsing experience, rather than prevent websites and services from collecting information.
What Incognito actually does
Chrome's Incognito mode does provide a real privacy function, but that function is primarily local.
When a user opens an Incognito window, Chrome starts a separate browsing session. Once all Incognito windows are closed, Chrome does not retain the browsing history, cookies and site data, or information entered into forms from that session in the normal browser profile. Third-party cookies are also blocked by default in current versions of Chrome, although users can temporarily allow them for particular sites.
This makes Incognito useful in situations where the concern is another person accessing the same device.
Someone using a shared computer, for example, can browse for a gift without leaving the visited pages in Chrome's ordinary history. It can also provide a separate browsing session when a user does not want existing cookies and account sessions to carry over.
But there is an important limitation.
Incognito does not erase everything created during a session. Downloads remain on the device, and bookmarks saved during the session remain available after Incognito is closed. Signing into a website can also allow that service to associate activity with the account being used.
The key distinction is therefore simple: Incognito primarily limits what Chrome stores locally. It does not turn the internet connection into a private tunnel.
Your ISP and network administrator can still see activity
Opening an Incognito window does not prevent an internet service provider from observing network activity.
Google's own documentation states that organizations managing a network, including schools, employers and internet service providers, may be able to observe activity while a user is browsing in Incognito. Incognito also does not hide activity or location from the websites being visited.
This is an important distinction from encryption.
Chrome's HTTPS protections can encrypt traffic between a browser and an HTTPS-enabled website, helping prevent someone monitoring the connection from reading the contents of that traffic. Chrome also warns users when they are about to load sites without HTTPS, while Secure DNS can encrypt DNS lookups in supported configurations.
But HTTPS does not make the user anonymous.
The network still has visibility into connection metadata, while the destination website receives the request and can process information available to it.
In other words, Incognito and HTTPS solve different problems. Incognito reduces local traces. HTTPS protects communications in transit. Neither one, by itself, is an anonymity system.
Websites can still identify and track users
The privacy boundary becomes even clearer once a user reaches a website.
Google's current Chrome documentation explicitly states that Incognito does not change how websites collect data or how the services those websites use collect information. Sites can continue gathering information even when a user is not signed in.
Websites can also use first-party technologies and other mechanisms to understand activity within a session. Third-party cookies are only one part of the tracking ecosystem. Google itself notes that websites can use different mechanisms to personalize content and advertising and learn about activity across sites.
This is also where the distinction between an IP address and browser history matters.
Incognito can prevent a local Chrome profile from retaining the list of pages a user visited. It does not automatically conceal the network address from the websites receiving the connections.
And if a person voluntarily signs into a service while using Incognito, the service has an obvious account-level identifier with which to associate the activity. Google's own documentation warns that signing into a Google service or another website during an Incognito session can allow that site to remember the activity.
The lawsuit forced changes to Incognito
The settlement went further than simply changing a warning message.
According to the court filing, Google agreed to delete or remediate billions of records reflecting class members' private browsing activities. The company also agreed to continue blocking third-party cookies in Incognito for five years.
The filing provides an unusually detailed picture of why the cookie change mattered.
Google had historically collected its own third-party cookies when users visited non-Google websites. After the lawsuit was filed, Google implemented third-party-cookie blocking for Incognito users. Under the settlement, that protection had to remain in place for five years. The plaintiffs' filing said blocking data associated with Google's third-party cookies in Incognito could reduce Google's global annual revenue by nearly $500 million.
Google also agreed to remove four identified private-browsing detection signals. According to the plaintiffs' filing, those signals could reveal that a user had chosen private browsing and were then used to label the resulting data as private. The settlement required Google to delete those signals and agree not to use such detection mechanisms to identify or track private browsing.
The class covered an estimated 136 million users, according to court-related filings.
Google eventually changed the warning
The dispute also changed the language presented to Chrome users.
Chrome's current Incognito documentation now makes the limitation explicit. It says that Incognito does not change how data is collected by websites users visit and the services those websites use, including Google. Google also says that websites, network administrators and ISPs may still be able to observe activity during an Incognito session.
That clarification is arguably more important than the Incognito icon itself.
The familiar private-browsing interface can create an intuitive association between the words "Incognito" and anonymity. Technically, however, the feature is much narrower. Chromium describes Incognito as a window-level mode in which pages are not persisted to browsing history and a temporary cookie store is used for the session.
That is a local privacy mechanism, not an invisibility cloak.
So, is Incognito worth using?
Yes, if the objective is local privacy.
If you share a computer with other people, do not want a particular browsing session stored in your ordinary history, or want a temporary browser session separated from your normal cookies, Incognito remains useful.
It is also useful for testing how a website behaves without the cookies and account state associated with a normal session.
But users should not treat the Incognito icon as a guarantee that their online activity is hidden.
It does not prevent an ISP or network administrator from observing activity. It does not stop websites from collecting information. It does not automatically hide an IP address. It does not prevent a user from being identified after signing into an account. And it does not protect files downloaded to the device after the session ends.
Users seeking stronger privacy need to think in layers rather than relying on a single browser setting.
A privacy-focused browser can reduce tracking at the browser level. Tracker and content blockers can limit third-party collection. A properly configured VPN can conceal the user's IP address from the websites they visit and hide destination traffic from the ISP, although the VPN provider itself becomes part of the trust model. Keeping the browser, operating system and extensions updated remains essential because privacy controls cannot compensate for an unpatched security vulnerability.
Chrome itself should also not be treated as static. Google continues to modify its privacy and security architecture. Third-party-cookie protections in Incognito are already part of the browser's privacy model, while Google has also explored additional protections for IP addresses in Incognito.
The larger lesson from the Incognito lawsuit is therefore not that private browsing is useless.
It is that privacy has layers, and the word "private" can mean very different things depending on where the data is stored, who controls the network and which services receive the user's requests.
Incognito can hide your browsing history from someone checking the same device.
It cannot make you disappear from the internet.
When people think about a cyberattack, they usually picture stolen passwords, malware, ransomware or someone exploiting a vulnerability to break into a system.
Side-channel attacks work differently. Instead of directly stealing a secret, an attacker studies the traces a computer produces while carrying out normal operations. Tiny differences in processing time, electricity consumption, electromagnetic signals, sounds or hardware activity can reveal clues about what is happening inside the machine.
Think of a locked safe. A thief may not know its combination or be able to break the lock, but if turning the dial produces different clicks or pauses, listening closely could reveal information about the combination. The safe is not deliberately revealing anything. Its physical behavior is simply giving away clues.
Computers can do much the same thing.
A problem that is decades old
Side-channel attacks are not a new phenomenon.
In 1985, Dutch researcher Wim van Eck demonstrated that electromagnetic emissions from video display units could be captured and decoded, potentially revealing what was being displayed. The screen was not intentionally broadcasting its contents, but its normal operation produced signals that could be observed externally.
The technique became particularly important in cryptography during the 1990s. In 1996, researcher Paul Kocher showed that measuring tiny differences in the time taken by cryptographic operations could reveal information about private keys. In 1999, Kocher, Joshua Jaffe and Benjamin Jun demonstrated that measuring power consumption could similarly expose information from cryptographic devices.
Researchers later showed that sound could become another source of leakage. Experiments demonstrated that acoustic emissions from laptops performing cryptographic operations could be analyzed to recover a 4,096-bit RSA key under controlled conditions.
These discoveries changed the way security engineers evaluated systems. A cryptographic algorithm could be mathematically secure while its implementation still leaked information through timing, power, sound or electromagnetic radiation.
When processor performance became a security problem
The rise of modern CPUs created another class of side channels.
Processors use speculative execution to predict which instructions a program will need and execute them ahead of time, improving performance. In 2018, researchers disclosed Meltdown and Spectre, demonstrating that traces left by speculative execution could allow malicious code to infer information that should have remained protected.
The attacks challenged an important assumption in computing: that programs running on the same machine can be reliably isolated from one another. They also demonstrated that security problems could originate from performance features built deep inside the processor rather than from conventional software bugs.
Researchers have continued finding similar problems in newer hardware.
In 2022, Hertzbleed showed that dynamic voltage and frequency scaling, a feature used to manage processor power and performance, could become a timing side channel. Because processor frequency can vary with the computation being performed, an attacker could potentially infer information remotely without directly measuring power consumption. The researchers demonstrated implications for cryptographic key extraction on modern Intel and AMD processors.
In 2023, Downfall exposed another weakness in certain Intel processors through the Gather instruction, while Zenbleed affected AMD's Zen 2 architecture and could expose information from another execution context under particular conditions.
The pattern is becoming difficult to ignore: features designed to make computers faster or more efficient can also create unexpected paths for information leakage.
Side channels are spreading beyond CPUs
Researchers are now finding these channels in other parts of the computing stack.
GPU.zip demonstrated how hardware-based graphics compression could create a side channel capable of exposing visual information processed by graphics processors. The research showed that the problem could extend beyond the CPU and into the way GPUs handle graphical data.
In 2024, GoFetch exposed another hardware-level problem in Apple processors. The attack targeted a feature called a data memory-dependent prefetcher, which predicts future memory requirements to improve performance. Researchers demonstrated that this behavior could undermine protections in cryptographic software and help extract secret keys.
These attacks illustrate why simply securing software is not always enough. Hardware underneath the software can produce information that applications never intended to expose.
The SSD can become a side channel too
The latest research pushes the idea even further.
In 2026, researchers at Graz University of Technology introduced FROST, short for "Fingerprinting Remotely using OPFS-based SSD Timing." The attack targets the browser's Origin Private File System, or OPFS, a feature that allows websites to store and access files within their own sandboxed storage area.
FROST does not give a malicious website direct access to another application's files.
Instead, it measures delays caused when multiple programs compete for the same SSD.
The concept is similar to traffic on a shared road. A driver does not need to see another vehicle to know that it is there. If traffic suddenly makes the journey slower, the delay itself provides information.
FROST applies the same principle to storage. A malicious webpage can repeatedly perform storage operations through OPFS and measure tiny changes in how long they take. Those changes can reveal patterns in other activity occurring on the same computer.
The researchers found that the technique could be used to fingerprint websites and applications. In their evaluation, FROST achieved an F1 score of 88.95% for website fingerprinting and 95.83% for application fingerprinting on tested systems. It can also operate remotely through JavaScript without requiring native code execution.
That does not mean websites can simply read a user's files or see everything happening on a computer. FROST is an inference attack. It identifies activity from the timing patterns produced by shared hardware resources.
A specialised threat, but an important warning
Side-channel attacks are not currently the everyday attack method most users are likely to encounter. Cybercriminals generally have easier options, including phishing, credential theft, malware, ransomware and exploiting vulnerable software.
But their importance extends beyond how frequently criminals use them.
Side-channel research repeatedly reveals that security boundaries can be weaker than they appear. A processor, GPU, browser or storage device may never intentionally disclose sensitive information, yet its normal operation can leave behind measurable clues.
From electromagnetic emissions and cryptographic timing to speculative execution, processor frequency, GPU compression and SSD activity, the side channel keeps changing as computing technology evolves.
Computers do not always need to be hacked for them to leak secrets.
Sometimes, all an attacker needs is to listen to what the machine reveals while it is doing its job.