Description

Malicious code in projz-py (PyPI)

-= Per source details. Do not edit below this line.=-

Source: amazon-inspector (196ea7ee7277857a29c8478e6908961bde9f28aa136c3e6ae68412ba4b67bff0)

The package routes authentication-related calls through a hardcoded third-party HTTP endpoint and then unpickles the server's raw response, which is a textbook unauthenticated remote code execution primitive against the installer's Python process. Specifically, projz/api/control/rpc.py sets RPC_SERVER = 'http://deepthreads.ru' (plain HTTP) and implements _rpc as: pickle.dumps(args) → session.post(...) → pickle.loads(response.read()). This path is reached from projz/api/request_manager.py (build_headers calls provider.generate_request_signature) and from projz/client.py during registration (RPC.generate_smid), meaning normal documented use of the library drives pickle.loads on attacker-influenceable bytes. Anyone who controls that domain — or any network position on a plain-HTTP path — can execute arbitrary code in the process that imported projz. Compounding the risk, projz/api/secret/init.py opens a sibling secret.pyc, skips the 16-byte header, marshal.loads the code object and exec()s it at import time into a synthetic secret_functions module; headers_provider.py imports this at the top of the import graph, so the hidden bytecode runs on import projz. The.pyc is not present in the sdist, defeating source review of the code that actually builds request signatures and device IDs. The Termux-gated pkg install sox -y in setup.py is a minor additional concern (install-time mutation of system package state conditional on an environment marker) but is not the basis for this verdict.

Mitigation

Aliases