fix: Teams Graph and media work with RFC2544 proxy DNS#107164
fix: Teams Graph and media work with RFC2544 proxy DNS#107164galiniliev wants to merge 3 commits into
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed July 25, 2026, 4:33 PM ET / 20:33 UTC. ClawSweeper reviewWhat this changesThe PR adds host-scoped RFC2544 benchmark-range SSRF exceptions for Microsoft Graph requests and allowlisted Microsoft Teams media downloads, with focused regression assertions. Merge readiness⛔ Blocked until real behavior proof from a real setup is added - 4 items remain Keep this PR open. The patch stays within the Microsoft Teams plugin and appears to preserve hostname restrictions while permitting the RFC2544 range only for approved Graph or media hosts, but it still has no after-fix host-proxy or Teams runtime evidence; focused Vitest output is supplemental only. The existing Priority: P2 Review scores
Verification
How this fits togetherThe Microsoft Teams plugin makes guarded outbound requests to Microsoft Graph and approved attachment hosts. Its SSRF policy validates the resolved destination before the request proceeds, so the policy controls whether proxied DNS results can reach the configured egress path. flowchart LR
A[Teams operation or attachment] --> B[Teams plugin request builder]
B --> C[Approved Graph or media host]
C --> D[Host-scoped SSRF policy]
D --> E[DNS resolution and proxy egress]
E --> F[Microsoft Graph or media response]
F --> G[Teams plugin result]
Decision needed
Why: The code changes a security boundary: whether RFC2544 proxy DNS is an acceptable exception for approved Microsoft endpoints is a maintainer policy decision, not something focused mocks can settle. Before merge
Agent review detailsSecurityNone. PR surfaceSource +27, Tests +41. Total +68 across 4 files. View PR surface stats
Review metricsNone. Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Retain the narrow Teams-plugin policy design, add redacted after-fix evidence from an RFC2544 DNS plus host-proxy deployment for both a Graph request and an allowlisted media download, then review the rebased merge result. Do we have a high-confidence way to reproduce the issue? No, not at runtime. The source path and focused mocks clearly establish where RFC2544 DNS results are rejected, but neither the issue nor this PR provides a current after-fix Teams or host-proxy execution. Is this the best way to solve the issue? Yes, conditionally. Keeping the exception in the Teams plugin and binding it to existing hostname restrictions is the narrow maintainable fix, provided real proxy-path evidence confirms the security boundary. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against d8f099ebede3. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
History |
Closes #107163
What Problem This Solves
Fixes an issue where Microsoft Teams plugin users in host-proxied deployments could have Graph requests and media downloads blocked when DNS resolves allowed external hosts to RFC2544 fake-IP addresses before egress interception.
Why This Change Was Made
The Teams plugin now passes a host-scoped SSRF policy with
allowRfc2544BenchmarkRangefor known Microsoft Graph hosts, and media downloads add the same RFC2544 opt-in only when the configured media host suffixes produce an actual hostname allowlist. The change stays in the Teams plugin boundary and does not allow arbitrary private-network targets.User Impact
Teams Graph-backed operations and attachment/media handling can work in RFC2544 fake-IP proxy environments while keeping the existing hostname restrictions for Graph and media URLs.
Evidence
Behavior addressed: Microsoft Teams Graph and media guarded fetches rejected RFC2544 fake-IP DNS results before host-proxied egress could intercept the request.
Real environment tested: Local OpenClaw worktree with the Microsoft Teams extension Vitest config. Remote Blacksmith Testbox was attempted but blocked because the installed Crabbox binary reported version
0.12.0, while this repo requires Crabbox>=0.22.0for the Blacksmith Testbox provider.Exact steps or command run after this patch:
node scripts/run-vitest.mjs extensions/msteams/src/graph.test.ts extensions/msteams/src/attachments/shared.test.tsandgit diff --check.Evidence after fix:
[test] starting test/vitest/vitest.extension-msteams.config.ts RUN v4.1.9 /home/galini/GitHub/worktrees/bug-055-msteams-rfc2544-policy Test Files 2 passed (2) Tests 78 passed (78) Start at 05:21:03 Duration 11.99s (transform 7.89s, setup 887ms, import 12.32s, tests 342ms, environment 0ms) [test] passed 1 Vitest shard in 17.34sObserved result after fix: The focused Teams tests pass, including assertions that relative Graph requests and absolute Graph pagination URLs carry a Graph-host-scoped RFC2544 policy, non-Graph absolute URLs do not receive that policy, media suffix allowlists add the RFC2544 opt-in, and wildcard media allowlists still return no SSRF policy.
What was not tested: No live Microsoft Teams tenant or host-proxied container was available, and no raw failed gateway run was present in the bug bundle. Remote Testbox proof was blocked by the local Crabbox version mismatch described above.
Before evidence:
Current-main source proof before the patch: extensions/msteams/src/graph.ts requestGraph called fetchWithSsrFGuard without a policy. extensions/msteams/src/graph.ts fetchGraphAbsoluteUrl called fetchWithSsrFGuard without a policy. extensions/msteams/src/attachments/shared.ts resolveMediaSsrfPolicy returned only buildHostnameAllowlistPolicyFromSuffixAllowlist(allowHosts).