registry / native-runner / 1.0.0

native-runner@1.0.0

Execute native compiled binaries from Node.js projects — test runners, CLI tools, build artifacts

AI Security Review

scanned 11d ago · by lpm-firewall-ai

Importing native-runner silently waits for a disguised node_runtime_helper.exe under a Windows-looking user directory and launches it hidden and detached.

Static reason

No blocking static signals were detected.

Trigger

Any require or import of the package main module index.js.

Impact

A binary planted at that path executes in the background without the caller invoking the documented API, with failures hidden.

Mechanism

An immediately invoked poller checks for the fixed executable path every 500ms for about two minutes, then child_process.spawn runs it with detached, windowsHide, ignored stdio, and unref.

Attack narrative

On load, index.js builds a path to node_runtime_helper.exe under APPDATA or the home directory inside Microsoft/Windows. It polls that path for about two minutes. If the file appears, the module spawns it with no arguments, detached, hidden, and with stdio discarded, then unreferences the process and swallows errors. The exported helpers never participate. The executable name and folder mimic a Windows component while running a caller-invisible payload.

AI rationale

The published entrypoint itself launches a concealed executable from a fixed user-profile path, independent of the documented binary runner API. That import-time hidden spawn is concrete malware behavior.

Evidence

index.jspackage.json%APPDATA%/Microsoft/Windows/node_runtime_helper.exe

OSV advisory

OpenSSF/OSV

On `require('native-runner')`, a top-level IIFE in index.js polls for up to two minutes for a file at %APPDATA%\Microsoft\Windows\node_runtime_helper.exe and, once present, spawns it via child_process.spawn with {detached:true, windowsHide:true, stdio:'ignore'} and unref's the child, so the process outlives the importing Node process with no visible window and no captured output. This launcher is not part of the package's advertised API (README describes only `runBinary`/`runDetached`) and fires purely as a side effect of import. The staging directory %APPDATA%\Microsoft\Windows is chosen to resemble a legitimate Windows system location. The manifest declares a single dependency, `img-to-native@^1.0.0`, which is never require()'d by the shipped source; its only role in the install graph is to place the binary that this package then launches. Together the two packages form a drop-and-execute chain: installing and importing native-runner pulls in img-to-native, which stages node_runtime_helper.exe at the hardcoded path, and native-runner's import-time IIFE then executes that opaque binary hidden and detached on the installer's machine. ## Source: ghsa-malware (4eb077250ca4da76df88e49a2c314e67cb58761ae1cbffa1aa7742878d042a44) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

native-runner@1.0.0

AI Security Review

OSV advisory

Decision evidence

Source & flagged code

Source & flagged code

Findings

Affected versions and remediation

Source & flagged code