CVE-2025-48935 is a critical flaw (CVSS 9.1) in the Deno runtime, from version 2.2.0 and before 2.2.5. A script can get around the read and write permission checks by using a SQLite ATTACH DATABASE statement. Deno 2.2.5 contains the fix, so upgrade to it or later.
What's affected
The CVE record says Deno is affected starting in version 2.2.0 and prior to 2.2.5. The GitHub advisory agrees, listing affected versions from 2.2.0 and the patched version as 2.2.5 or later. It names the node:sqlite module as the place where the bypass happens.
Deno's permission system is the main security feature of the runtime. You run code with flags such as the read and write permissions, and the runtime refuses file access outside what you allowed. The advisory says the read and write checks could be bypassed using an ATTACH DATABASE statement, so code with database access could touch files beyond the granted scope. The advisory lists no workaround other than the fix.
Note that GitHub rates this advisory High while the CVE record scores it 9.1 Critical. The two sources use different scoring inputs. Both point to the same action.
How to check if you're exposed
Check the Deno version wherever you run it: developer laptops, CI runners, containers and servers.
deno --version
If the version is 2.2.0 up to 2.2.4, you are in range. Then check whether you run code that you do not fully trust under Deno permissions. The bypass matters most when the permission flags are the thing that limits the damage, for example when you run third party scripts, plugins or user supplied code and rely on narrow read or write grants.
Search your repositories for use of the module:
grep -rn "node:sqlite" --include="*.ts" --include="*.js" .
Code that never opens a database through that module is less likely to be affected in practice, but the runtime version is still the thing to fix.
What to do now
- Upgrade Deno to 2.2.5 or later on every machine and image. The built in command is
deno upgrade, or pin the version in your CI configuration and container images. - Rebuild container images that bundle an older Deno, and redeploy.
- Review any workflow where untrusted code runs under Deno permissions. Do not rely on the permission flags alone as a sandbox. Add operating system level isolation, such as a container with a read only file system, for code you do not control.
- Keep permission grants as narrow as you can, and avoid granting broad read or write access out of convenience.
Why it matters
The record classifies the issue as CWE-863, incorrect authorization. The runtime had a permission check, but one path did not enforce it. The SQLite engine inside the module could open and attach database files by itself, outside the runtime's own file access checks.
This is a useful reminder about sandboxes in general. A permission model only holds if every route to the resource goes through it. Any feature that hands a path to a native library, such as a database engine, is a place where the check can be skipped.
The issue is not listed in the CISA Known Exploited Vulnerabilities catalogue, and the advisory describes no exploitation. A scan of your repositories and container images for the Deno version, plus a policy that blocks builds below 2.2.5, closes the gap quickly.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which Deno versions are affected?
Versions from 2.2.0 up to but not including 2.2.5. The fix is in 2.2.5.
Is there a workaround if I cannot upgrade?
The advisory lists none. Reduce risk by not running untrusted code under Deno and by adding container level isolation until you can upgrade.
Sources
Last reviewed: 18 October 2026.
