## Summary Deno's permission system enforces filesystem and execution restrictions by comparing the requested path against the path supplied to `--deny-read`, `--deny-write`, `--deny-run`, or `--deny-ffi`. On macOS, that comparison was done at the raw-byte level while the APFS filesystem treats different Unicode spellings of the same name as the same file. That means a program could reach a denied path by spelling it differently than the deny rule. For example, with `--deny-read=/secrets/passwörter.txt`, a script could still read the file by opening `/secrets/passwo\u0308rter.txt` (NFD instead of NFC), or `/SECRETS/PASSWÖRTER.txt` (different case, since default APFS volumes are case-insensitive). Other forms include ligature characters (`fi` vs `fi`, `ff` vs `ff`, …) and German `ß` vs `ss`. The denied path and the requested path differed at the byte level, so Deno's permission check passed; the kernel then resolved them to the same inode and served the file anyway. The same flaw affected `--deny-write`, `--deny-run`, and `--deny-ffi`, which share the same path-comparison code. ## Am I affected? You are potentially affected if **all** of the following are true: 1. You run Deno on **macOS** (the issue is specific to APFS path-equivalence rules; Linux and Windows are not affected by this variant). 2. You rely on `--deny-read`, `--deny-write`, `--deny-run`, or `--deny-ffi` as a security boundary against less-trusted code — a dependency, plugin, or attacker-controlled input. 3. The protected path contains characters that have alternate Unicode spellings — most commonly accented characters (`é`, `ñ`, `ö`, …), German `ß`, or Latin ligatures — or you rely on case-sensitivity on a default APFS volume. If you only run fully trusted code, or your deny rules cover paths that are pure ASCII with no case-sensitive aliases, you are not exposed to this specific bypass. ## Impact A program running with broad `--allow-read` (or `--allow-write` / `--allow-run` / `--allow-ffi`) but with `--deny-*` carve-outs for specific paths could read, write, execute, or load via FFI those denied paths by referring to them through a Unicode- or case-equivalent spelling. The sandbox model on macOS was weaker than the flags suggested. ## Workaround If you cannot upgrade immediately: - Prefer `--allow-*` allowlists over `--deny-*` denylists. Allow rules match against the original specifier, so an attacker-supplied alternate spelling will not match a path you didn't explicitly grant. - Do not rely on case-sensitivity of paths on macOS for security boundaries; default APFS volumes are case-insensitive. ## Fix On macOS, Deno now normalizes both the deny-rule path and the requested path to NFC and applies Unicode case folding before comparing them. This matches how APFS resolves paths at the inode level, so byte-different but equivalent spellings are now rejected by the same deny rule.
## Summary Deno's permission system enforces filesystem and execution restrictions by comparing the requested path against the path supplied to `--deny-read`, `--deny-write`, `--deny-run`, or `--deny-ffi`. On macOS, that comparison was done at the raw-byte level while the APFS filesystem treats different Unicode spellings of the same name as the same file. That means a program could reach a denied path by spelling it differently than the deny rule. For example, with `--deny-read=/secrets/passwörter.txt`, a script could still read the file by opening `/secrets/passwo\u0308rter.txt` (NFD instead of NFC), or `/SECRETS/PASSWÖRTER.txt` (different case, since default APFS volumes are case-insensitive). Other forms include ligature characters (`fi` vs `fi`, `ff` vs `ff`, …) and German `ß` vs `ss`. The denied path and the requested path differed at the byte level, so Deno's permission check passed; the kernel then resolved them to the same inode and served the file anyway. The same flaw affected `--deny-write`, `--deny-run`, and `--deny-ffi`, which share the same path-comparison code. ## Am I affected? You are potentially affected if **all** of the following are true: 1. You run Deno on **macOS** (the issue is specific to APFS path-equivalence rules; Linux and Windows are not affected by this variant). 2. You rely on `--deny-read`, `--deny-write`, `--deny-run`, or `--deny-ffi` as a security boundary against less-trusted code — a dependency, plugin, or attacker-controlled input. 3. The protected path contains characters that have alternate Unicode spellings — most commonly accented characters (`é`, `ñ`, `ö`, …), German `ß`, or Latin ligatures — or you rely on case-sensitivity on a default APFS volume. If you only run fully trusted code, or your deny rules cover paths that are pure ASCII with no case-sensitive aliases, you are not exposed to this specific bypass. ## Impact A program running with broad `--allow-read` (or `--allow-write` / `--allow-run` / `--allow-ffi`) but with `--deny-*` carve-outs for specific paths could read, write, execute, or load via FFI those denied paths by referring to them through a Unicode- or case-equivalent spelling. The sandbox model on macOS was weaker than the flags suggested. ## Workaround If you cannot upgrade immediately: - Prefer `--allow-*` allowlists over `--deny-*` denylists. Allow rules match against the original specifier, so an attacker-supplied alternate spelling will not match a path you didn't explicitly grant. - Do not rely on case-sensitivity of paths on macOS for security boundaries; default APFS volumes are case-insensitive. ## Fix On macOS, Deno now normalizes both the deny-rule path and the requested path to NFC and applies Unicode case folding before comparing them. This matches how APFS resolves paths at the inode level, so byte-different but equivalent spellings are now rejected by the same deny rule.
Update deno to 2.7.14 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanDeno: Permission Bypass via Unicode Normalization Mismatch on macOS (APFS) affects deno (rust). Severity is high. ## Summary Deno's permission system enforces filesystem and execution restrictions by comparing the requested path against the path supplied to `--deny-read`, `--deny-write`, `--deny-run`, or `--deny-ffi`. On macOS, that comparison was done at the raw-byte level while the APFS filesystem treats different Unicode spellings of the same name as the same file. That means a program could reach a denied path by spelling it differently than the deny rule. For example, with `--deny-read=/secrets/passwörter.txt`, a script could still read the file by opening `/secrets/passwo\u0308rter.txt` (NFD instead of NFC), or `/SECRETS/PASSWÖRTER.txt` (different case, since default APFS volumes are case-insensitive). Other forms include ligature characters (`fi` vs `fi`, `ff` vs `ff`, …) and German `ß` vs `ss`. The denied path and the requested path differed at the byte level, so Deno's permission check passed; the kernel then resolved them to the same inode and served the file anyway. The same flaw affected `--deny-write`, `--deny-run`, and `--deny-ffi`, which share the same path-comparison code. ## Am I affected? You are potentially affected if **all** of the following are true: 1. You run Deno on **macOS** (the issue is specific to APFS path-equivalence rules; Linux and Windows are not affected by this variant). 2. You rely on `--deny-read`, `--deny-write`, `--deny-run`, or `--deny-ffi` as a security boundary against less-trusted code — a dependency, plugin, or attacker-controlled input. 3. The protected path contains characters that have alternate Unicode spellings — most commonly accented characters (`é`, `ñ`, `ö`, …), German `ß`, or Latin ligatures — or you rely on case-sensitivity on a default APFS volume. If you only run fully trusted code, or your deny rules cover paths that are pure ASCII with no case-sensitive aliases, you are not exposed to this specific bypass. ## Impact A program running with broad `--allow-read` (or `--allow-write` / `--allow-run` / `--allow-ffi`) but with `--deny-*` carve-outs for specific paths could read, write, execute, or load via FFI those denied paths by referring to them through a Unicode- or case-equivalent spelling. The sandbox model on macOS was weaker than the flags suggested. ## Workaround If you cannot upgrade immediately: - Prefer `--allow-*` allowlists over `--deny-*` denylists. Allow rules match against the original specifier, so an attacker-supplied alternate spelling will not match a path you didn't explicitly grant. - Do not rely on case-sensitivity of paths on macOS for security boundaries; default APFS volumes are case-insensitive. ## Fix On macOS, Deno now normalizes both the deny-rule path and the requested path to NFC and applies Unicode case folding before comparing them. This matches how APFS resolves paths at the inode level, so byte-different but equivalent spellings are now rejected by the same deny rule.
AI coding agents often install or upgrade packages automatically in rust. A high 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.7.13 | 2.7.14 |
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.7.14 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanDeno: Permission Bypass via Unicode Normalization Mismatch on macOS (APFS) affects deno (rust). Severity is high. ## Summary Deno's permission system enforces filesystem and execution restrictions by comparing the requested path against the path supplied to `--deny-read`, `--deny-write`, `--deny-run`, or `--deny-ffi`. On macOS, that comparison was done at the raw-byte level while the APFS filesystem treats different Unicode spellings of the same name as the same file. That means a program could reach a denied path by spelling it differently than the deny rule. For example, with `--deny-read=/secrets/passwörter.txt`, a script could still read the file by opening `/secrets/passwo\u0308rter.txt` (NFD instead of NFC), or `/SECRETS/PASSWÖRTER.txt` (different case, since default APFS volumes are case-insensitive). Other forms include ligature characters (`fi` vs `fi`, `ff` vs `ff`, …) and German `ß` vs `ss`. The denied path and the requested path differed at the byte level, so Deno's permission check passed; the kernel then resolved them to the same inode and served the file anyway. The same flaw affected `--deny-write`, `--deny-run`, and `--deny-ffi`, which share the same path-comparison code. ## Am I affected? You are potentially affected if **all** of the following are true: 1. You run Deno on **macOS** (the issue is specific to APFS path-equivalence rules; Linux and Windows are not affected by this variant). 2. You rely on `--deny-read`, `--deny-write`, `--deny-run`, or `--deny-ffi` as a security boundary against less-trusted code — a dependency, plugin, or attacker-controlled input. 3. The protected path contains characters that have alternate Unicode spellings — most commonly accented characters (`é`, `ñ`, `ö`, …), German `ß`, or Latin ligatures — or you rely on case-sensitivity on a default APFS volume. If you only run fully trusted code, or your deny rules cover paths that are pure ASCII with no case-sensitive aliases, you are not exposed to this specific bypass. ## Impact A program running with broad `--allow-read` (or `--allow-write` / `--allow-run` / `--allow-ffi`) but with `--deny-*` carve-outs for specific paths could read, write, execute, or load via FFI those denied paths by referring to them through a Unicode- or case-equivalent spelling. The sandbox model on macOS was weaker than the flags suggested. ## Workaround If you cannot upgrade immediately: - Prefer `--allow-*` allowlists over `--deny-*` denylists. Allow rules match against the original specifier, so an attacker-supplied alternate spelling will not match a path you didn't explicitly grant. - Do not rely on case-sensitivity of paths on macOS for security boundaries; default APFS volumes are case-insensitive. ## Fix On macOS, Deno now normalizes both the deny-rule path and the requested path to NFC and applies Unicode case folding before comparing them. This matches how APFS resolves paths at the inode level, so byte-different but equivalent spellings are now rejected by the same deny rule.
AI coding agents often install or upgrade packages automatically in rust. A high 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.7.13 | 2.7.14 |
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