On September 2, 2026, "Safe Links" in Microsoft Defender for Office 365 misclassified legitimate Google search links as malicious URLs, blocking access for some users. Microsoft said it resolved the issue by the following day, September 3, but the same classification also triggered alerts in the Defender portal and Microsoft Sentinel. The affected feature is not the antivirus function built into Windows, but the cloud-based link inspection that protects corporate email, Teams, and similar services. Why would legitimate Google URLs need to be scrutinized at all, and how did a single misclassification spread across multiple operational dashboards? The answer lies in the current phishing landscape, where even the redirect features of trusted services get exploited in attacks.
The Misclassification That Blocked Google Search Links Has Been Resolved
According to a Microsoft service notice reviewed by BleepingComputer, the company became aware of the issue, tracked as "MO1465962," at 10:30 UTC on September 2. Affected users who tried to open Google search URLs saw a warning stating, "It may not be safe to open this website." Even copying the link and pasting it into a browser did not bypass the warning.
Beyond preventing users from reaching search results, the issue also affected administrators. Because the URLs were incorrectly flagged as threats, related alerts and incidents could be generated in both the Microsoft Defender portal and Microsoft Sentinel. In practice, this created both an access disruption and an added burden on security staff investigating false alarms.
Microsoft attributed the cause to an "inaccurate security classification," and in a September 3 update, BleepingComputer added that Microsoft confirmed the issue had been resolved. However, Microsoft also noted that some effects could linger in certain environments until the fix fully propagates across the service infrastructure. The company has not disclosed which regions or organizations were affected, nor the number of users or URLs involved. As of September 5, the issue should be treated as resolved.
Safe Links Re-evaluates URLs at the Moment of Click
Safe Links inspects URLs contained in incoming email at the time of delivery and, by default, rewrites them to point to a Microsoft inspection URL. When a user later clicks the link in email, Teams, or a supported Office app, the system re-evaluates it using the most current assessment available at that moment. This design accounts for cases where a site was safe when the email arrived but was later compromised or turned into an attack page.
The evaluation draws on more than one signal. According to Microsoft's public documentation, Defender for Office 365 uses machine learning to examine message headers, body content, and URLs. URL evaluation also incorporates dynamic analysis in a sandboxed environment and reputation data from sources outside Microsoft. URLs without an existing valid reputation are analyzed asynchronously, and suspicious links or download targets become subject to real-time inspection.
Redirect destinations also matter. According to Microsoft Graph documentation, dynamic analysis of a single URL can trigger further analysis, pulling in URLs not directly written in the email as part of a "chain of analysis." Even if the visible URL belongs to a safe, major site, if it redirects to a different host, the behavior of the final destination must also be verified.
This same mechanism can become a pathway for false positives to spread. When Safe Links determines a URL is malicious, it blocks the user's click, and that same detection result also generates alerts for administrators. In this incident, the link being blocked, the Defender alert, and the Sentinel incident all appeared together—not because separate failures coincidentally overlapped, but as a direct consequence of a design that uses the same URL judgment for both protection and monitoring.
Why Google URLs Can't Simply Be Whitelisted
It's also not possible to simply decide that any URL displaying a Google domain is automatically safe. Prior to this incident, Microsoft had already documented attacks that exploited legitimate Google functionality as a stepping stone. Because legitimate search results and attacker-controlled redirects can coexist within the same service family, allowlisting based on hostname alone is insufficient.
| Case documented by Microsoft | Surface-level trust signal | Actual behavior | Relationship to this incident |
|---|---|---|---|
| 2019 Google search result abuse | Legitimate google.ru search URL | Region-specific poisoned search results redirected through an attacker-controlled site to phishing | Past precedent showing why Safe Links needs to inspect beyond the search URL itself |
| March 2026 OAuth redirect abuse | Legitimate Google/Microsoft authentication URL | Standard error-redirect functionality was exploited to redirect to an attacker-controlled site | Example showing that even trusted authentication hosts can become dangerous depending on parameters and redirect targets |
| September 2026 MO1465962 | Legitimate Google search URL | Safe Links misclassified it as malicious and blocked it | A separate false positive, unrelated to the prior attacks; the specific point of misclassification remains undisclosed |
In the 2019 attack, the URL embedded in the email body was a legitimate Google search URL. Attackers manipulated search results in specific regions so that a crafted page appeared at the top, from which victims were directed to a phishing page. A separate campaign that Microsoft reported in March 2026 exploited OAuth's legitimate error-handling process. Attackers specified their own site as the redirect destination following an authentication failure, using trusted authentication URLs from providers like Google as the entry point.
Neither case is evidence of what caused this particular false positive. But they do explain why Safe Links cannot adopt a rule as simple as "allow it because it's Google." The defensive system must combine the complete URL, its parameters, the chain of redirects, and the behavior of the final destination to make a determination. If any part of that process misclassifies a batch of legitimate URLs as malicious, the impact scales with how widely the service is used.
Root Cause Undisclosed; Broad Exceptions Create New Risks
Microsoft has not disclosed which specific evaluation signal caused the misclassification this time. Machine learning models, reputation rules, sandbox analysis, and external reputation sources all appear in public documentation, but there is no basis for narrowing the cause of MO1465962 to any single one of them. Explanations such as "the AI learned to treat Google as malware" would be speculation. The only officially confirmed root cause remains the "inaccurate security classification."
When administrators identify a false positive, they can submit the URL as legitimate through the Microsoft Defender portal. Microsoft states that submitted items undergo both an updated URL reputation check and dynamic analysis, as well as human review. Recording the warning screen and the time it occurred, then submitting it along with the Defender or Sentinel identifiers from the original message, makes it easier to pinpoint the specific misjudgment than creating a broad exception would.
Tenant-level URL allow entries require caution. According to Microsoft's documentation, an allowed URL overrides all filters related to that URL at the moment of the click. Administrators can set allow entries to expire after a maximum of 30 days, but whitelisting an entire Google domain risks overlooking the kind of legitimate-feature abuse documented in 2019 and March 2026. Since this particular outage has already been resolved, it provides no justification for maintaining a permanent, broad allowlist.
When false alarms recur, telling users to simply "ignore the warning if it's Google" is also risky. The first step should be confirming whether the timing and URL match the MO1465962 incident, then handling it as an isolated false positive. If Microsoft explains how it will prevent recurrence, what matters is not the conclusion that "the classification was fixed," but which specific evaluation signal was wrong—and what verification steps have been added before any fix is rolled out broadly.