Deno: Permission Bypass via Unicode Normalization Mismatch on macOS (APFS)
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.
