This demo showcases how to detect and prevent distribution-level supply chain attacks by using Chainguard Libraries as the safe source for open source. It compares different variants of the ultralytics package to highlight risks flagged by malcontent-action which checks git commits using malcontent diff
Update the setup.yaml to switch between different sources for ultralytics. Once setup.yaml the build workflow will kick off which checks for malware.
⚠️ Note: Thev8.3.40release was removed from PyPI. This demo uses a snapshot from the malcontent-samples repository.
To test the malicious sample, create a new branch, then update .github/workflows/setup.yaml to switch sources and make a PR:
env:
ULTRALYTICS_SOURCE: "PYPI"To test the safe Chainguard Library update .github/workflows/setup.yaml:
env:
ULTRALYTICS_SOURCE: "CHAINGUARD"You should see no changes in risk detected:

This code was injected into the PyPI release artifacts and was not present in the public GitHub repository.
See the advisory details here:
The commit Cb260c243ffa3e0cc84820095cd88be2f5db86ca is the triggering commit for the first malicious release.
It bumps the version to the first known malicious version (v8.3.41) and critically removes a github.actor check that limited who could do publish.yml triggers from the main branch.
This commit is authored by the @UltralyticsAssistant which strongly suggests that the attacker is in full control of the @UltralyticsAssistant identity at this point.
- ultralytics-8.3.41.tar.gz https://search.sigstore.dev/?logIndex=153415338
- ultralytics-8.3.41-py3-none-any.whl https://search.sigstore.dev/?logIndex=153415340
- The release
v8.3.41was uploaded to PyPI with a Trusted Publisher and valid attestations for each distribution, matching theultralytics/ultralyticsTrusted Publisher identity.
Each branch name referenced a file in a commit that supposedly contained a malicious payload used during the exploitation. However, both those files were removed from GitHub following the incident.
As forecasted in Woodruff’s analysis, the actual attack payload is a copy of the proof of concept from Adnan Khan's post on GitHub Actions cache poisoning.
It uses the same Python memory dump tool and HTTP data exfiltration channel. The exfiltration occurred to a temporary HTTP webhook:
hxxps://webhook.site/9212d4ee-df58-41db-886a-98d180a912e6 (which has been deleted since then).
No other mention of this webhook was observed in our GitHub dataset.
