CVE-2026-58043

What it actually does

CVE-2026-58043 is an authorization bypass in the Node.js Permission Model. When Node.js is run with `--permission` and filesystem permissions are constrained with path allowlists, incorrect radix-tree prefix boundary handling can cause access granted for one path to unintentionally match neighboring paths outside the intended boundary. A local, low-privileged attacker or attacker-controlled JavaScript running inside the constrained Node.js process may be able to read or write files that should have been denied. The impact is high for confidentiality and integrity, but it requires the application to use the experimental/permission model and for the attacker to already have a way to execute code within that Node.js process or influence file operations.

Why it matters to the business

Applications relying on Node.js filesystem permissions for sandboxing or tenant/plugin isolation may provide a false sense of containment. If exploited, sensitive files outside the intended allowlist could be exposed or modified, potentially leading to secret theft, configuration tampering, data corruption, or further compromise of the application runtime. The issue is not currently in CISA KEV, has very low EPSS, and has no known mature public exploit, but affected Node.js 22.x, 24.x, and 26.x deployments that depend on `--permission` should still be prioritized because the flaw undermines a security boundary.

How an attack unfolds

An attacker first needs an execution foothold inside a Node.js process that is running with the Permission Model enabled, such as through untrusted plugin code, server-side JavaScript execution, a compromised dependency, or another application-level code execution path. The attacker then identifies a filesystem path that the process is allowed to access using permission flags such as `--allow-fs-read` or `--allow-fs-write`. By crafting file paths that exploit radix-tree prefix boundary confusion, the attacker causes Node.js to treat a disallowed neighboring path as if it falls under the allowed prefix. Successful exploitation allows unauthorized reads or writes outside the configured allowlist, which may expose credentials, source code, configuration files, or enable tampering with application files accessible to the process user.

How to fix it

Upgrade affected Red Hat Node.js packages to the fixed versions or later: `nodejs22-main` fixed in `22.23.2-2.3.hum1` via `RHSA-2026:48273`, `nodejs24-main` fixed in `24.18.1-0.1.hum1` via `RHSA-2026:48273`, and `nodejs26-main` fixed in `26.5.1-1.5.hum1` via `RHSA-2026:48273`. For upstream or other distributions, upgrade Node.js 22.x, 24.x, or 26.x to a vendor release containing the permission model boundary-handling fix. Where immediate upgrade is not possible, do not rely on Node.js `--permission` as the only sandbox boundary for untrusted code; isolate untrusted workloads using OS-level controls such as containers, chroot/jails, AppArmor/SELinux, seccomp, dedicated service accounts, and restrictive filesystem permissions. Review allowlisted paths for ambiguous prefix relationships and avoid granting broad or similarly named adjacent path prefixes until patched.

How to confirm the fix worked

Confirm that all Node.js runtimes in scope are running fixed package versions or later. Check package manager inventory and runtime output with commands such as `node --version`, `rpm -q nodejs22-main nodejs24-main nodejs26-main`, or equivalent distribution package queries. Validate startup scripts, service definitions, containers, and process managers for use of `--permission`, `--allow-fs-read`, and `--allow-fs-write`; prioritize those workloads for patch verification. As a functional test in a non-production environment, run a permission-enabled Node.js process with a narrowly allowed path and confirm that attempts to access similarly prefixed but non-allowed sibling paths are denied. Also verify that compensating OS-level controls prevent the Node.js service account from reading or writing files that the application should not access.

Typical attack path

1. Gain the ability to run or influence JavaScript code inside a Node.js process that was started with `--permission`.
2. Determine or infer the filesystem paths granted through permission flags such as `--allow-fs-read` or `--allow-fs-write`.
3. Craft file access requests using path names that cross radix-tree prefix boundaries while resembling an allowed path prefix.
4. Use standard Node.js filesystem APIs to attempt reads or writes against files outside the intended allowlist.
5. Extract sensitive data such as secrets, configuration, source code, or tokens, or modify files writable by the Node.js process.
6. Use the exposed or modified files to escalate impact within the application or surrounding host context.

How to detect it

Because this issue abuses legitimate Node.js filesystem APIs from inside a process, exploitation may not produce a unique network signature. Detection should focus on process telemetry, file access auditing, application logs, and endpoint events showing Node.js reading or writing files outside its expected allowlisted paths. Review command-line telemetry for Node.js processes started with `--permission`, `--allow-fs-read`, or `--allow-fs-write`, then compare actual file access events against those declared permissions and the application’s normal behavior. Useful sources include EDR file events, Linux auditd logs, eBPF/Falco telemetry, container runtime audit logs, systemd journal entries, application error logs, and shell/process history. Look for Node.js access to sensitive files such as SSH keys, cloud credentials, environment files, service configuration, package manager credentials, source repositories, or writable application scripts. Also investigate unexpected path variants that share prefixes with allowed directories, repeated `EACCES`/`ERR_ACCESS_DENIED` errors followed by successful access to similarly named paths, and any suspicious plugin, dependency, build, or user-supplied script activity preceding file reads or writes.

• --permission
• --allow-fs-read
• --allow-fs-write
• ERR_ACCESS_DENIED
• EACCES
• node --permission
• /usr/bin/node --permission
• /usr/local/bin/node --permission
• /etc/passwd
• /etc/shadow
• /etc/ssh/ssh_host_rsa_key
• /root/.ssh/id_rsa
• /.ssh/id_rsa
• /.aws/credentials
• /.config/gcloud/application_default_credentials.json
• /.kube/config
• .env
• npmrc
• /root/.npmrc
• /home/.npmrc
• process.env
• fs.readFile
• fs.readFileSync
• fs.writeFile
• fs.writeFileSync
• fs.open
• fs.openSync

What your security team should do

• Inventory Node.js 22.x, 24.x, and 26.x deployments, especially services launched with `--permission`.
• Patch affected Red Hat packages to `nodejs22-main 22.23.2-2.3.hum1`, `nodejs24-main 24.18.1-0.1.hum1`, or `nodejs26-main 26.5.1-1.5.hum1` or later, as applicable.
• Treat any application using Node.js Permission Model for untrusted plugins, user-submitted JavaScript, build scripts, or dependency execution as higher priority.
• Do not rely solely on Node.js Permission Model for security isolation until patched; enforce host, container, SELinux/AppArmor, and service-account restrictions.
• Review filesystem allowlists for prefix-adjacent paths and reduce grants to the minimum required directories and files.
• Search logs and telemetry for unexpected filesystem access attempts by Node.js processes outside expected application directories.
• Monitor dependency, plugin, and script execution paths that could provide attackers with local code execution inside permission-enabled Node.js processes.
• Track vendor advisories for non-Red Hat Node.js distributions and rebuild container images or base images that include affected runtimes.