EUVD-2026-38547
GHSA-8xpq-cjcf-3wh9
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessExecute untrusted code inside Deno sandbox
-
Deliveryidentify denied path with Unicode/case variant
-
Exploitrequest file via alternate spelling
-
Executionbyte-level deny check passes
-
Persistkernel resolves to same APFS inode
-
Impactread/write/execute protected resource
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Path traversal prevention
|
| Exploitation Conditions | Exploitation requires all of: (1) the target runs Deno on macOS with an APFS volume (Linux/Windows unaffected); (2) the operator relies on --deny-read, --deny-write, --deny-run, or --deny-ffi as a boundary against less-trusted code (a dependency, plugin, or attacker-influenced input) while granting a broader --allow-*; and (3) the attacker can already execute code in that Deno process and influence the path string. The denied path must be reachable via an equivalent spelling - most reliably any path containing letters on a default case-insensitive APFS volume via case folding, and otherwise paths containing accented characters, German ß, or Latin ligatures that have NFC/NFD or compatibility variants. Limiting factors: it is local-only (no network vector), it does not bypass --allow-* allowlists, it is useless against fully trusted workloads, and pure-ASCII deny paths on a case-sensitive APFS volume are not exposed. |
| Impact | Signals are mixed and point to a real but bounded boundary-control weakness rather than an internet-facing emergency. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, base 8.4) correctly models this as a LOCAL sandbox escape, not remote code execution - the attacker must already be executing code inside a Deno process. That local-only nature is consistent with EPSS at 0.14% (3rd percentile), CISA SSVC marking Exploitation: none, Automatable: no, Technical Impact: partial, and the absence of any KEV listing or known POC. The divergence to flag for defenders: the headline 8.4 'High' is driven by the S:C scope change plus C:H/I:H, which overstates urgency for organizations not relying on --deny-* as a trust boundary. Realistic risk is concentrated in multi-tenant or plugin/dependency-sandboxing setups on macOS that lean on deny-lists; for those it is a genuine sandbox-integrity failure worth prompt patching, while shops running only trusted code or pure-ASCII deny paths face minimal exposure. |
| Exploit ScenarioDerived | An application runs a third-party plugin or dependency under Deno on macOS with broad --allow-read but --deny-read=/app/secrets/contraseña.env to protect credentials. The malicious dependency opens the same file using an NFD spelling or a case variant such as /app/secrets/CONTRASEÑA.ENV; Deno's byte comparison sees a different string, allows the open, and the kernel returns the secret. No public POC is known, but the technique is straightforward and requires only local code execution within the sandbox (AV:L/AC:L). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv4 – Jun 26, 2026
Permission-sandbox bypass in the Deno runtime (versions <= 2.7.13) on macOS lets untrusted code reach paths that operators explicitly blocked with --deny-read, --deny-write, --deny-run, or --deny-ffi. Because Deno compared paths byte-for-byte while APFS treats Unicode-equivalent and case-equivalent spellings as the same file, a script granted broad --allow-* but with --deny-* carve-outs can read, write, execute, or FFI-load a protected file by referring to it with an alternate spelling (NFD vs NFC, case folding, ligatures, or German ss vs ß). No public exploit identified at time of analysis, and EPSS is low (0.14%), but the bypass is trivial to perform once an attacker controls the path string.
Earlier versions of this analysis (3)
Permission-boundary bypass in the Deno runtime (versions ≤ 2.7.13) on macOS lets less-trusted code reach paths protected by --deny-read, --deny-write, --deny-run, or --deny-ffi by referencing them with a Unicode- or case-equivalent spelling. Because Deno compared paths byte-for-byte while APFS resolves NFC/NFD, case, ligature, and ß/ss variants to the same inode, a deny rule like --deny-read=/secrets/passwörter.txt could be defeated with /secrets/passwörter.txt or /SECRETS/PASSWÖRTER.txt. There is no public exploit identified at time of analysis and EPSS is very low (0.14%), but a vendor patch is available (Deno 2.7.14).
Permission sandbox bypass in Deno on macOS allows untrusted code to access paths protected by --deny-read, --deny-write, --deny-run, or --deny-ffi by referring to them through Unicode-equivalent or case-equivalent spellings. Because APFS treats NFC/NFD forms, ligatures, German ß/ss, and case variants as the same inode while Deno compared paths byte-for-byte, the kernel resolved alternate spellings to the protected file even though the deny check passed. No public exploit identified at time of analysis, but the technique is straightforward and the fix is upstream in Deno 2.7.14.
Permission bypass in Deno's macOS sandbox allows untrusted code executing within a Deno script to access filesystem paths, executables, or FFI libraries that were explicitly blocked via --deny-read, --deny-write, --deny-run, or --deny-ffi flags. All Deno versions up to and including 2.7.13 on macOS are affected; Linux and Windows are not impacted because this flaw is intrinsically tied to APFS path-equivalence semantics. The bypass requires no special privileges beyond being an executing Deno dependency and is straightforward to reproduce by any attacker who knows the structure of deny rules in use, making it a meaningful erosion of Deno's sandbox trust model despite its medium CVSS score.
RemediationAI
Primary fix: upgrade Deno to 2.7.14 or later (Vendor-released patch: 2.7.14), where macOS now normalizes both the deny-rule path and the requested path to NFC and applies Unicode case folding before comparing, matching how APFS resolves inodes. If you cannot upgrade immediately, the vendor-recommended workaround is to stop relying on --deny-* denylists for security and instead express the boundary as --allow-* allowlists, because allow rules match against the original specifier so an attacker-supplied alternate spelling will not match a grant you did not explicitly issue (trade-off: you must enumerate every legitimately needed path, which is more restrictive and may break code paths that depended on broad allow plus narrow deny). Additionally, do not treat macOS path case-sensitivity as a security property, since default APFS volumes are case-insensitive. Full guidance is in advisory GHSA-8xpq-cjcf-3wh9 (https://github.com/denoland/deno/security/advisories/GHSA-8xpq-cjcf-3wh9).
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in cargo
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Deno enforces its capability sandbox in userspace by string-matching a requested filesystem/exec path against the operator-supplied deny rules before issuing the syscall. The root cause is CWE-41 (Improper Resolution of Path Equivalence): the kernel and the userspace check disagree on what 'the same path' means. macOS APFS normalizes filenames and, on default volumes, is case-insensitive, so /secrets/passwörter.txt, its NFD form /secrets/passwo\u0308rter.txt, and /SECRETS/PASSWÖRTER.txt all resolve to one inode - yet they are distinct byte strings to Deno's comparator. The denied string therefore fails to match the requested string, the permission gate opens, and the kernel serves the underlying inode. The CPE pkg:rust/deno reflects that the vulnerable comparison lives in the Rust core permissions code shared by all four --deny-* flags. The flaw is macOS/APFS-specific; the same logic on Linux and Windows is not affected by this variant.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Attacker needs local code execution inside the sandbox (AV:L, PR:L); default case-insensitive APFS makes the bypass low-complexity (AC:L); escaping the permission boundary changes scope (S:C) to read/write protected files (C:H/I:H).
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
7DescriptionNVD
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:
- You run Deno on macOS (the issue is specific to APFS path-equivalence
rules; Linux and Windows are not affected by this variant).
- 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.
- 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.
Executive ViewAI
The Deno runtime on macOS (versions 2.7.13 and earlier) contains a permission-sandbox bypass that allows scripts to circumvent file-access restrictions (--deny-read, --deny-write, --deny-run, --deny-ffi) using alternate Unicode or case-equivalent path spellings. No public exploit identified at time of analysis, though the attack path is trivial to execute once an attacker controls path input. Organizations relying on Deno's sandbox protections on macOS require immediate assessment and patching to prevent unauthorized data access and code execution.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB