fix(security): validate inbound Slack file URLs against SSRF

[zapabob]

Summary

When Hermes receives a file on Slack it downloads the bytes server-side using the bot token. The two inbound download helpers followed redirects without validating the destination, while the outbound send_image path in the same adapter already validates URLs and re-checks every redirect hop. Because the request carries an Authorization: Bearer <bot-token> header and follow_redirects=True, a URL that resolves to — or 3xx-redirects into — a private/internal address could be used to reach internal services and/or egress the bot token to a non-Slack host (CWE-918, SSRF).

Root cause

gateway/platforms/slack.py — _download_slack_file and _download_slack_file_bytes:

async with httpx.AsyncClient(timeout=30.0, follow_redirects=True) as client:
    response = await client.get(url, headers={"Authorization": f"Bearer {bot_token}"})

No is_safe_url pre-flight and no redirect guard, unlike the guarded outbound path and base.cache_image_from_url.

Fix

Apply the existing, canonical pattern to both inbound sibling paths:

• is_safe_url(url) pre-flight (raises ValueError before any network I/O when the target is private/internal),
• event_hooks={"response": [_ssrf_redirect_guard]} so each redirect hop is re-validated.

This reuses tools.url_safety.is_safe_url and gateway.platforms.base._ssrf_redirect_guard — the same helpers the outbound path uses — so behavior stays consistent across the adapter.

Tests

tests/gateway/test_slack_download_ssrf.py (parametrized over both helpers):

• unsafe/internal URL is rejected with ValueError before any HTTP client call,
• the AsyncClient is constructed with _ssrf_redirect_guard registered on the response hook.

Impact

Legitimate Slack file URLs (files.slack.com etc.) are unaffected. Only requests targeting private/internal/metadata addresses or redirecting into them are blocked. No change to prompt cache, role alternation, or config.

[liuhao1024]

Verification: LGTM ✅

Reviewed the diff and tests. The SSRF guard is correctly applied to both _download_slack_file and _download_slack_file_bytes — these are the inbound download paths that attach the bot token and were missing the protection that the outbound send_image path already has.

Checked:

• is_safe_url() pre-flight check on both methods
• _ssrf_redirect_guard wired into httpx.AsyncClient event hooks on both methods
• Tests verify the guard runs before network access (ValueError raised before httpx touches the wire)
• Tests verify the redirect guard hook is registered in the client kwargs
• Both download methods are covered by parametrized tests

Clean implementation, no issues found.

[teknium1]

Thanks for identifying the authenticated inbound-file download path. The security premise remains valid on current main: plugins/platforms/slack/adapter.py:4059-4065 and :4115-4121 still follow redirects while attaching the bot token, without the shared URL preflight and redirect guard.

Problems

• The PR targets the removed gateway/platforms/slack.py; commit 5600105478ffde29d7566b45421b100eaa29c4ef moved it to plugins/platforms/slack/adapter.py. The new test's gateway.platforms.slack import is obsolete as well.
• plugins/platforms/slack/adapter.py:1751-1778 is another redirect-following Slack URL fetch: it preflights the initial URL at :1772 but registers no redirect hook.

Suggested changes

• Retarget the two helper changes and test import to plugins/platforms/slack/adapter.py, using the existing gateway.platforms.base._ssrf_redirect_guard (gateway/platforms/base.py:541-554).
• Cover the remaining send_multiple_images redirect-following fetch or split it into a focused follow-up.

Automated hermes-sweeper review.

[teknium1]

Current main moved SlackAdapter from gateway/platforms/slack.py to plugins/platforms/slack/adapter.py in 5600105478ffde29d7566b45421b100eaa29c4ef; this import must be retargeted along with the production change.

[teknium1]

Merged via #70193 — your commit was cherry-picked/reapplied onto current main with your authorship preserved in git history: your inbound file URL validation was hand-ported to the plugin adapter, tightened to a Slack CDN allowlist.

Thanks for the contribution!