Deno: Permission Bypass via Unicode Normalization Mismatch on macOS (APFS)

Vulnerability

A byte-level path comparison in Deno's permission system fails to account for macOS APFS Unicode equivalence rules. When a file is protected by --deny-read, --deny-write, --deny-run, or --deny-ffi, the denied path is compared against the requested path as raw bytes. APFS treats different Unicode normalizations (e.g., NFC vs. NFD), case variants on case-insensitive volumes, ligatures (fi vs. fi), and characters like ß vs. ss as the same file. An attacker can therefore access a denied path by supplying an alternate spelling that differs byte-wise from the deny rule but resolves to the same inode. This affects all Deno versions on macOS prior to the fix [1][2].

Exploitation

The attacker needs to execute a script or untrusted code inside a Deno process that holds --allow-read, --allow-write, --allow-run, or --allow-ffi with a --deny-* carve-out for a specific path. The attacker observes or knows a protected path containing characters that have Unicode alternatives (accented letters, ligatures, ß, or case differences). They then construct the path using a byte-different but APFS-equivalent spelling—for example, using NFD instead of NFC, or using uppercase on a case-insensitive volume. The Deno permission byte comparison passes (because byte values differ), and the kernel resolves the alternative path to the same file, allowing the operation [1][2].

Impact

A successful bypass lets the attacker read, write, execute, or load via FFI a file or resource that the deny rule was intended to block. Because the permission model treats the path as permitted, the attacker can access sensitive files, modify protected configuration, run arbitrary binaries, or load shared libraries that were meant to be inaccessible. The compromise is within the context of the Deno process's existing permissions, but it effectively erases the intended security boundary provided by --deny-* flags on affected paths [1][2].

Mitigation

Deno has released a fix in version 2.1.10 (2026-06-16). Users on macOS should upgrade to 2.1.10 or later as soon as possible [1][2]. There is no known workaround for unpatched versions other than avoiding --deny-* on paths with Unicode alternatives or case-sensitive discrepancies, or restricting code execution to fully trusted scripts. The vulnerability is not listed in CISA's KEV catalog as of the publication date.