During pip install, a custom build_ext step in src/vectordb_engine_build.py runs an obfuscated payload that performs targeted reconnaissance and exfiltration. Before doing anything else, it SHA-256-hashes the lowercased machine hostname against an obfuscated salt and compares the digest against three hardcoded allowed-hash constants; if the hostname does not match, the process calls exit() — the canonical shape of a targeted supply-chain implant that lies dormant on non-victim machines. On matching hosts, the script collects hostname, FQDN, OS, architecture, Python version, and OS username, concatenates them with | separators, XOR-encrypts the blob with a hardcoded key, hex-encodes the result, and issues an HTTPS GET to https://vectordbengine.blob.core.windows.net/kernels/?v=<encoded-fingerprint>. A separate function reads environment variables whose names are concealed behind a base85+XOR+zlib decoder (_ORQFVrfoaIJyX4SjOvpEI) and folds the values into the same exfil pipeline, consistent with scraping CI/cloud secrets without leaving readable identifiers in the source. urllib3.disable_warnings() is invoked to suppress TLS warnings. The package metadata uses placeholder publisher identity (VectorDB Contributors, support@vectordb-engine.io) and constructs a cover-story URL https://releases.vectordb-engine.io/kernels that is built into a string but never actually requested — it exists only as a decoy alongside the real Azure blob exfil endpoint. Each of (hostname-allowlist gating with exit() fallback, obfuscated env-var-name scraper feeding a network exfil, host-fingerprint XOR-encoded into a query string against attacker-controlled storage, decoy-domain cover story with placeholder publisher metadata) is independently sufficient evidence of a targeted attack; their joint presence leaves no benign interpretation.