## Summary When a WebSocket connection was opened, Deno checked the destination hostname against `--deny-net` rules but did not re-check the IP addresses that hostname resolved to. An attacker-controlled script could use a specially crafted domain name that passes the hostname check yet resolves to a denied IP, bypassing the network restriction entirely. ## Impact Code running under `--deny-net` could connect to hosts that the user intended to block. In practice this means network isolation rules — for example, blocking access to `localhost` or internal services — could be silently circumvented by a malicious or compromised dependency. `Deno.connect` and `fetch()` were not affected by this specific issue (a companion advisory covers `fetch()`). ## Who is affected Users who: - run untrusted or third-party code with `deno run`, and - rely on `--deny-net` to restrict which hosts that code can reach. If you do not use `--deny-net`, or if you only run fully trusted code, you are not affected. ## Workaround No workaround is available short of upgrading. If upgrading immediately is not possible, avoid granting `--allow-net` to untrusted code that also has `--deny-net` restrictions you depend on for security.
## Summary When a WebSocket connection was opened, Deno checked the destination hostname against `--deny-net` rules but did not re-check the IP addresses that hostname resolved to. An attacker-controlled script could use a specially crafted domain name that passes the hostname check yet resolves to a denied IP, bypassing the network restriction entirely. ## Impact Code running under `--deny-net` could connect to hosts that the user intended to block. In practice this means network isolation rules — for example, blocking access to `localhost` or internal services — could be silently circumvented by a malicious or compromised dependency. `Deno.connect` and `fetch()` were not affected by this specific issue (a companion advisory covers `fetch()`). ## Who is affected Users who: - run untrusted or third-party code with `deno run`, and - rely on `--deny-net` to restrict which hosts that code can reach. If you do not use `--deny-net`, or if you only run fully trusted code, you are not affected. ## Workaround No workaround is available short of upgrading. If upgrading immediately is not possible, avoid granting `--allow-net` to untrusted code that also has `--deny-net` restrictions you depend on for security.
Update deno to 2.8.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanDeno: WebSocket API sandbox bypass via missing post-DNS check affects deno (rust). Severity is medium. ## Summary When a WebSocket connection was opened, Deno checked the destination hostname against `--deny-net` rules but did not re-check the IP addresses that hostname resolved to. An attacker-controlled script could use a specially crafted domain name that passes the hostname check yet resolves to a denied IP, bypassing the network restriction entirely. ## Impact Code running under `--deny-net` could connect to hosts that the user intended to block. In practice this means network isolation rules — for example, blocking access to `localhost` or internal services — could be silently circumvented by a malicious or compromised dependency. `Deno.connect` and `fetch()` were not affected by this specific issue (a companion advisory covers `fetch()`). ## Who is affected Users who: - run untrusted or third-party code with `deno run`, and - rely on `--deny-net` to restrict which hosts that code can reach. If you do not use `--deny-net`, or if you only run fully trusted code, you are not affected. ## Workaround No workaround is available short of upgrading. If upgrading immediately is not possible, avoid granting `--allow-net` to untrusted code that also has `--deny-net` restrictions you depend on for security.
AI coding agents often install or upgrade packages automatically in rust. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| denorust | <=2.8.0 | 2.8.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate deno to 2.8.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanDeno: WebSocket API sandbox bypass via missing post-DNS check affects deno (rust). Severity is medium. ## Summary When a WebSocket connection was opened, Deno checked the destination hostname against `--deny-net` rules but did not re-check the IP addresses that hostname resolved to. An attacker-controlled script could use a specially crafted domain name that passes the hostname check yet resolves to a denied IP, bypassing the network restriction entirely. ## Impact Code running under `--deny-net` could connect to hosts that the user intended to block. In practice this means network isolation rules — for example, blocking access to `localhost` or internal services — could be silently circumvented by a malicious or compromised dependency. `Deno.connect` and `fetch()` were not affected by this specific issue (a companion advisory covers `fetch()`). ## Who is affected Users who: - run untrusted or third-party code with `deno run`, and - rely on `--deny-net` to restrict which hosts that code can reach. If you do not use `--deny-net`, or if you only run fully trusted code, you are not affected. ## Workaround No workaround is available short of upgrading. If upgrading immediately is not possible, avoid granting `--allow-net` to untrusted code that also has `--deny-net` restrictions you depend on for security.
AI coding agents often install or upgrade packages automatically in rust. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| denorust | <=2.8.0 | 2.8.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard