CVE-2026-48617

What it actually does

The flaw weakens Node.js Permission Model enforcement in Node.js 22, 24, and 26. Under affected configurations, path validation for `process.report.writeReport()` can be misapplied, allowing JavaScript code running inside a constrained Node.js process to write a diagnostic report to a path that should not be permitted by the configured filesystem permissions. This is a security-boundary bypass rather than remote code execution: an attacker generally needs the ability to execute or influence JavaScript in the target process, and the impact is limited to the permissions and runtime context of that process.

Why it matters to the business

Organizations using the Node.js Permission Model as a sandboxing or containment control may have a false sense of isolation. A malicious package, plugin, job, or script could bypass intended file-write restrictions and create diagnostic report files in unauthorized locations, potentially enabling data exposure, configuration tampering, log poisoning, or follow-on abuse depending on where files can be written. The current public exploitation signal is low: the CVSS score is 1.8, EPSS is 0.0024, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity is reported; however, affected Node.js versions are common and this should still be remediated where the Permission Model is relied upon.

How an attack unfolds

An attacker first needs a path to run or influence JavaScript within a Node.js application that is using the Permission Model, such as through a malicious dependency, extension mechanism, build script, scheduled job, developer tooling, or another code-execution foothold. The application is expected to restrict filesystem access using Node.js permission flags. The attacker then invokes `process.report.writeReport()` with a crafted or unexpected path that is mishandled by the permission check. Because the path validation is flawed, Node.js may allow the diagnostic report to be written somewhere outside the intended allowlist. The attacker can use that unauthorized write to place diagnostic data in a readable location, pollute files consumed by other tooling, or create artifacts that support a later attack stage. This vulnerability does not by itself give a network attacker direct access; it becomes meaningful when untrusted or semi-trusted code is executed inside a permission-restricted Node.js process.

How to fix it

Upgrade affected Node.js 22, 24, and 26 installations to a vendor-fixed release when available for the deployed release line. Because no exact fixed versions were provided in the input, track the official Node.js security release notes for CVE-2026-48617 and update all supported runtime images, developer workstations, CI runners, server deployments, containers, and base images that use affected Node.js versions. Until patched, do not rely on the Node.js Permission Model as the sole boundary for untrusted code. Avoid executing untrusted JavaScript in the same process, remove unnecessary use of `process.report.writeReport()`, restrict diagnostic report output directories at the operating-system or container layer, run Node.js workloads with least-privilege filesystem permissions, use read-only filesystems where practical, and isolate plugin or build execution in containers, sandboxes, or separate low-privilege accounts.

How to confirm the fix worked

Confirm all Node.js runtimes report a fixed version for their release line using `node --version` and by checking the official Node.js advisory for the patched version. Inventory container images, CI images, developer tooling, package manager shims, and production hosts because Node.js may be embedded in build and automation systems. Validate that workloads using `--permission` do not depend solely on Node.js for filesystem isolation by performing a controlled test in a non-production environment: configure a denied write path, attempt to write a diagnostic report there with `process.report.writeReport()`, and confirm the operation is blocked after the upgrade. Review application code and dependencies for legitimate uses of diagnostic reports and ensure report output paths are explicitly controlled and constrained by OS-level permissions.

Typical attack path

1. Identify a Node.js 22, 24, or 26 runtime that uses the Node.js Permission Model to restrict filesystem access.
2. Gain the ability to execute or influence JavaScript in that process, commonly through a malicious package, plugin, script, build step, or compromised local workflow.
3. Check that `process.report.writeReport()` is available and that filesystem permissions are intended to prevent writes to the target location.
4. Call `process.report.writeReport()` with a path that is misvalidated by the affected Node.js runtime.
5. Cause Node.js to write a diagnostic report to an unauthorized or unintended filesystem path.
6. Use the written report or resulting file placement for information exposure, log/file poisoning, persistence staging, or follow-on exploitation depending on local file permissions and downstream consumers.

How to detect it

Look for evidence that JavaScript code invoked diagnostic report generation in permission-restricted Node.js processes. Relevant sources include application logs, Node.js process command lines, shell history, CI/CD job logs, EDR process telemetry, file integrity monitoring, Linux auditd, macOS EndpointSecurity logs, Windows Sysmon, container runtime logs, and filesystem audit events. Focus on Node.js processes launched with `--permission` and unexpected calls or references to `process.report.writeReport()`. Investigate diagnostic report files created outside approved directories, especially files created by `node` or `node.exe` in configuration directories, application directories, web roots, temporary directories, user home directories, startup locations, or CI workspaces. Review recent package, plugin, and build-script changes for newly introduced report-generation behavior. Since this issue does not have a known public exploit pattern or named threat actor activity in the supplied intelligence, detection should emphasize anomalous Node.js report creation and unauthorized filesystem writes rather than a single definitive network indicator.

• process.report.writeReport(
• process.report.writeReport()
• --permission
• --allow-fs-write
• --allow-fs-read
• node --permission
• node.exe --permission
• Writing Node.js report to file
• Node.js report completed
• report.
• node-report
• diagnostic report
• process.report
• node.exe
• /usr/bin/node
• /usr/local/bin/node

What your security team should do

• Inventory all Node.js 22, 24, and 26 installations, prioritizing systems that run untrusted code, plugins, build scripts, developer tooling, CI/CD jobs, or multi-tenant workloads.
• Patch Node.js to the vendor-fixed release for each affected release line as soon as it is published and available in your package, container, or runtime distribution channel.
• Treat Permission Model protections as defense-in-depth until patched; add OS, container, and service-account filesystem restrictions around sensitive paths.
• Search source code and dependency trees for use of `process.report.writeReport()` and review whether paths are derived from user input, plugin input, environment variables, or configuration files.
• Monitor Node.js processes for unexpected diagnostic report creation, especially outside approved report directories.
• Rebuild and redeploy container images and CI runner images that bundle affected Node.js versions rather than only patching long-running servers.
• If untrusted JavaScript execution is required, isolate it in hardened sandboxes, separate containers, or disposable workers with minimal filesystem access.
• Because this issue is not currently in KEV and has low EPSS, prioritize it behind actively exploited critical issues unless Node.js Permission Model sandboxing is a primary security control in the environment.