🛡️ MAL-2026-3690 — dlty

Malicious code in dlty (PyPI)

Source: amazon-inspector

Importing the dlty package triggers an active data-exfiltration channel from the installer to third-party-controlled infrastructure. dlty/__init__.py imports dlty.dlt, which defines a class DataLeakTest whose class body contains threading.Thread(target=leak_data).start() — meaning the thread runs at class-definition/import time, not on instantiation. The target function leak_data (dlty/dlt.py) first performs an HTTP GET to https://www.google.de as a connectivity probe, then reads the environment variables RUN, PIPELINE, STEP and uploads them with a timestamp as a blob to the hardcoded Google Cloud Storage bucket data-leak-test via storage.Client().get_bucket('data-leak-test').blob(run).upload_from_string(...). This uses the installer's ambient GCP credentials (Application Default Credentials) to write installer-side environment variables (commonly CI/CD metadata) to author-controlled storage. Exceptions are swallowed with a reassuring print, and the exfiltration is placed in a class body rather than __init__ to make it less visible during casual review. Metadata fields are placeholders (Example Author, pypa/sampleproject URL), the README is a single line, and the package name does not advertise any of this behavior. This is a one-way installer→attacker exfiltration path and meets the criteria for an active supply-chain attack.