Skip to content

fix(raycast): only offer http(s) URLs from server-controlled metadata - #1585

Open
Sravanjangam wants to merge 1 commit into
supermemoryai:mainfrom
Sravanjangam:fix/raycast-url-allowlist
Open

fix(raycast): only offer http(s) URLs from server-controlled metadata#1585
Sravanjangam wants to merge 1 commit into
supermemoryai:mainfrom
Sravanjangam:fix/raycast-url-allowlist

Conversation

@Sravanjangam

@Sravanjangam Sravanjangam commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

Hi supermemory team 👋 Thanks for building such a great product! While running a security & quality audit of the repo we hit this issue and put together a small, tested fix — details below.

Problem

apps/raycast-extension/src/search-memories.tsx passed server-controlled metadata.url — which originates from ingested third-party content — straight to Action.OpenInBrowser with no scheme check. A crafted memory document could surface javascript:, file:, or custom app-handler schemes as clickable actions in Raycast.

Part of #1578 (finding M10).

Solution

Parse with new URL() and offer only https:/http: targets as browser actions; anything else is dropped from the action list rather than crashing the result view.

Changes

  • search-memories.tsx → new extractUrl() helper: https/http-only via URL parsing, used by the action list

Verification

Biome clean on the touched file (fresh from branch). Note: this package defines no test runner or typecheck gate upstream; tsc --noEmit fails identically on clean main in this workspace because @raycast/* dependencies aren't installed — baseline parity confirmed, zero errors attributable to this diff.


Happy to iterate on any of this — feedback and reworks very welcome! 🙏

Environment

  • macOS 26.1 (arm64) · bun 1.4.0 · node v26.7.0
  • vitest 3.2.4 (workspace-pinned) · Biome lint clean
  • Branch fix/raycast-url-allowlist — all gates re-run fresh at commit 4c5754de473d

metadata.url arrives from the API and can originate in third-party
ingested content shared into a container. extractUrl now parses the
value and only returns it for https:/http: schemes, so javascript:,
file:, and arbitrary app-handler URLs never reach Action.OpenInBrowser
and the OS opener.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant