Pin Microsoft Teams attachment fetch DNS [AI] by pgondhi987 · Pull Request #87567 · openclaw/openclaw

pgondhi987 · 2026-05-28T07:35:29Z

Summary

Route Microsoft Teams attachment fetches through the SDK SSRF guard so DNS validation is pinned into the request dispatcher.
Keep Teams-specific auth fallback and direct save behavior while ensuring unused non-OK guarded responses are canceled.
Update attachment regression tests to assert pinned dispatcher usage and current guard failures.

AI-assisted: Yes

Verification

CI=1 OPENCLAW_VITEST_MAX_WORKERS=1 timeout 300 node scripts/run-vitest.mjs run extensions/msteams/src/attachments/shared.test.ts extensions/msteams/src/attachments/bot-framework.test.ts extensions/msteams/src/attachments.test.ts
node scripts/run-oxlint.mjs extensions/msteams/src/attachments/shared.ts extensions/msteams/src/attachments/shared.test.ts extensions/msteams/src/attachments/bot-framework.ts extensions/msteams/src/attachments/bot-framework.test.ts extensions/msteams/src/attachments/download.ts extensions/msteams/src/attachments/remote-media.ts
git diff --check

Real behavior proof

Behavior addressed: Microsoft Teams attachment downloads now use guarded fetches that pin validated DNS results into the request dispatcher before connecting.
Real environment tested: Local OpenClaw worktree on Linux with Node 24.15.0.
Exact steps or command run after this patch: Focused Vitest command listed above against the Teams attachment downloader tests.
Evidence after fix: 3 test files passed, 89 tests passed.
Observed result after fix: Attachment fetch tests preserve auth fallback, redirect handling, and direct save behavior while asserting pinned dispatcher usage.
What was not tested: Live Microsoft Teams attachment download against a real tenant.

clawsweeper · 2026-05-28T07:37:00Z

Codex review: needs real behavior proof before merge. Reviewed May 29, 2026, 1:46 AM ET / 05:46 UTC.

Summary
The PR routes Microsoft Teams attachment downloads through the shared pinned SSRF guarded fetch path, adds guarded Authorization redirect retention, gates dispatcher-aware custom fetch hooks, and updates focused Teams/net tests.

PR surface: Source +155, Tests +110. Total +265 across 12 files.

Reproducibility: yes. at source level: current main validates Teams attachment DNS and then performs a separate no-dispatcher fetch, while the PR routes that path through the pinned SSRF guard. I did not run a live DNS-rebinding or Teams tenant reproduction.

Review metrics: 1 noteworthy metric.

Fetch contract options: 2 added. The PR adds fetchFnSupportsDispatcher on Teams attachment helper params and retainAuthorizationRedirectHostnameAllowlist on the guarded fetch option surface, which are compatibility and security-boundary surfaces maintainers should notice before merge.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦪 silver shellfish
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof from a real setup is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P1] Add redacted real behavior proof for a live Teams attachment download or a local DNS-rebinding/guarded-fetch diagnostic that shows pinned dispatcher use.
[P1] Have a maintainer/security owner explicitly accept the fail-closed custom fetch hook behavior and the allowlisted HTTPS Authorization redirect retention.

Proof guidance:

[P1] Needs real behavior proof before merge: The PR body and comments provide focused test/CI/GHSA dry-run output, but no live Teams attachment run or live DNS-rebinding/diagnostic proof; add redacted terminal/log/live-output proof, then updating the PR body should trigger re-review or a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

[P1] The proof in the PR is focused tests, CI, and GHSA dry-run output only; it does not show a live Teams tenant download or a live DNS-rebinding/diagnostic run that proves the actual connection uses the pinned dispatcher.
[P1] Unsupported custom Teams attachment fetch hooks now fail closed unless they opt into dispatcher support, which is security-favorable but can break existing custom test or integration hooks at runtime.
[P1] The PR intentionally restores Authorization across HTTPS redirects to allowlisted hosts in the shared guard for Teams, so maintainers should explicitly accept that credential-forwarding boundary before merge.

