Which versions of proxy-check-i are malicious?

The following PyPI versions of proxy-check-i are flagged malicious: 0.1.0, 0.1.1. Treat any of these as compromised.

How do I remediate proxy-check-i if I installed it?

Remove proxy-check-i from your project and lockfile, then assume any secrets accessible to the build or runtime were exposed: rotate API keys, tokens, and credentials, and audit for unexpected outbound activity or persistence.

I already installed proxy-check-i — how do I know if it already compromised me?

If proxy-check-i 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 proxy-check-i part of a known attack campaign?

Yes — proxy-check-i is associated with the IN-MAL-2026-009583, IN-MAL-2026-009584 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 proxy-check-i 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 proxy-check-i (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging proxy-check-i across your stack and pipelines.

Malicious package

proxy-check-iPyPI

Malicious code in proxy-check-i (PyPI) Remove it immediately and rotate any exposed credentials.

MAL-2026-10100

Immediate action

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

pip uninstall proxy-check-i

What this malware does

The package advertises itself as a wrapper for a 'qsshd executable' but the bundled Go binary is a reverse-SSH daemon that grants a remote operator persistent shell, exec, pty, and TCP port-forwarding on the installer's host. The entry point proxy-check-i (declared in the package's console_scripts, mapped to qsshd.launcher:main) uses os.execv to launch the bundled Go binary. The daemon establishes device identity by writing a .device_lock file under $XDG_CONFIG_HOME, /dev/shm, or /tmp, then repeatedly dials out to a relay via github.com/mydearniko/overthing (tunnel.NewServer with RelayURI and ForwardAddr pointing at the local SSH listener). SSH authentication only accepts a single hardcoded ed25519 public key embedded at build time via //go:embed authorized_keys, so only the key holder can connect. The reverse-connect design bypasses inbound firewalls. PyPI metadata is a cover story: PKG-INFO summary mentions only 'qsshd executable' with no README and no disclosure of SSH-server, authorized-keys, or outbound-relay behavior, so an installer cannot infer they are enabling a remote-shell daemon. Any host that runs proxy-check-i is remotely controllable by the key holder.

Malicious versions

2 flagged

0.1.00.1.1

Indicators of compromise (SHA-256)

2da390c130eb840eb129a5d43faf0a64a0f0f602070243613aa0e2f8ea8f6d04

ee0e907c752a42d6a2b084a971dd61af2b020ccf33026f9a7b40367615344b36

Detection & response playbook

Malicious package

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for proxy-check-i (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging proxy-check-i across your stack and pipelines.
If you installed it — respond
Remove proxy-check-i from your project and lockfile, then assume any secrets accessible to the build or runtime were exposed: rotate API keys, tokens, and credentials, and audit for unexpected outbound activity or persistence.
Did it already run?
If proxy-check-i 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 proxy-check-i 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. proxy-check-i on PyPI has been identified as a malicious package (versions 0.1.0, 0.1.1 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-009583IN-MAL-2026-009584

References

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks proxy-check-i-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the malicious outbound activity and severs the channel.

Malware detection Runtime egress monitoring