A researcher found PortSwigger disabled a CSRF training lab after claiming Chrome updates made it unsolvable, then tested it themselves across multiple Chrome versions. Their proof-of-concept shows Chrome can still send “Lax-by-default” cookies in cross-site POST requests for ~120 seconds after a cookie is issued or refreshed. This creates a short window attackers can exploit by first triggering a cookie refresh (e.g., via SSO/OAuth) and then immediately performing a CSRF action.
Chrome's SameSite Lax policy is designed to block cookies from being sent in most cross-site requests, including top-level POST requests. However, testing showed that Chrome does not actually enforce this restriction for the first 120 seconds after a cookie is issued. During that short window, a cookie can still be delivered along with a cross-site POST request, effectively bypassing the protection that Lax is meant to provide.
This grace period exists to avoid breaking single sign-on and OAuth flows, which often rely on redirects between sites shortly after login. The tradeoff is that the same window can be used to carry out cross-site request forgery style actions if an attacker can get a victim to act within that timeframe.
A key finding is that refreshing a cookie's value resets the 120-second window entirely, regardless of when the cookie was first created. This means an attacker does not need to wait for a brand-new login. Instead, they can find a gadget on a site, such as an OAuth-based SSO login step, that causes the victim's existing cookie to refresh. Immediately after that refresh, a cross-site request can be sent while the cookie is still inside its fresh grace period.
This turns what might look like a one-time narrow opportunity into a repeatable technique, since any action that refreshes a session cookie can reopen the window.
Several behavioral patterns can signal this type of attempt:
Because this issue relies on timing and user clicks rather than stolen credentials, awareness and caution around unexpected prompts matter more than technical defenses alone. Treat requests to click to verify or continue, especially right after logging into another site, as suspicious. Be cautious with unfamiliar session refresh or SSO re-authentication flows that appear unexpectedly, since these can reset protective windows and enable follow-on actions quickly. This is particularly relevant for users of banking and payment web apps, and for anyone who frequently uses SSO-enabled applications, where a brief lapse in attention could allow an unintended cross-site action to succeed.
Mirage safely runs attacks like this one against your own team, so you find out what happens before a real adversary does.
Chrome does not enforce SameSite Lax restrictions for the first 120 seconds after a cookie is issued, even on top-level POST requests, which can allow cookies to be sent in cross-site requests during that window.
Yes, refreshing a cookie's value resets the 120-second grace window entirely, regardless of when the cookie was originally created, which can be triggered through actions like OAuth-based SSO logins.
An attacker could trick a victim into triggering a cookie refresh, such as through an SSO login flow, then immediately follow up with a cross-site POST request while the cookie is still within its grace period.
The risk applies broadly to anyone using web applications with cookie-based sessions, particularly those using SSO or OAuth flows, with finance and banking web app users highlighted as a notable group.
You just logged into your bank, then another tab says, “Please click to continue.” One click, and Chrome quietly helps send a request as you. Here’s the trick: Chrome’s SameSite Lax has a hidden two‑minute grace window. For about 120 seconds after login, it still sends your fresh cookie on cross‑site POSTs, even when you’re on some random “continue” page. It gets worse: any 'Security check: click to verify your session' can refresh that cookie and reset the two‑minute window. One button can silently 'Refresh Cookie & Send Cross‑Site POST request' in the background. If you just logged in somewhere, treat any new tab saying 'click to continue' or 'verify your session' as suspicious. Your move: close that tab instead of clicking.
This roundup describes several real-world social-engineering and human-abuse techniques, including trojanized “installer” lures (ClickFix), large-scale phone-based investment fraud, and stalkers misusing Chrome Sync after brief physical access. The items include clear workflows that can be turned…
This bulletin describes multiple real-world scams where attackers make fake pages and messages look like routine, trusted experiences (search answers, Google login pop-ups, “giveaways,” and official-sounding calls). Examples include a fake Claude Max giveaway using a convincing fake Google sign-in…
Researchers described an Android Trojan (“RatHat”) that starts with scam texts or malicious ads and tricks people into installing a fake app from a bogus download page. After installation, it pressures victims to grant Accessibility permissions using fake excuses or incentives, then uses those…
Researchers tied Mirage Kitten to a job-recruiting scam that targets developers via LinkedIn and job platforms. Victims are sent a “technical assessment” ZIP file hosted on legitimate cloud storage; running the project silently installs a remote-access trojan (NodeRabbit) that lets attackers…
Sophos reports real incidents where attackers impersonated well-known AI brands (especially Claude) to trick people into installing malware. The lures included polished fake installer pages that instruct victims to copy/paste commands, and browser extensions that look legitimate via high ratings…
Attackers are taking over hotel and conference Wi‑Fi gateways and changing DNS settings so travelers are silently redirected to fake Microsoft 365 sign-in pages. Victims are then tricked into completing a device-code login that grants attackers a legitimate session token, often bypassing MFA. This…
