Loading story…
Researchers disclosed a Chrome vulnerability that could bypass SameSite=Strict cookie protections when a target website had a registered service worker and a victim opened Chrome DevTools. A cross-site POST initially sent without cookies could be replayed by the Inspector Resource Content Loader using the invalid kNoCors and kOnlyIfCached combination; the target site's service worker could then refetch the request in its own origin context, causing Strict cookies to be attached.
The flaw could enable CSRF-style actions, including unauthorized account or password changes and financial transfers. Chrome's Vulnerability Reward Program rated the report S3/P2 and fixed the issue by changing the loader request mode to kSameOrigin while retaining kOnlyIfCached. Researchers also reported a related cache and request-resubmission path involving Ctrl+U and page refresh behavior as Issue-470629629.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
Chrome fixed the issue by changing Inspector Resource Content Loader's request mode to kSameOrigin while retaining kOnlyIfCached. The change prevents a service worker from making an outbound network fetch that could replay a cookie-bearing POST request.
Researcher Jorian found that Ctrl+U to view page source could trigger the same cache issue and separately reported refresh behavior with resubmission confirmation as Issue-470629629.
Researchers, including bug_blitzer, reported a Chrome vulnerability in which opening DevTools after a cross-site POST could cause a service worker to replay the request in the target origin context with SameSite=Strict cookies attached. Chrome VRP classified the report as severity S3 and priority P2.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A serious unpatched **Chromium** vulnerability was accidentally exposed after Google engineers marked the issue as fixed without shipping a patch, causing the bug report and proof-of-concept to become public. The flaw, originally reported in 2022, abuses the **Background Fetch API** to keep a Service Worker and malicious JavaScript running after the browser is closed and, in some cases, even after a device reboot. Affected products include **Chrome**, **Microsoft Edge**, **Brave**, **Opera**, **Vivaldi**, and **Arc**. The bug could let attackers abuse victims’ browsers for proxying traffic, launching DDoS activity, opening websites, and tracking user behavior; Google later re-hid the report and said it is working on a fix. Separately, researchers analyzing the **VoidStealer** infostealer found it can bypass Chrome’s **Application-Bound Encryption (ABE)** on Windows by attaching to the browser as a debugger, intercepting the moment Chrome decrypts protected data, and extracting the master key from memory. That technique enables theft of cookies, sessions, and other sensitive browser data, and the risk extends to other Chromium-based browsers using the same protection model. Together, the disclosures show that Chromium ecosystems face both browser-level persistence abuse and post-compromise data theft, with defenders urged to watch for unusual download-menu behavior, keep browsers updated as fixes arrive, and harden endpoints against infostealer activity.
Jun 29, 2026
Security researchers demonstrated methods to bypass SameSite cookie protections in web applications, enabling successful Cross-Site Request Forgery (CSRF) attacks against a change email function. In one scenario, the application used the default SameSite=Lax setting, which allowed session cookies to be sent in cross-site GET requests during top-level navigation. By manipulating HTTP methods and leveraging the absence of unpredictable tokens, attackers could exploit this configuration to perform unauthorized actions on behalf of users. Another scenario involved SameSite=Strict cookies, where a client-side JavaScript redirect was identified as a potential vector to circumvent the strict cookie policy, again enabling CSRF attacks if exploited correctly. These findings highlight the importance of properly configuring SameSite cookie attributes and implementing robust anti-CSRF tokens in sensitive web application endpoints. The research underscores that even with modern browser protections, creative exploitation of HTTP methods and client-side behaviors can undermine session security, emphasizing the need for defense-in-depth strategies in web application development and testing.
Jul 4, 2026
Chromium fixed **CVE-2026-95344**, a Chrome DevTools vulnerability that could let a malicious extension execute JavaScript inside another extension's content-script isolated world. The attack combined a time-of-check/time-of-use flaw in DevTools keyboard-shortcut forwarding with insufficient authorization for evaluation in a debugger-selected call frame. An attacker could pause execution, select a victim extension's frame, and invoke victim-scoped APIs, including `chrome.storage.local`; the issue was demonstrated against MetaMask. Chromium's DevTools frontend changes validate forwarded shortcuts and block ExtensionServer evaluation while paused, with release notes planned for Chrome M154.
Sep 23, 2026