Skip to content

Exposure of the GITHUB_TOKEN in Pex Workflow Run Artifact

Critical
jsirois published GHSA-h4c9-2c5c-fwfc Apr 17, 2025

Package

pip Pex (pip)

Affected versions

2.33.7

Patched versions

None

Description

Summary

For each workflow run, Github generates an API key called the GITHUB_TOKEN. This is meant for the workflow to be able to authenticate to the Github API and perform duties outlined in the workflow file (checking out the repo, modifying PRs, etc). Github will automatically place this token in artifact files.

If developers are unaware of this and somehow publish contents of their working directory, it's possible for the GITHUB_TOKEN to leak. It should only be valid for the duration of the workflow run, but there is some wiggle room that can be exploited by someone with enough determination.
Details

The ci.yml workflow file uses actions/upload-artifact@v4 to upload the workspace artifact. This artifact is a zip of the current directory, which includes the run's GITHUB_TOKEN. Seeing as the artifact can be downloaded prior to the end of the workflow, there is a few seconds where an attacker can extract the token from the artifact and use it with the Github API to push malicious code or rewrite release commits in your repository.

PoC

  • Monitor for runs of the ci.yml workflow
  • Once a run is found, wait for the artifact to be made available
  • Download and extract the GITHUB_TOKEN from it
  • Use the token with the Github API to push a new commit to main with backdoored code. Alternatively update the release tags to point to this new commit so subsequent downloads of the releases contain the backdoor.

Impact

Any downstream user of this repo.

Suggested Fix

Only add the files required to the artifact, instead of specifying the current directory. Make sure the artifact doesn't contain environment variables

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CVE ID

No known CVE

Weaknesses

Insufficiently Protected Credentials

The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval. Learn more on MITRE.

Credits