Maintainer options:

Require real diagnostic proof (recommended)
Ask for a redacted live Teams attachment run or a local DNS-rebinding/guarded-fetch diagnostic that shows the actual fetch path using the pinned dispatcher before merge.
Accept fail-closed custom hooks
Maintainers can intentionally accept that custom Teams attachment fetch hooks must declare dispatcher support and unsupported hooks will stop downloading attachments instead of bypassing DNS pinning.
Pause for security-owner sign-off
Pause this PR if the Authorization redirect-retention and DNS-pinning tradeoff needs explicit security-owner approval beyond source-level tests.

Next step before merge

[P1] Protected maintainer/security-boundary handling and missing non-mock proof require human review; I found no narrow code defect for an automated repair lane.

Security
Cleared: The diff strengthens Teams attachment SSRF protection by routing through the pinned guard and keeps Authorization retention limited to configured HTTPS allowlisted redirects; I found no concrete supply-chain or security regression in the patch itself.

Review details

Best possible solution:

Land the shared-guard fix after maintainer/security review accepts the fail-closed custom-fetch behavior and the PR has redacted real diagnostic proof or an explicit maintainer proof override for the GHSA path.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level: current main validates Teams attachment DNS and then performs a separate no-dispatcher fetch, while the PR routes that path through the pinned SSRF guard. I did not run a live DNS-rebinding or Teams tenant reproduction.

Is this the best way to solve the issue?

Yes, source-wise this is the narrow maintainable direction because it reuses the shared SSRF guard instead of duplicating pinning in the Teams plugin. The merge still needs maintainer acceptance for the fail-closed custom-fetch behavior and real diagnostic proof or an explicit proof override.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against f5e1fe9755c3.

Label changes

Label changes:

add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body and comments provide focused test/CI/GHSA dry-run output, but no live Teams attachment run or live DNS-rebinding/diagnostic proof; add redacted terminal/log/live-output proof, then updating the PR body should trigger re-review or a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
remove rating: 🌊 off-meta tidepool: Current PR rating is rating: 🦐 gold shrimp, so this older rating label is no longer current.

Label justifications:

P2: This is a bounded Microsoft Teams attachment security hardening PR with meaningful channel impact but no evidence of an active core-wide outage in this review.
merge-risk: 🚨 compatibility: Unsupported custom Teams attachment fetch hooks now fail closed unless they explicitly support dispatcher injection.
merge-risk: 🚨 message-delivery: A regression in this path can suppress or drop Teams attachment media from inbound messages.
merge-risk: 🚨 security-boundary: The diff changes SSRF DNS pinning and Authorization forwarding behavior on untrusted attachment URLs.
rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body and comments provide focused test/CI/GHSA dry-run output, but no live Teams attachment run or live DNS-rebinding/diagnostic proof; add redacted terminal/log/live-output proof, then updating the PR body should trigger re-review or a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

PR surface:

Source +155, Tests +110. Total +265 across 12 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	7	191	36	+155
Tests	5	146	36	+110
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	12	337	72	+265

What I checked:

Repository policy applied: Root AGENTS.md and scoped extensions/plugin-sdk/plugins guides were read; their compatibility, security-boundary, plugin-SDK, and PR proof guidance applies to this Teams attachment and SSRF guard change. (AGENTS.md:1, f5e1fe9755c3)
Current vulnerable shape on main: Current main's Teams safeFetch validates allowlists and DNS, then calls fetch without a pinned dispatcher on the no-dispatcher path, leaving DNS validation and connection as separate steps. (extensions/msteams/src/attachments/shared.ts:586, f5e1fe9755c3)
Shared guard provides pinning: fetchWithSsrFGuard resolves each hop, creates a pinned dispatcher, and attaches it to the request before fetching; ssrf.ts builds the dispatcher lookup from the validated address set. (src/infra/net/fetch-guard.ts:501, f5e1fe9755c3)
PR diff uses the shared guard: The PR adds a no-dispatcher safeFetch branch that calls fetchWithSsrFGuard with requireHttps, the Teams media SSRF policy, the Teams resolver, and auth-retention allowlist plumbing. (extensions/msteams/src/attachments/shared.ts:668, a2535485e59f)
PR is live, cleanly mergeable, and protected: The live PR API reports the PR open, mergeable clean, maintainer_can_modify true, and carrying maintainer plus compatibility/message-delivery/security-boundary merge-risk labels. (a2535485e59f)
Mocked verification only: The PR body and later verification comment report focused Vitest, lint, diff-check, GHSA dry-run, autoreview, and CI success, but explicitly say live Microsoft Teams attachment delivery and live authoritative DNS-rebinding were not tested. (a2535485e59f)

