The incident did not involve the Microsoft Defender Antivirus client built into Windows. It affected Safe Links, the cloud-based link protection service in Microsoft Defender for Office 365 that checks URLs in email, Microsoft Teams, and supported Office applications. That distinction matters for desktop administrators: a Windows Security scan, a Defender Antivirus signature update, or a local endpoint exclusion would not have fixed this particular block.
Windows Report initially described the issue while Microsoft was still investigating it. At that point, affected users received an “Opening this website might not be safe” warning when selecting some Google Search links, and copying the URL into a browser did not bypass the block. Microsoft later confirmed that a faulty security classification—not a Google-side compromise or a newly discovered malicious campaign—was responsible.
MO1465962 was a short-lived cloud classification failure
Microsoft’s final notice said “some users” could not open Google Search links from email and Teams messages. The company classified MO1465962 as an advisory, a category generally used for more limited service impact, and did not publish a tenant count, regional breakdown, or list of the specific Google URL patterns caught by the detection.
BleepingComputer first reported Microsoft’s acknowledgement of the incident at 10:30 AM UTC on September 2. The later final record shows the underlying impact window began earlier, at 2:53 AM UTC, and ended at 10:17 AM UTC. In other words, organizations could have encountered blocked links for about seven hours and 24 minutes even though public reporting first surfaced after Microsoft had already been working the problem.
Microsoft’s stated root cause was unusually narrow: “an inaccurate security classification” caused legitimate Google Search URLs to be identified as malicious. The company has not publicly detailed whether the faulty reputation decision applied to a redirect format, query-string pattern, geographic endpoint, or another characteristic of the links. That missing technical detail makes it difficult for administrators to determine whether a strange-looking block seen outside that September 2 window was part of MO1465962 or a legitimate Safe Links detection.
The important operational conclusion is straightforward: this was a false positive in Defender for Office 365’s URL classification service, and Microsoft says the classification was corrected. It was not evidence that Google Search had been broadly marked unsafe or that the affected tenants had suffered an endpoint infection.
Why pasting the link into a browser still failed
Safe Links does more than replace visible hyperlinks with a Microsoft protection URL in email. Microsoft’s product documentation says the service scans inbound URLs during mail flow and also performs a time-of-click check when a recipient opens a link. That design is intended to stop a link that looked harmless when delivered but later redirects to phishing or malware infrastructure.
It also explains the behavior administrators found confusing during MO1465962. A user could copy the original Google Search URL from a message and paste it directly into a browser, yet still receive the Safe Links warning. The reputation decision was being applied as part of the protection flow, rather than merely being attached to one rewritten email hyperlink.
Safe Links can protect links in Exchange Online email, Teams chats and channels, and supported Office apps. Microsoft’s documentation also notes that Safe Links may be provided through built-in protection presets for licensed Defender for Office 365 organizations even when an administrator has not built a custom Safe Links policy from scratch. An organization therefore could have been affected without recently changing a policy or deploying a local client update.
The same centralized architecture is why the incident ended without an on-premises patch, Windows restart, or Outlook update. Microsoft fixed the cloud-side classification. It also means that temporarily weakening Safe Links would have been a poor response to a problem that lasted only hours: disabling time-of-click checks trades a known availability nuisance for a real reduction in phishing protection.
Defender and Sentinel alerts need historical triage, not blanket suppression
Microsoft warned that the bad classification could generate related alerts and incidents in both the Microsoft Defender portal and Microsoft Sentinel. For security operations teams, the direct cost was not limited to people who could not open search results. A routine web action could resemble a malicious-link event in dashboards, queues, hunting results, or automated incident workflows.
As of September 16, 2026, those alerts should be treated as historical noise only when they match the known incident: legitimate Google Search URLs, Safe Links activity, and the September 2 impact period. A Defender or Sentinel detection involving a Google-branded domain outside that narrow context still deserves normal validation. Google domains, redirectors, and compromised accounts can all be abused in real phishing chains; “it looks like Google” is not a triage verdict.
Administrators reviewing the episode should preserve the records long enough to document why affected events were closed. They should also check whether Sentinel automation rules, ticketing integrations, or user-notification workflows generated unnecessary cases during the incident window. Closing individual false positives with an incident reference is preferable to creating a broad suppression rule for Google-related URLs.
Microsoft’s Safe Links documentation contains another trap for rushed remediation: adding an address to the “Do not rewrite” list does not necessarily stop a URL from being blocked at click time. Microsoft specifically says that exempted links may still be evaluated by Safe Links, and points administrators to the Tenant Allow/Block List for URLs confirmed clean. In this case, though, a permanent allow entry for wide Google Search patterns would have been an overreaction to a fixed classification issue and could have created a longer-lived blind spot.
What IT teams should verify now
There is no Microsoft-issued client patch or configuration change associated with MO1465962. The appropriate post-incident task is confirmation and cleanup:
- Confirm that previously affected Google Search links now open normally from Exchange Online mail and Teams for users covered by Safe Links.
- Review Defender portal and Microsoft Sentinel detections generated between 2:53 AM and 10:17 AM UTC on September 2, 2026, and document the false-positive rationale where the URLs match the incident.
- Remove any emergency Safe Links bypass, custom allow entry, or temporary user guidance that was created solely for this outage.
- Keep Safe Links enabled, including time-of-click protection, unless a separate and current business requirement supports a controlled policy change.
Microsoft says it is reviewing its URL reputation classification processes to prevent similar false positives. That is the only forward-looking remediation the company has disclosed. It has not published the faulty indicator, a postmortem explaining how it reached production, or a broader scope assessment.
For affected organizations, the practical outcome is that normal access should already be restored. The remaining work is administrative: clear the alert residue, reverse any improvised exceptions, and ensure a seven-hour cloud reputation mistake does not become a permanent hole in the organization’s link defenses.