How severe is GHSA-x6gv-2rvh-qmp6?

GHSA-x6gv-2rvh-qmp6 has a CVSS score of 10/10, rated CRITICAL. Immediate patching is strongly recommended.

Which packages are affected by GHSA-x6gv-2rvh-qmp6?

GHSA-x6gv-2rvh-qmp6 affects the following packages: m00nl1ght-dev/steam-workshop-deploy (GitHub Actions), BoldestDungeon/steam-workshop-deploy (GitHub Actions). Ecosystems affected: GitHub Actions.

How do I fix GHSA-x6gv-2rvh-qmp6?

Update m00nl1ght-dev/steam-workshop-deploy to 4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x6gv-2rvh-qmp6 is resolved across your whole dependency graph.

How do I detect GHSA-x6gv-2rvh-qmp6 in my GitHub Actions dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for m00nl1ght-dev/steam-workshop-deploy. 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-x6gv-2rvh-qmp6 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-x6gv-2rvh-qmp6?

O3 pinpoints whether GHSA-x6gv-2rvh-qmp6 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-x6gv-2rvh-qmp6 actively exploited in the wild?

No public exploit code has been indexed for GHSA-x6gv-2rvh-qmp6 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-x6gv-2rvh-qmp6 published, and has it been updated?

GHSA-x6gv-2rvh-qmp6 was published on August 13, 2025 and was last updated on October 27, 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-x6gv-2rvh-qmp6

CRITICAL

m00nl1ght-dev/steam-workshop-deploy: Exposure of Version-Control Repository to an Unauthorized Control Sphere and Insufficiently Protected Credentials

Published

Aug 13, 2025

Updated

Oct 27, 2025

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

Blast Radius

2 pkgs affected

📦m00nl1ght-dev/steam-workshop-deploy📦BoldestDungeon/steam-workshop-deploy

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

The steam-workshop-deploy github action does not exclude the .git directory when packaging content for deployment and provides no built-in way to do so. If a .git folder exists in the target directory (e.g., due to a local Git repo, custom project structure, or via the actions/checkout workflow), it is silently included in the output package. This results in leakage of sensitive repository metadata and potentially credentials, including github personal access tokens (PATs) embedded in .git/config.

Many game modding projects require packaging from the project root as the game expects certain files (assets, configuration, metadata) to be present at specific root-level paths. Consequently, the .git directory often exists alongside these required files and gets packaged unintentionally, especially when using actions/checkout.

While github hosted runners automatically revoke ephemeral credentials at the end of each job, the severity of this issue increases dramatically in other CI environments:

Self-hosted runners may store long-lived tokens or secrets.
Developers may maintain their own .git folders with embedded PATs or remotes tied to private repositories.
The workflow may run without the actions/checkout action, distributing the .git directory present on the running machine if it exists in the directory.

A real example of an affected mod can be found here: https://github.com/BoldestDungeon/wildermyth-drauven-pcs/security/advisories/GHSA-7j9v-72w9-ww6w

Details

Who is affected:

Any user of steam-workshop-deploy operating in an environment where .git exists in the packaging directory.
Any user of steam-workshop-deploy operating in an environment where the actions/checkout workflow is used and then the .git directory is inadvertently generated within the packaging directory (greatly reduced severity due to the ephemeral nature of github actions).

Impact

The severity of this issue for downstream components can range from 0.0 (no credentials, sensitive metadata, or private source code were present in the packaging directory) to 10.0 (extremely sensitive, high privilige credentials or source code from private repositories were exposed).

The actual severity depends primarily on the permissions, scope, and nature of the exposed data:

Low/none (0.0-3.9): Only non-sensitive repository metadata was exposed, no credentials were present, or only public facing code was included.
Medium(4.0-6.9): Credentials with limited repository access and/or short lifespan (e.g., ephemeral tokens) were exposed, or non-sensitive private code was disclosed.
High/critical (7.0-10.0): Long-lived tokens, organization-wide credentials, or credentials with administrative privileges were exposed, potentially enabling full repository compromise, secret extraction, code tampering, or the complete leak of private repository source code.

As such, each downstream consumer should independently assess their exposure by reviewing packaged artifacts for the presence of .git directories or other credentials, and evaluating both the sensitivity of any credentials found and the confidentiality of any included source code.

Consequences may include:

Unauthorized access to git repositories via exposed PATs.
Tampering with repository code or metadata.
Malicious CI behavior (triggering workflows, reading secrets).
Disclosure of commit history, remote origins, or other sensitive internal structure.

Recommendation

This issue should be considered severe due to the potential exposure of sensitive tokens and repository metadata. Although most workflows that use steam-workshop-deploy also employ actions/checkout, which handles tokens and credentials more securely, there are legitimate use cases where actions/checkout is not used or where custom .git folders exist. Additionally, actions/checkout can accept a on-emphemeral tokens as a parameter for its workflow. In such cases, long-lived or sensitive credentials may be packaged and exposed, greatly increasing the risk of unauthorized access and repository compromise. Therefore, this issue should be considered severe regardless of common usage patterns.

Downstream:

Downstream components should revoke any credentials or PATs associated with workflows or repositories that use this github action

This Deployment Action

The action should exclude .git/ and other common sensitive file(s) by default from all packaging operations.
A deployignore or similar mechanism should be introduced to give users finer control of what files or directories are included for deployed artifacts

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
📦GitHub Actions	`m00nl1ght-dev/steam-workshop-deploy`	all versions	4
📦GitHub Actions	`BoldestDungeon/steam-workshop-deploy`	all versions	2.0.0

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for m00nl1ght-dev/steam-workshop-deploy. 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 m00nl1ght-dev/steam-workshop-deploy to 4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x6gv-2rvh-qmp6 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-x6gv-2rvh-qmp6 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-x6gv-2rvh-qmp6. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary The `steam-workshop-deploy` github action does not exclude the `.git` directory when packaging content for deployment and provides no built-in way to do so. If a `.git` folder exists in the target directory (e.g., due to a local Git repo, custom project structure, or via the `actions/checkout` workflow), it is silently included in the output package. This results in leakage of sensitive repository metadata and potentially credentials, including github personal access tokens (PATs) embedded in `.git/config`. Many game modding projects require packaging from the project root as the

O3 Security · Impact-Aware SCA

Is GHSA-x6gv-2rvh-qmp6 in your dependencies?

O3 detects GHSA-x6gv-2rvh-qmp6 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