{"id":"CVE-2026-49401","title":"Deno: Permission Bypass via Unicode Normalization Mismatch on macOS (APFS)","summary":"Deno: Permission Bypass via Unicode Normalization Mismatch on macOS (APFS)","severity":"medium","cvss":5.2,"cwe":["CWE-41","CWE-176"],"vendor":"deno","product":"deno","ecosystem":"rust","affected":["deno <= 2.7.13"],"patched":["deno 2.7.14"],"published":"2026-06-16","updated":"2026-06-16","source":"GHSA","sourceUrl":"https://github.com/advisories/GHSA-8xpq-cjcf-3wh9","references":[{"url":"https://github.com/denoland/deno/security/advisories/GHSA-8xpq-cjcf-3wh9"},{"url":"https://github.com/advisories/GHSA-8xpq-cjcf-3wh9"}],"tags":["ghsa","rust"],"epss":0.00197,"epssPercentile":0.0969,"ingestedAt":"2026-06-29T14:31:47.707Z","slug":"CVE-2026-49401","body":"## Overview\n\n## Summary\n\nDeno's permission system enforces filesystem and execution restrictions by\ncomparing the requested path against the path supplied to `--deny-read`,\n`--deny-write`, `--deny-run`, or `--deny-ffi`. On macOS, that comparison was\ndone at the raw-byte level while the APFS filesystem treats different Unicode\nspellings of the same name as the same file.\n\nThat means a program could reach a denied path by spelling it differently than\nthe deny rule. For example, with `--deny-read=/secrets/passwörter.txt`, a\nscript could still read the file by opening `/secrets/passwo\\u0308rter.txt`\n(NFD instead of NFC), or `/SECRETS/PASSWÖRTER.txt` (different case, since\ndefault APFS volumes are case-insensitive). Other forms include ligature\ncharacters (`fi` vs `fi`, `ff` vs `ff`, …) and German `ß` vs `ss`.\n\nThe denied path and the requested path differed at the byte level, so Deno's\npermission check passed; the kernel then resolved them to the same inode and\nserved the file anyway. The same flaw affected `--deny-write`, `--deny-run`,\nand `--deny-ffi`, which share the same path-comparison code.\n\n## Am I affected?\n\nYou are potentially affected if **all** of the following are true:\n\n1. You run Deno on **macOS** (the issue is specific to APFS path-equivalence\n   rules; Linux and Windows are not affected by this variant).\n2. You rely on `--deny-read`, `--deny-write`, `--deny-run`, or `--deny-ffi`\n   as a security boundary against less-trusted code — a dependency, plugin,\n   or attacker-controlled input.\n3. The protected path contains characters that have alternate Unicode\n   spellings — most commonly accented characters (`é`, `ñ`, `ö`, …), German\n   `ß`, or Latin ligatures — or you rely on case-sensitivity on a default\n   APFS volume.\n\nIf you only run fully trusted code, or your deny rules cover paths that are\npure ASCII with no case-sensitive aliases, you are not exposed to this\nspecific bypass.\n\n## Impact\n\nA program running with broad `--allow-read` (or `--allow-write` /\n`--allow-run` / `--allow-ffi`) but with `--deny-*` carve-outs for specific\npaths could read, write, execute, or load via FFI those denied paths by\nreferring to them through a Unicode- or case-equivalent spelling. The sandbox\nmodel on macOS was weaker than the flags suggested.\n\n## Workaround\n\nIf you cannot upgrade immediately:\n\n- Prefer `--allow-*` allowlists over `--deny-*` denylists. Allow rules match\n   against the original specifier, so an attacker-supplied alternate spelling\n   will not match a path you didn't explicitly grant.\n- Do not rely on case-sensitivity of paths on macOS for security boundaries;\n   default APFS volumes are case-insensitive.\n\n## Fix\n\nOn macOS, Deno now normalizes both the deny-rule path and the requested path\nto NFC and applies Unicode case folding before comparing them. This matches\nhow APFS resolves paths at the inode level, so byte-different but equivalent\nspellings are now rejected by the same deny rule.\n\n## Affected packages\n\n- `deno <= 2.7.13`\n\n## Remediation\n\nUpgrade to a patched release:\n\n- `deno 2.7.14`","depth":"sunlit","depthScore":29,"depthScoreParts":{"impact":28.6,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}