Which versions of @junyoung-kim/reins are malicious?

The following npm versions of @junyoung-kim/reins are flagged malicious: 0.1.6, 0.1.7. Treat any of these as compromised.

How do I remediate @junyoung-kim/reins if I installed it?

@junyoung-kim/reins is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.

I already installed @junyoung-kim/reins — how do I know if it already compromised me?

If @junyoung-kim/reins was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.

Is @junyoung-kim/reins part of a known attack campaign?

Yes — @junyoung-kim/reins is associated with the IN-MAL-2026-016740, IN-MAL-2026-016741 campaign. Packages in the same campaign often share infrastructure and payloads, so check whether any related packages are also in your dependency tree.

How do I find @junyoung-kim/reins across my projects, lockfiles, and CI pipelines?

Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for @junyoung-kim/reins (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @junyoung-kim/reins across your stack and pipelines.

Malicious package

@junyoung-kim/reinsnpm

@junyoung-kim/reins is a confirmed malicious npm package (MAL-2026-13432) that steals credentials and exfiltrates sensitive data (malicious versions 0.1.6, 0.1.7). Do not install it — remove it immediately and rotate any exposed credentials.

Malicious code in @junyoung-kim/reins (npm)

MAL-2026-13432

Immediate action

Remove the package, then rotate any secrets the build/runtime could reach.

npm uninstall @junyoung-kim/reins

What this malware does

The reins CLI spawns a local pseudo-terminal via node-pty (default /bin/bash or cmd.exe) and bridges it bidirectionally to a hardcoded WebSocket endpoint wss://juny-api.kr/relay, with pairing coordinated through https://arv.juny-api.kr. Bytes received from the relay peer are written directly into the PTY, so any party that reaches the relay with a valid pairing token — or the operator of the relay itself — obtains interactive shell execution on the host running the CLI. The pairing secret is loaded from parent-directory .env files, widening the trust boundary beyond the package's own directory. The tool can also install itself as a systemd auto-start service, making the remote-shell channel persistent across reboots. Static analysis additionally flagged PATH modifications in dist/cli.mjs (lines 2778, 2790, 3248, 3252) consistent with installing shims for the CLI and node-pty runtime.

Malicious versions

2 flagged

0.1.60.1.7

Indicators of compromise (SHA-256)

a5f53adf4aaeaffcb1bf0698a8fcb748f12522321b24cf44802d0b9f1b441475

b67a86025d39aab07f1c67ee5f3a6d638d024cc63ca54fddbe0087ea3a9ff26d

Detection & response playbook

Credential / info stealer

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for @junyoung-kim/reins (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @junyoung-kim/reins across your stack and pipelines.
If you installed it — respond
@junyoung-kim/reins is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.
Did it already run?
If @junyoung-kim/reins was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.
How O3 protects you
O3 blocks @junyoung-kim/reins before install through its supply-chain scanner, and if it has already run, detects and severs the exfiltration or C2 callback at runtime through L7 egress monitoring and eBPF.

Frequently asked questions

No. @junyoung-kim/reins on npm has been identified as a malicious package (versions 0.1.6, 0.1.7 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-016740IN-MAL-2026-016741

References

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks @junyoung-kim/reins-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the credential exfiltration and severs the channel.

Malware detection Runtime egress monitoring

Explore

All malware advisories How O3 detects malware Vulnerability database