Microsoft Defender for Office 365 started blocking ordinary Google search result links this morning, tagging them as malicious and stopping anyone from clicking through. Microsoft confirmed the false-positive issue under incident ticket MO1465962 shortly after 10:30 AM UTC on September 2, hours before this piece went up, and admitted the cause is a bad security classification, not a real threat.
The warning itself is blunt: "Opening this website might not be safe." It shows up wherever Defender's Safe Links feature rewrites and checks a URL before letting a user open it, which for most Microsoft 365 tenants means every link inside Outlook, Teams and OneDrive gets run through the same broken check. Copying the raw Google URL and pasting it straight into a browser doesn't help either. Bleeping Computer, which first reported the incident, notes there's no user-side workaround at all right now.
RelatedvCenter's 9.8 Flaw Was Exploited Five Days After Disclosure
What is Defender actually getting wrong?
Safe Links doesn't just scan links once. It rewrites every URL a user clicks through a Microsoft-hosted redirector, checks that destination in real time against a threat classification model, and either forwards the click or throws up a warning. Somewhere in the last update to that classifier, ordinary google.com search-result URLs, the kind that carry a long string of tracking parameters after the domain, started scoring as malicious. Microsoft's own statement calls it "an inaccurate security classification," which is corporate-speak for a false positive baked into the detection model itself rather than a one-off glitch on a single tenant.
The blast radius goes beyond the click warning. The same bad classification is also generating alerts inside Microsoft Sentinel, so security teams watching their SOC dashboards are seeing a flood of "malicious URL click" incidents that don't correspond to any actual attack. Anyone triaging alerts today has to manually separate real threats from noise generated by Microsoft's own tooling, which is its own kind of damage: alert fatigue is exactly the condition that lets a genuine incident slip through unnoticed.
Has this happened before?
Yes, and the repeat is the more interesting part of the story. In March 2023, Defender for Office 365 went through almost the identical failure mode under a different ticket, DZ534539, misflagging links to Zoom and Google after a change to the SafeLinks detection logic. Microsoft's fix that time was to revert the offending update. Three and a half years later, a near-identical classification error is hitting the same feature, on the same class of target (a mainstream, high-traffic domain), which says the underlying detection pipeline still doesn't have a reliable guardrail against shipping a bad model update straight to production traffic.
Who gets hit by this?
Any organization on Microsoft 365 with Defender for Office 365 and Safe Links turned on, which is most enterprise and education tenants running Microsoft's own email security rather than a third-party gateway. That covers a lot of ground: employees clicking a colleague's shared search link in Teams, students following a link in a school email, security analysts trying to figure out why their queue just filled up with alerts about Google. The severity is closer to "annoying and disruptive" than "dangerous," since nothing is actually being exploited, but for organizations that lean on Safe Links as a hard gate rather than just a warning, legitimate work traffic is getting stopped cold.
RelatedShieldBreak Zero-Day Bypasses Microsoft's Defender Patch
What should Microsoft 365 admins do while this is unresolved?
Don't chase individual blocked links, that's a losing game while the underlying classifier is still misfiring. Instead, flag MO1465962 in your own tenant's Service Health dashboard so you get Microsoft's status updates directly rather than secondhand. If your SOC uses Sentinel, add a filter or note for analysts so a spike in "malicious URL" alerts referencing google.com domains gets triaged as known noise rather than escalated as a live incident. And resist the urge to loosen Safe Links policy tenant-wide to work around the block. A temporarily annoying false positive is a much smaller problem than an actually-relaxed link-scanning policy that outlives the fix.
- The fix timeline. Microsoft's March 2023 version of this bug was resolved same-day by reverting the classifier update, so a similarly fast turnaround is plausible here.
- Whether other domains get swept in. The 2023 incident wasn't limited to one site, Zoom got caught too. If Google is the first domain reported rather than the only one, expect more complaints to surface through the day.
- Sentinel alert volume. Any SOC that doesn't account for the false positive risks real alerts getting lost in the noise until Microsoft ships a fix.
Our take
The technical fix here is probably straightforward, Microsoft's own history with this exact bug suggests a rollback fixes it within hours, not days. The more interesting problem is that the same failure mode surfaced again after three and a half years, on the same feature, against the same category of target. Security products live or die on precision, and a threat classifier that occasionally flags Google as malware erodes trust in every warning it produces afterward, including the real ones. If you administer Defender for Office 365, today's incident is a good prompt to check how your team distinguishes a genuine Safe Links block from a classifier hiccup, because based on the track record, this won't be the last time it happens.
Original analysis by GenZTech Team. Sources: BleepingComputer.