Likely related people:

steipete: Local blame in this shallow checkout points current Teams safeFetch and shared guarded-fetch lines to the import/squash commit, and GitHub history shows recent shared media/download and Teams security hardening commits by this handle. (role: recent area contributor; confidence: medium; commits: b2bdad5bee5a, 53d007bc878c, c56b56e514f8; files: extensions/msteams/src/attachments/shared.ts, extensions/msteams/src/attachments/download.ts, src/infra/net/fetch-guard.ts)
sudie-codes: GitHub history shows this handle authored the Node 24 SharePoint media and Bot Framework attachment fix that introduced the no-pinned-dispatcher workaround this PR revisits. (role: prior Teams attachment fix owner; confidence: high; commits: 2084441b51aa, 4fc5016f8fd2, ab9be8dba547; files: extensions/msteams/src/attachments/download.ts, extensions/msteams/src/attachments/bot-framework.ts, extensions/msteams/src/monitor-handler/inbound-media.ts)
eleqtrizit: GitHub history shows recent Bot Framework service URL hardening and media guard work in the same Teams attachment surface. (role: recent Teams attachment/security contributor; confidence: medium; commits: 2c3d7f5badbe, a31cb155611f; files: extensions/msteams/src/attachments/bot-framework.ts, extensions/msteams/src/attachments/shared.ts)
shakkernerd: GitHub history shows recent fetch guard/header normalization work in src/infra/net, which is the shared guard this PR extends for Authorization redirect retention. (role: shared fetch-guard contributor; confidence: medium; commits: 79f21a444267, d52f581f76c2; files: src/infra/net/fetch-guard.ts, src/infra/net/runtime-fetch.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

clawsweeper · 2026-05-28T07:42:18Z

ClawSweeper PR egg: 🎁 locked until real behavior proof passes.

Details

No creature or rarity is rolled until proof passes.
Eggs are collectible flavor only; they do not affect labels, ratings, merge decisions, or automation.

pgondhi987 · 2026-05-28T10:15:15Z

Diff notes

Fix verdict: SOLVES.

The current PR fixes the accepted GHSA root cause for the affected Microsoft Teams attachment paths. The normal no-dispatcher safeFetch path now delegates to fetchWithSsrFGuard, which resolves and validates the hostname and connects through a pinned dispatcher, so Teams media downloads no longer validate one DNS answer and then connect after an unpinned second lookup.

Evidence:

PR extensions/msteams/src/attachments/shared.ts:647 routes no-dispatcher Teams media fetches through fetchWithSsrFGuard with requireHttps: true, maxRedirects: MAX_SAFE_REDIRECTS, the Teams media allowlist converted to an SSRF policy, and the Teams resolver passed as lookupFn.
PR extensions/msteams/src/attachments/shared.ts:478 adds resolveGuardedFetchImpl; dispatcher-aware, global, or mocked fetch hooks can be used, while custom fetch hooks that cannot receive the pinned dispatcher now fail explicitly instead of silently using an unpinned connection.
PR src/infra/net/fetch-guard.ts:538 resolves each redirect-hop hostname with resolvePinnedHostnameWithPolicy, src/infra/net/fetch-guard.ts:542 creates a pinned dispatcher, and src/infra/net/fetch-guard.ts:550 attaches it to the actual fetch request.
src/infra/net/ssrf.ts:547 validates resolved DNS answers, src/infra/net/ssrf.ts:580 returns the pinned address set, and src/infra/net/ssrf.ts:635 builds the dispatcher lookup from that pinned set.
The affected Teams entry points propagate the guarded fetch behavior through Bot Framework, Graph media, and generic attachment download paths, so the previously listed callers no longer use the vulnerable no-pinning path.
Regression tests assert dispatcher injection for safeFetch, explicit failure for unsupported custom fetch functions, private-IP redirect blocking, Authorization redirect behavior, Bot Framework dispatcher-aware fetch hooks, and HTTPS-only Authorization restoration in the shared fetch guard.

Plain-language post description

A Microsoft Teams attachment link could appear safe when OpenClaw checked it, then point somewhere different when OpenClaw actually downloaded it. In a cloud deployment, that could let a malicious Teams attachment make the OpenClaw process contact private internal services, such as cloud metadata endpoints, that should not be reachable through an incoming message.

The PR changes Teams attachment downloads to use OpenClaw's guarded fetch path, which checks the destination and pins the connection to the checked address before downloading. It also fails closed for custom fetch hooks that cannot receive the pinned connection, while preserving Teams redirect and Authorization behavior for explicitly allowed hosts.

Change Impact Analysis

Change scope: Targeted
Regression risk: Medium
Change path: Standard fix

The fix is limited to Teams attachment fetching plus additive options in the shared fetch guard and Teams fetch helpers. It preserves existing config defaults, CLI behavior, wire formats, manifests, and persisted data. Normal Teams attachments should continue to work, while attachment URLs that resolve or redirect to private/internal destinations are blocked.

Impact reasons:

The affected production surface is Microsoft Teams media download handling.
The shared fetch-guard change is additive and default-off for existing non-Teams callers.
Existing Teams media allowlist defaults are preserved.
Dispatcher-aware, global, and mocked fetch hooks can still be used; unsupported custom hooks now fail closed rather than bypass DNS pinning.
Regression risk is medium because the PR changes fetch, redirect, Authorization, dispatcher, and response cleanup behavior on a user-visible attachment path.

Verification notes:

Root-cause review found Teams no-dispatcher media fetches now route through fetchWithSsrFGuard with pinned DNS.
Backward compatibility review found no API, CLI, config, schema, serialization, or public SDK break.
Regression tests cover dispatcher injection, explicit failure for unsupported custom fetch functions, private-IP redirect blocking, Bot Framework dispatcher-aware hooks, and Authorization retention/stripping across redirects.
The tests are mocked rather than a live DNS-rebinding environment, so the strongest proof is source-level use of the pinned SSRF guard.

Caveats

Residual risks:

The existing hasDispatcher branch still trusts an already supplied dispatcher, but the reported production callers do not enter that branch without an upstream guard.
Custom non-dispatcher-aware fetch hooks now fail closed unless callers opt in with fetchFnSupportsDispatcher; this avoids the root-cause bypass but is a behavior/compatibility concern handled by separate gates.
The tests are mocked rather than a live authoritative DNS-rebinding setup; the strongest proof is the source-level use of OpenClaw's pinned SSRF guard.

Automated review gate:

Bot-only unresolved actionable comments: 0
No unresolved/unreplied actionable bot comments.

Gate blockers:

None

Backward Compatibility Review

Compatibility verdict: PASS.
Informational only: this section does not block GHSA PR gate outcome.

The PR remains backward-compatible for API, CLI, config, and wire/schema contracts. It changes Teams attachment fetch internals, adds optional fetch-guard and Teams fetch-helper parameters, and preserves existing Teams media allowlist defaults; no required config changes, manifest changes, protocol changes, or persisted data shape changes are introduced.

Blocking concerns:

(none)

Notes:

The new retainAuthorizationRedirectHostnameAllowlist guarded-fetch option is additive and default-off for existing non-Teams callers.
The new fetchFnSupportsDispatcher Teams option is additive; normal production callers without custom fetch hooks continue through the guarded runtime fetch path.
Existing custom non-mock fetchFn hooks now fail closed unless they opt into dispatcher support, which is a behavior change for internal/test-style callers but prevents fallback to an unpinned fetch path.
Teams attachment URLs resolving or redirecting to private/internal targets now fail closed; this is the intended security behavior change.
Fetch error text or logging may change because failures now come from the shared SSRF guard, but that is not a CLI, config, schema, or wire compatibility break.

Verdict: Legitimate CVE

# Conflicts: # extensions/msteams/src/attachments/shared.test.ts # extensions/msteams/src/attachments/shared.ts

pgondhi987 · 2026-05-29T05:34:00Z

Verification before merge:

Behavior addressed: Microsoft Teams attachment downloads now pin the
DNS answer used for the actual fetch through the shared SSRF guard,
while Bot Framework tokens are only sent to explicitly auth-
allowlisted HTTPS service hosts.
Real environment tested: local source checkout and GitHub Actions PR
CI.
Exact steps or command run after this patch:

git diff --check
pnpm exec vitest run extensions/msteams/src/attachments/ shared.test.ts extensions/msteams/src/attachments/bot- framework.test.ts src/infra/net/fetch-guard.ssrf.test.ts
scripts/pr review-tests 87567 extensions/msteams/src/attachments/ shared.test.ts extensions/msteams/src/attachments/bot- framework.test.ts src/infra/net/fetch-guard.ssrf.test.ts
./auto-pr.sh issue 700 --run-stage ghsa_dry_run
.agents/skills/autoreview/scripts/autoreview --mode branch --base origin/main
Evidence after fix:
Focused Vitest: 3 files and 161 tests passed.
GHSA dry-run: passed with fix_verdict: SOLVES; GHSA real gate: not
run in this dry run.
Review gates: review-pr passed with 0 findings, and autoreview was
clean with no accepted/actionable findings.
PR CI on SHA a2535485e59f7b01171696a7a86fcde1ca478e14: 78 success,
38 skipped, 1 neutral, 0 failed, 0 pending.
Observed result after fix: tests cover dispatcher injection into the
Teams guarded fetch path, private/internal DNS rejection, explicit
failure for unsupported custom fetch hooks, and Bot Framework
Authorization stripping for non-auth-allowlisted media hosts while
preserving auth for smba.trafficmanager.net.
What was not tested: live Microsoft Teams attachment delivery or a
live authoritative DNS-rebinding setup.

RomneyDa · 2026-05-29T05:39:56Z

@clawsweeper re-review

clawsweeper · 2026-05-29T05:39:59Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/26620302711
Updated: 2026-05-29T05:46:26.096Z

steipete · 2026-05-29T08:03:37Z

Verification before merge:

Behavior addressed: Microsoft Teams attachment downloads now route through the shared SSRF guarded fetch path so the validated DNS result is pinned into the dispatcher used for the actual request.

Real environment tested: Local OpenClaw checkout on macOS plus GitHub Actions PR CI for SHA a253548.

Exact steps or command run after this patch:

CI=1 OPENCLAW_VITEST_MAX_WORKERS=1 timeout 300 node scripts/run-vitest.mjs run extensions/msteams/src/attachments/shared.test.ts extensions/msteams/src/attachments/bot-framework.test.ts src/infra/net/fetch-guard.ssrf.test.ts
gh pr checks 87567 --repo openclaw/openclaw --watch=false
git pull --ff-only
gh pr view 87567 --repo openclaw/openclaw --json mergeable,mergeStateStatus,headRefOid

Evidence after fix:

Focused local Vitest passed: 3 test files, 161 tests.
PR checks on SHA a253548 are green for the relevant CI/security lanes, including Real behavior proof, Security High network-ssrf-boundary, Critical Quality network-runtime-boundary, check-prod-types, check-lint, check-test-types, check-guards, build-artifacts, and bundled/channel/plugin contract lanes.
Merge state rechecked after pulling current main: CLEAN / MERGEABLE.

Observed result after fix: Tests cover dispatcher injection in the Teams guarded fetch path, private/internal DNS rejection, explicit fail-closed behavior for unsupported custom fetch hooks, Bot Framework guarded fetch behavior, and HTTPS-only Authorization retention for allowlisted redirects.

What was not tested: Live Microsoft Teams tenant attachment delivery and a live authoritative DNS-rebinding setup. Maintainer landing request accepts the remaining proof gap for this PR.

Route Microsoft Teams attachment downloads through the shared SSRF guarded fetch path so DNS validation is pinned into the dispatcher used for the actual request. Keep Teams auth fallback and allowlisted HTTPS Authorization redirect behavior while failing closed for custom fetch hooks that cannot accept dispatcher injection. Verification: - CI=1 OPENCLAW_VITEST_MAX_WORKERS=1 timeout 300 node scripts/run-vitest.mjs run extensions/msteams/src/attachments/shared.test.ts extensions/msteams/src/attachments/bot-framework.test.ts src/infra/net/fetch-guard.ssrf.test.ts - gh pr checks 87567 --repo openclaw/openclaw --watch=false PR: openclaw#87567

fix: pin msteams attachment fetch DNS

7b65f2f

openclaw-barnacle Bot added channel: msteams Channel integration: msteams size: S maintainer Maintainer-authored PR labels May 28, 2026

fix: preserve guarded auth redirects

b5619fe

openclaw-barnacle Bot added size: M and removed size: S labels May 28, 2026

clawsweeper Bot added the merge-risk: 🚨 security-boundary 🚨 May affect sandboxing, authorization, credentials, or sensitive data. label May 28, 2026

This comment was marked as spam.

Sign in to view

pgondhi987 added 5 commits May 28, 2026 08:18

fix: gate msteams dispatcher fetch hooks

6a12002

fix: reject unpinned msteams fetch hooks

5d0acd9

fix: narrow guarded redirect headers

5096a2a

fix: keep redirected auth on https only

59905d9

fix: preserve wildcard auth redirects

a7744ed

Merge remote-tracking branch 'origin/main' into fix/fix-700

a253548

# Conflicts: # extensions/msteams/src/attachments/shared.test.ts # extensions/msteams/src/attachments/shared.ts

openclaw-barnacle Bot added the extensions: codex label May 29, 2026

RomneyDa added dependency-guard-backfill and removed dependency-guard-backfill labels May 29, 2026

steipete self-assigned this May 29, 2026

steipete merged commit 9497629 into openclaw:main May 29, 2026
151 of 161 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Pin Microsoft Teams attachment fetch DNS [AI]#87567

Pin Microsoft Teams attachment fetch DNS [AI]#87567
steipete merged 8 commits into
openclaw:mainfrom
pgondhi987:fix/fix-700

pgondhi987 commented May 28, 2026

Uh oh!

clawsweeper Bot commented May 28, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 28, 2026

Uh oh!

This comment was marked as spam.

pgondhi987 commented May 28, 2026

Uh oh!

pgondhi987 commented May 29, 2026

Uh oh!

RomneyDa commented May 29, 2026

Uh oh!

clawsweeper Bot commented May 29, 2026 •

edited

Loading

Uh oh!

steipete commented May 29, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

pgondhi987 commented May 28, 2026

Summary

Verification

Real behavior proof

Uh oh!

clawsweeper Bot commented May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clawsweeper Bot commented May 28, 2026

Uh oh!

This comment was marked as spam.

pgondhi987 commented May 28, 2026

Diff notes

Plain-language post description

Change Impact Analysis

Caveats

Backward Compatibility Review

Uh oh!

pgondhi987 commented May 29, 2026

Uh oh!

RomneyDa commented May 29, 2026

Uh oh!

clawsweeper Bot commented May 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

steipete commented May 29, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

clawsweeper Bot commented May 28, 2026 •

edited

Loading

clawsweeper Bot commented May 29, 2026 •

edited

Loading