CVE-2026-56847

What it actually does

The flaw is an authorization bypass in Node.js Permission Model enforcement. In affected Node.js 22.x, 24.x, and 26.x configurations, JavaScript code running with restricted filesystem write permissions can call `trace_events.createTracing().enable()` and cause Node.js trace-event log files to be written outside paths permitted by `--allow-fs-write`. This weakens the intended filesystem security boundary and can allow low-privileged code already executing inside the Node.js process to create or modify trace log output in locations that should have been blocked. The issue does not by itself provide remote code execution; exploitation requires the attacker to already have a way to run JavaScript in the affected process or local execution context.

Why it matters to the business

Organizations that rely on the Node.js Permission Model to safely run untrusted or semi-trusted JavaScript may have weaker isolation than expected. An attacker or malicious package with code execution inside a constrained Node.js process could write trace files outside approved directories, undermining sandbox assumptions, creating unauthorized artifacts, and potentially exposing operational data contained in trace output. The CVSS and EPSS values are low and there is no known KEV listing or mature public exploitation signal, but affected services that use Node.js permissions as a security boundary should still be prioritized because the vulnerability directly bypasses that control.

How an attack unfolds

An attacker first needs the ability to execute JavaScript in an affected Node.js 22.x, 24.x, or 26.x process where the Permission Model is enabled and filesystem writes are restricted with `--allow-fs-write`. This could occur through a malicious dependency, plugin, template execution path, local user access, or another application flaw that permits JavaScript execution. The attacker then imports the built-in `node:trace_events` module and calls `trace_events.createTracing(...).enable()`. Due to the enforcement flaw, Node.js creates or writes trace-event output even when the destination is outside the filesystem paths that the process was explicitly allowed to write. The attacker may then trigger additional application activity to enrich the trace file, use the unauthorized write as evidence of sandbox escape, or attempt to retrieve the generated file through other available local, application, or operational channels.

How to fix it

Upgrade affected Node.js 22.x, 24.x, and 26.x runtimes to a vendor-patched release that explicitly fixes this Permission Model bypass. No exact fixed versions were provided in the input, so track the official Node.js security release notes for CVE-2026-56847 and deploy the first fixed release for each active major line in use. Until patched, do not rely on the Node.js Permission Model as the only sandbox boundary for untrusted JavaScript. Avoid running untrusted plugins, scripts, templates, or dependencies in the same process as sensitive workloads. Use OS-level isolation such as containers, read-only filesystems, restricted working directories, least-privilege service accounts, AppArmor/SELinux/seccomp profiles, and separate temporary directories to limit the impact of unauthorized trace-file creation. Where feasible, monitor and restrict Node.js trace-event usage and avoid configurations that place trace output near sensitive paths.

How to confirm the fix worked

Confirm all Node.js runtimes in scope are no longer on vulnerable 22.x, 24.x, or 26.x builds and match the fixed versions listed in the official Node.js advisory. Validate behavior with a controlled negative test: run Node.js with the Permission Model enabled and `--allow-fs-write` limited to a specific test directory, execute a small script that calls `trace_events.createTracing().enable()`, and confirm no `node_trace` or trace-event log file is created outside the allowed write path. Review process launch arguments, container images, buildpacks, and base images to ensure patched Node.js binaries are being used consistently. For production validation, search for unexpected trace-event files in application working directories and temporary directories after patching; their continued creation outside approved paths indicates incomplete remediation or remaining exposure.

Typical attack path

1. Obtain the ability to run JavaScript code inside an affected Node.js 22.x, 24.x, or 26.x process.
2. Confirm or assume the process is using the Node.js Permission Model with restricted filesystem writes, such as `--permission` and limited `--allow-fs-write` paths.
3. Load the built-in trace events capability using `require('node:trace_events')` or `import 'node:trace_events'`.
4. Call `trace_events.createTracing()` with selected categories and invoke `.enable()`.
5. Cause the process to perform activity that results in trace-event data being emitted.
6. Leverage the unauthorized trace log write outside the allowed filesystem-write paths, potentially to bypass policy controls or expose operational data present in trace output.

How to detect it

Detection should focus on identifying unexpected trace-event usage and trace files because exploitation requires code execution inside an affected Node.js process. Review endpoint, EDR, container, and filesystem telemetry for Node.js processes creating files named like `node_trace*.log` outside approved write directories. Inspect process command lines for Node.js Permission Model usage, especially `--permission` combined with limited `--allow-fs-write`, and correlate with creation of trace-event logs. Search source repositories, deployed bundles, package artifacts, and runtime logs for imports of `node:trace_events` or calls to `createTracing().enable()` in code paths that should not use diagnostics. If available, review file creation audit logs, Linux auditd, macOS EndpointSecurity, Windows Sysmon, container runtime logs, and EDR events for `node` or `node.exe` writing trace files in application roots, home directories, temporary directories, or other locations not listed in allowed write policy. Trace files may contain process activity metadata, so preserve suspicious files for forensic review while handling them as potentially sensitive.

• node_trace*.log
• node_trace.${pid}.log
• node_trace.${rotation}.log
• trace_events.createTracing
• createTracing().enable
• require('node:trace_events')
• require("node:trace_events")
• import 'node:trace_events'
• import "node:trace_events"
• --permission
• --allow-fs-write
• --trace-event-file-pattern
• node:trace_events

What your security team should do

• Inventory services, containers, developer tooling, CI jobs, and server-side JavaScript platforms using Node.js 22.x, 24.x, or 26.x with the Permission Model enabled.
• Prioritize patching systems that execute user-supplied, plugin-based, third-party, or otherwise untrusted JavaScript under filesystem permission restrictions.
• Update Node.js to the vendor-fixed release for each affected major version as soon as available, and rebuild container images or deployment artifacts that bundle vulnerable Node.js binaries.
• Until patching is complete, treat the Node.js Permission Model as defense-in-depth rather than a complete sandbox and enforce filesystem restrictions at the operating system or container layer.
• Search for unexpected Node.js trace-event log files, especially `node_trace*.log`, outside approved write directories.
• Review dependency and plugin execution paths for code that imports `node:trace_events` or calls `createTracing().enable()` without an operational need.
• Add runtime or EDR monitoring for Node.js processes creating trace files in unexpected directories.
• Document any exception where tracing is intentionally enabled so security teams can distinguish legitimate diagnostics from suspicious behavior.