OpenClaw Tightens Microsoft Teams Shared-Link Host Checks Against Look-Alike Domains
A bare suffix match treated look-alike hosts such as evil1drv.ms as OneDrive and SharePoint share links, routing them into Graph authentication. Merged fixes require a dot boundary, HTTPS, and keep look-alike downloads out of the Graph auth path.
Operators running the Microsoft Teams channel should update to a build that includes pull request #123046. Before it, OpenClaw’s Teams attachment pipeline classified some attacker-chosen hostnames as Microsoft Graph shared links and pushed them through Graph-authenticated download paths that should only ever see genuine 1drv.ms, OneDrive, and SharePoint hosts.
What the code did before the fix
isGraphSharedLinkUrl() decided whether an incoming attachment URL pointed at a Microsoft shared link by checking the hostname against a list of known suffixes using JavaScript’s endsWith(). The check required either an exact host match or any suffix match — with no requirement that the match start on a ., /, or string boundary.
That is the classic bare-suffix bug. A host like evil1drv.ms ends with 1drv.ms; notonedrive.com ends with onedrive.com; fakeonedrive.live.com ends with onedrive.live.com. All three satisfied the old predicate even though none of them is a Microsoft property. (The one benign-looking case, evilsharepoint.com against suffix sharepoint.com, does not actually satisfy a bare endsWith because of the leading evil — the merged tests still cover it, which is the right instinct for boundary regressions.)
The practical consequence was not just misclassification. Once a URL was flagged as a Graph share link, the downloader rewrote the request toward the Graph shares endpoint and fell back to Graph token authentication when that route failed. In other words, a link that merely looked like a shared link could steer the bot’s credentialed request machinery toward infrastructure the operator never approved. The fix’s own regression test makes this explicit: for https://notonedrive.com/direct.pdf, the Graph shares prefix must never be requested, and the file must come back through plain direct fetch instead.
What changed
Three commits landed under PR #123046:
- Dot-boundary matching — the suffix check now compares against
.<suffix>(or an exact host), soevil1drv.msno longer matches1drv.ms. The commit message names the exact bypass cases:evil1drv.ms,notonedrive.com,fakeonedrive.live.com. - HTTPS enforcement — shared-link classification additionally requires the
httpsscheme. - Look-alike download routing tests — new coverage pins that look-alike hosts stay out of both the Graph shares rewrite and the authenticated fallback path, exercising real download flows rather than only the classifier helper.
Why the failure mode matters
This is a credential-routing defect, not a remote-code-execution bug, and it is important to read it that way. The bot did not hand over tokens to the attacker’s server on its own initiative — but it did make attacker-influenced decisions about which endpoints deserve its Microsoft credentials. Any environment where that decision can be steered by inbound message content deserves the same review you would give an outright leak, because it shrinks the distance between a phishing message and your tenant-scoped Graph token. It also degrades availability semantics: legitimate-looking links could be silently rewritten to an endpoint that will 401 them.
Operator actions
- Update the Teams extension/gateway to a build containing #123046 and confirm via changelog or local source that
isGraphSharedLinkUrluses dot-boundary suffix checks. - If you cannot update immediately, treat inbound Teams attachments hosted on non-Microsoft domains with suspicion in automations that auto-fetch links, since older builds classify them more loosely.
- Review gateway logs for past Graph shares requests targeting hosts you do not recognize; those entries are evidence the old path fired on look-alike input.
- Audit other channel extensions for the same pattern —
host.endsWith(suffix)without a boundary check is worth grepping for anywhere else your deployment accepts URLs from messages.
Interpretation note: severity judgments here are ours. The repository carries no published CVE or GHSA for this change; the assessment rests on the merged diff, its tests, and the commit narrative. The original patch was authored August 13, 2026, and the final test-hardening commit landed August 22 before merge.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF