[GHSA-8xpq-cjcf-3wh9] Deno: Permission Bypass via Unicode Normalization Mismatch on macOS (APFS)

[tomasilluminati]

Updates

• CVSS v3
• Severity

Comments
Hi,
Thanks for reviewing. I wanted to ask if you could reconsider the Integrity (I) metric, which is currently set to Low (I:L). I believe High (I:H) is a better fit here, and the base score should reflect that.

The advisory isn't just a read (confidentiality) bypass. The proof of concept shows a clear --deny-write bypass where a file explicitly protected by the rule gets overwritten with attacker-controlled data. This gives the attacker control over both the target file and the contents written to it.

Under CVSS v3.1, Integrity: High applies when there is a total loss of integrity or a complete loss of protection, such as when an attacker can modify files the component is meant to protect. That fits this scenario exactly, since the bypass completely defeats the protection --deny-write is supposed to enforce.

Also, because APFS is case-insensitive by default on macOS, this doesn't just happen with rare Unicode characters. It triggers on simple case variations (like SECRET.txt vs secret.txt). This means effectively any file a user tries to protect with --deny-write can be overwritten. Since the modification isn't limited in scope or outside the attacker's control, Integrity: Low doesn't quite fit.

The underlying issue (comparing raw bytes without Unicode or case normalization) also affects --deny-run and --deny-ffi through the same logic, which extends the integrity impact beyond just file writes.

Just a quick procedural note: the advisory was updated after discussions with the maintainer, so the version you reviewed might differ from the current one. Could you confirm if the assessment reflects the latest revision?

Best regards

[github]

Hi there @bartlomieju! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[bartlomieju]

LGTM

[tomasilluminati]

Hi @github,

Just a quick update, the NIST index the CVE, and set the CVSS in 8.4

https://nvd.nist.gov/vuln/detail/CVE-2026-49401

[github-actions]

👋 This pull request has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the Keep label to hold stale off permanently, or do nothing. If you do nothing this pull request will be closed eventually by the stale bot. Please see CONTRIBUTING.md for more policy details.

[tomasilluminati]

@bartlomieju Does the @github team need to push a bit harder, or can you accept it as it is?

[bartlomieju]

@tomasilluminati I already approved it, not sure what else I can do

[tomasilluminati]

Haha no worries @bartlomieju! Honestly, I’m not entirely sure either, it definitely seems like it got stuck in a bit of a PR limbo haha.

Since you've already approved it, I'll ping the @github ( @copilot @claude[agent] ) security curation team on this thread to see if someone there can review and merge it.

Thanks again for your time and approval!

[advisory-database]

Hi @tomasilluminati! Thank you so much for contributing to the GitHub Advisory Database. This database is free, open, and accessible to all, and it's people like you who make it great. Thanks for choosing to help others. We hope you send in more contributions in the future!