How severe is GHSA-vxmw-7h4f-hqxh?

GHSA-vxmw-7h4f-hqxh has a CVSS score of 0/10, rated NONE. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-vxmw-7h4f-hqxh?

GHSA-vxmw-7h4f-hqxh affects the following packages: pypa/gh-action-pypi-publish (GitHub Actions). Ecosystems affected: GitHub Actions.

How do I fix GHSA-vxmw-7h4f-hqxh?

Update pypa/gh-action-pypi-publish to 1.13.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vxmw-7h4f-hqxh is resolved across your whole dependency graph.

How do I detect GHSA-vxmw-7h4f-hqxh in my GitHub Actions dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pypa/gh-action-pypi-publish. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-vxmw-7h4f-hqxh if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-vxmw-7h4f-hqxh?

O3 pinpoints whether GHSA-vxmw-7h4f-hqxh is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-vxmw-7h4f-hqxh actively exploited in the wild?

No public exploit code has been indexed for GHSA-vxmw-7h4f-hqxh yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-vxmw-7h4f-hqxh published, and has it been updated?

GHSA-vxmw-7h4f-hqxh was published on September 4, 2025. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 GitHub Actions

GHSA-vxmw-7h4f-hqxh

NONE

PyPI publish GitHub Action vulnerable to injectable expression expansions in action steps

Published

Sep 4, 2025

Updated

Sep 4, 2025

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

📦pypa/gh-action-pypi-publish

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects GitHub Actions packages — download data is not available via public APIs for these ecosystems.

Description

Summary

gh-action-pypi-publish makes use of GitHub Actions expression expansions (i.e. ${{ ... }}) in contexts that are potentially attacker controllable. Depending on the trigger used to invoke gh-action-pypi-publish, this may allow an attacker to execute arbitrary code within the context of a workflow step that invokes gh-action-pypi-publish.

Details

gh-action-pypi-publish contains a composite action step, set-repo-and-ref, that makes use of expression expansions:

  - name: Set repo and ref from which to run Docker container action
    id: set-repo-and-ref
    run: |
      # Set repo and ref from which to run Docker container action
      # to handle cases in which `github.action_` context is not set
      # https://github.com/actions/runner/issues/2473
      REF=${{ env.ACTION_REF || env.PR_REF || github.ref_name }}
      REPO=${{ env.ACTION_REPO || env.PR_REPO || github.repository }}
      REPO_ID=${{ env.PR_REPO_ID || github.repository_id }}
      echo "ref=$REF" >>"$GITHUB_OUTPUT"
      echo "repo=$REPO" >>"$GITHUB_OUTPUT"
      echo "repo-id=$REPO_ID" >>"$GITHUB_OUTPUT"
    shell: bash
    env:
      ACTION_REF: ${{ github.action_ref }}
      ACTION_REPO: ${{ github.action_repository }}
      PR_REF: ${{ github.event.pull_request.head.ref }}
      PR_REPO: ${{ github.event.pull_request.head.repo.full_name }}
      PR_REPO_ID: ${{ github.event.pull_request.base.repo.id }}

Permalink: https://github.com/pypa/gh-action-pypi-publish/blob/db8f07d3871a0a180efa06b95d467625c19d5d5f/action.yml#L114-L125

In normal intended operation, these expansions are used to establish a correct priority for outputs like ref and repo-id.

However, these expansions have a side effect: because they're done with ${{ ... }} and not with ${...} (i.e. normal shell interpolation), they can bypass normal shell quoting rules. In particular, if both env.ACTION_REF and env.PR_REF evaluate to empty strings, then the expression falls back to github.ref_name, which can be an attacker controlled string via a branch or tag name.

For example, if the attacker is able to set a branch name to something like innocent;cat${IFS}/etc/passwd, then the REF line may expand as:

REF=innocent;cat${IFS}/etc/passwd

which would set REF to innocent and then run the attacker's code.

Additional information about dangerous expansions can be found in zizmor's template-injection rule documentation.

Impact

The impact of this vulnerability is very low: the expression in question is unlikely to be evaluated in normal operation, since env.ACTION_REF should always take precedence.

In particular, the action is not vulnerable in many popular configurations, i.e. those where pull_request or release or a push: tags event is used to call the action.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
📦GitHub Actions	`pypa/gh-action-pypi-publish`	all versions	1.13.0

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pypa/gh-action-pypi-publish. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update pypa/gh-action-pypi-publish to 1.13.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vxmw-7h4f-hqxh is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-vxmw-7h4f-hqxh is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-vxmw-7h4f-hqxh. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary `gh-action-pypi-publish` makes use of GitHub Actions expression expansions (i.e. `${{ ... }}`) in contexts that are potentially attacker controllable. Depending on the trigger used to invoke `gh-action-pypi-publish`, this may allow an attacker to execute arbitrary code within the context of a workflow step that invokes `gh-action-pypi-publish`. ### Details `gh-action-pypi-publish` contains a composite action step, `set-repo-and-ref`, that makes use of expression expansions: ```yaml - name: Set repo and ref from which to run Docker container action id: set-repo-and-ref

O3 Security · Impact-Aware SCA

Is GHSA-vxmw-7h4f-hqxh in your dependencies?

O3 detects GHSA-vxmw-7h4f-hqxh across GitHub Actions dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works