Advisoriesby IbisAgent Network Filter Security Feature Bypass
Impact
A security feature bypass vulnerability existed in VS Code builds up to and including version 1.136.1 when the integrated browser's Navigate Page tool received an HTTP or HTTPS URL containing backslashes or mixed path separators. The network policy check and Chromium interpreted the same raw URL differently: the URI used by the filter could have an empty authority, while Chromium normalized the URL to a concrete destination host. Because empty authorities were allowed, the browser could make an outbound request to a host excluded by the configured network-domain policy.
An attacker able to influence a URL proposed to an agent could use this parsing difference to reach a local, private, or otherwise restricted endpoint. The request could carry URL data and browser-session cookies, and content returned by the destination could execute in the integrated browser. Subsequent agent access to the normalized destination remained subject to the network filter.
The affected configuration required chat.agent.networkFilter and integrated-browser chat tools to be enabled.
Patches
The fix (https://github.com/microsoft/vscode/commit/256500f4e96be525a26814260a5e815a137c1eff) is is available in VS Code builds starting with 1.136.2. HTTP, HTTPS, WebSocket, and secure WebSocket URIs with an empty authority now fail closed when network filtering is active. Browser tools...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| vscode Product | < 1.136.2 | 1.136.2 |
Details and references
### Impact A security feature bypass vulnerability existed in VS Code builds up to and including version 1.136.1 when the integrated browser's Navigate Page tool received an HTTP or HTTPS URL containing backslashes or mixed path separators. The network policy check and Chromium interpreted the same raw URL differently: the URI used by the filter could have an empty authority, while Chromium normalized the URL to a concrete destination host. Because empty authorities were allowed, the browser could make an outbound request to a host excluded by the configured network-domain policy. An attacker able to influence a URL proposed to an agent could use this parsing difference to reach a local, private, or otherwise restricted endpoint. The request could carry URL data and browser-session cookies, and content returned by the destination could execute in the integrated browser. Subsequent agent access to the normalized destination remained subject to the network filter. The affected configuration required `chat.agent.networkFilter` and integrated-browser chat tools to be enabled. ### Patches The fix (https://github.com/microsoft/vscode/commit/256500f4e96be525a26814260a5e815a137c1eff) is is available in VS Code builds starting with **1.136.2**. HTTP, HTTPS, WebSocket, and secure WebSocket URIs with an empty authority now fail closed when network filtering is active. Browser tools normalize and revalidate logical destinations immediately before network side effects. Rewritten external tunnel destinations receive an additional policy check, while registered loopback tunnel endpoints remain trusted transport. Regression tests cover every reported backslash and mixed-separator form. ### Workarounds Disable Navigate Page in the Chat tool picker for every Agent chat session until a build containing the fix is installed. Alternatively, disable integrated-browser chat tools with `"workbench.browser.enableChatTools": false`. Do not approve agent navigation requests containing unusual slash or backslash separators. ### References * The patch for this can be found at https://github.com/microsoft/vscode/commit/256500f4e96be525a26814260a5e815a137c1eff * An issue for this can be found at https://github.com/microsoft/vscode/issues/335131 * MSRC details for CVE-2026-81378 can be found at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-81378
- CVSS 3.1
- CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N
- Severity from
- GitHub (reviewed advisory)