CVE-2026-48935

What it actually does

This is a local authorization-bypass flaw in the Node.js Permission API. Code running inside a Node.js process can modify file metadata for a path that was intended to be read-only through Permission API configuration such as `--allow-fs-read`. The flaw does not directly allow reading unauthorized data, writing file contents, or remote code execution, but it weakens filesystem integrity controls by allowing metadata changes despite a read-only policy. The CVSS impact is low integrity impact, local attack vector, low complexity, and requires the attacker to already have the ability to execute code in the affected Node.js process.

Why it matters to the business

Applications that rely on the Node.js Permission API as a sandbox or containment boundary may have weaker file-protection guarantees than expected. An attacker who can run JavaScript in the process may tamper with file metadata, which can affect integrity checks, deployment workflows, audit trails, backup behavior, timestamps, permissions-dependent logic, or operational trust in protected files. Because exploitation requires local code execution within the Node.js runtime and EPSS is currently very low, this is generally a defense-in-depth issue rather than an internet-scale emergency; however, organizations using Node.js 22, 24, or 26 with Permission API controls should prioritize upgrades or mitigations once fixed versions are available.

How an attack unfolds

An attacker first obtains the ability to execute JavaScript in an affected Node.js process, such as through malicious package code, plugin execution, compromised build scripts, server-side code injection, or another application-level vulnerability. The process must be using the Node.js Permission API with a filesystem path granted as read-only using an option such as `--allow-fs-read`. The attacker then invokes Node.js filesystem functionality that changes metadata on the read-only path. Due to the authorization bypass, Node.js permits the metadata operation even though the policy should prevent modification. The attacker can then use the metadata change to undermine integrity assumptions, confuse auditing or synchronization processes, alter timestamps, or support follow-on activity that depends on file metadata manipulation.

How to fix it

Upgrade Node.js to a vendor-fixed release for the affected release line as soon as fixed versions are published. The affected supported release lines are Node.js 22, Node.js 24, and Node.js 26. Because no fixed versions were provided in the input, monitor the official Node.js security releases and package manager advisories for patched builds, then update all runtimes, container images, base images, CI runners, developer workstations, and production hosts using these release lines. Until patched, do not treat the Node.js Permission API as a complete sandbox for filesystem integrity. Avoid running untrusted code in the same Node.js process, minimize use of plugins or dynamic code execution, isolate workloads with operating-system controls, run services with least-privilege OS accounts, use container read-only mounts where practical, and enforce filesystem permissions outside Node.js for files that must not be modified.

How to confirm the fix worked

Inventory Node.js versions and startup flags across servers, containers, CI systems, and developer tooling. Confirm whether Node.js 22, 24, or 26 is in use and whether processes are launched with Permission API-related options such as `--permission`, `--experimental-permission`, or `--allow-fs-read`. After upgrading, verify the runtime version reports a patched release from the vendor advisory. Validate behavior with a controlled regression test: launch Node.js with a read-only filesystem permission for a test path, attempt a metadata-changing operation against that path, and confirm the operation is denied. Also confirm that OS-level protections, container mount options, and service account permissions prevent metadata modification for sensitive files independently of Node.js policy controls.

Typical attack path

1. Gain the ability to execute JavaScript in an affected Node.js 22, 24, or 26 process.
2. Confirm that the process is using the Node.js Permission API and has read-only filesystem access configured with options such as `--allow-fs-read`.
3. Identify files or directories whose metadata is security- or operations-relevant, such as configuration files, application artifacts, logs, dependency files, or build outputs.
4. Invoke filesystem metadata-changing operations from within the Node.js process against a path that should be read-only.
5. Use the resulting metadata tampering to weaken integrity checks, obscure activity, influence automation, or prepare for further compromise.

How to detect it

Look for evidence that a Node.js process changed file metadata on paths that should have been read-only under Permission API policy. Relevant sources include process creation logs, EDR telemetry, Linux auditd or eBPF file event logs, macOS Endpoint Security logs, Windows Sysmon file metadata events where applicable, container runtime logs, CI job logs, application logs, and file integrity monitoring alerts. Focus on Node.js processes launched with Permission API flags such as `--allow-fs-read`, `--permission`, or `--experimental-permission`, followed by metadata-changing activity such as chmod, chown, utime, futimes, lutimes, or timestamp/ownership/mode changes against protected files. Correlate suspicious metadata changes with recent package installs, build scripts, plugin activity, server-side code execution events, unexpected child processes, or application errors indicating denied filesystem access. Because there are no public exploit indicators in the supplied data, detection should be behavior-based rather than signature-based.

• --allow-fs-read=
• --permission
• --experimental-permission
• comm="node" chmod
• comm="node" fchmod
• comm="node" fchmodat
• comm="node" chown
• comm="node" fchown
• comm="node" fchownat
• comm="node" lchown
• comm="node" utime
• comm="node" utimes
• comm="node" futimes
• comm="node" lutimes
• process.name:node AND event.action:chmod
• process.name:node AND event.action:chown
• process.name:node AND event.action:utimes

What your security team should do

• Prioritize inventory of Node.js 22, 24, and 26 deployments that use the Permission API or execute untrusted, third-party, plugin, or user-controlled JavaScript.
• Track the official Node.js security advisory and upgrade to the fixed release for each affected line as soon as available.
• Do not rely on the Node.js Permission API alone as a security boundary for sensitive files until patched and validated.
• Apply compensating controls such as read-only container mounts, restrictive file ownership, least-privilege service accounts, mandatory access controls, and separation of untrusted code into isolated processes or sandboxes.
• Review build, CI/CD, package installation, and plugin execution paths for opportunities where malicious JavaScript could run inside affected Node.js processes.
• Enable or review file integrity monitoring and OS audit logging for unexpected metadata changes by Node.js processes.
• Because this issue is not listed in CISA KEV, has no known exploit maturity in the supplied data, and has very low EPSS, handle with normal vulnerability management urgency unless the Permission API is used as a key isolation control.