CVE-2020-7598

What it actually does

The flaw is a prototype pollution vulnerability in minimist before 1.2.2. When attacker-controlled input is parsed as command-line-style arguments, specially crafted keys such as __proto__ or constructor can add or modify properties on Object.prototype. In JavaScript applications, those polluted inherited properties may then affect unrelated objects created later in the same process. The practical impact depends on how the affected application uses parsed values, but can include configuration tampering, security control bypass, data exposure, denial of service, and in some unsafe code paths potential code execution through polluted options passed to sensitive APIs.

Why it matters to the business

Applications or products that bundle vulnerable minimist versions can behave unpredictably if they parse untrusted input, potentially leading to incorrect authorization decisions, service instability, or manipulation of application configuration. The issue is not listed in CISA KEV and has a relatively low EPSS score, but public exploit techniques exist and the vulnerability has been known since 2020, so lingering exposure generally indicates dependency hygiene risk. For the provided affected product data, cacti/cacti Git builds should be brought to the fixed commit 6ea486a00a56c1e43fac07a3ccb7c56acca17b3c or later.

How an attack unfolds

An attacker first identifies an application path, API, job runner, webhook, or administrative feature that passes externally supplied values into minimist or a vulnerable bundled copy of minimist. The attacker submits argument-like input containing prototype pollution keys, commonly using __proto__ or constructor.prototype syntax. The vulnerable parser writes attacker-supplied values onto Object.prototype instead of treating them as ordinary input. Subsequent application logic then reads those inherited properties as if they were legitimate own properties on normal objects. If those properties influence access checks, templates, subprocess options, serialization, or configuration defaults, the attacker may alter behavior, cause errors, expose data, or reach a more severe exploit chain. The supplied threat actor field appears to reference an unrelated vulnerability label rather than a named actor, so no specific actor attribution should be inferred from it.

How to fix it

Upgrade minimist to version 1.2.2 or later wherever it is used directly or transitively; current maintained dependency versions should be preferred over the minimum fixed version. For cacti/cacti Git builds identified in the input, update to commit 6ea486a00a56c1e43fac07a3ccb7c56acca17b3c or later. Regenerate lockfiles after dependency updates and confirm that no older minimist copy remains under nested node_modules paths. If immediate upgrade is not possible, prevent untrusted input from being passed into minimist, reject keys named __proto__, prototype, constructor, constructor.prototype, and equivalent encoded or nested forms, and use safe object creation patterns such as Object.create(null) for dictionaries. Also add defensive checks that require Object.prototype.hasOwnProperty.call(obj, key) before trusting object properties in security-sensitive logic.

How to confirm the fix worked

Confirm the fix by inspecting dependency manifests and lockfiles for minimist versions earlier than 1.2.2, including transitive copies. Use package manager tooling such as npm ls minimist, yarn why minimist, pnpm why minimist, software composition analysis, or container image scanning to verify the resolved version. For cacti/cacti Git deployments, verify the running source revision is commit 6ea486a00a56c1e43fac07a3ccb7c56acca17b3c or later. Test representative input paths with benign prototype pollution probes and confirm that Object.prototype is not modified after parsing. Regression tests should verify that parsed objects do not expose attacker-controlled inherited properties and that dangerous keys are rejected or neutralized.

Typical attack path

1. Find an exposed feature that accepts user-controlled parameters, request bodies, webhook content, job definitions, or command-line-like input.
2. Determine whether the application or bundled product uses a vulnerable minimist version before 1.2.2 to parse that input.
3. Send a crafted payload containing keys such as __proto__, constructor.prototype, or constructor[prototype].
4. Cause the vulnerable parser to write attacker-controlled properties onto Object.prototype.
5. Trigger follow-on application functionality that consumes ordinary JavaScript objects affected by the polluted prototype.
6. Abuse the resulting behavior change for configuration manipulation, authorization bypass, data access, denial of service, or further exploitation depending on available sinks.

How to detect it

To assess prior exploitation, review HTTP access logs, API gateway logs, WAF events, application logs, webhook/job-runner logs, and any audit logs for submitted parameters containing prototype pollution keys. Focus on payloads using __proto__, constructor.prototype, constructor[prototype], prototype, or URL-encoded variants. In Node.js application logs, look for unusual TypeError exceptions, unexpected configuration values, authorization anomalies, or repeated requests immediately before crashes or behavior changes. Inspect process-level telemetry for unexpected child process creation only if the application has code paths where polluted options could influence command execution. For forensics, examine package-lock.json, yarn.lock, pnpm-lock.yaml, npm-shrinkwrap.json, and node_modules/minimist/package.json to identify vulnerable versions that were present at the time of suspicious activity. Because prototype pollution often leaves no durable file artifact by itself, absence of filesystem indicators does not rule out exploitation; logs containing crafted keys are the most useful retrospective evidence.

• __proto__
• %5F%5Fproto%5F%5F
• constructor.prototype
• constructor%2Eprototype
• constructor[prototype]
• constructor%5Bprototype%5D
• --__proto__.polluted=
• --constructor.prototype.polluted=
• __proto__[polluted]
• __proto__%5Bpolluted%5D
• ?__proto__=
• &__proto__=
• ?constructor.prototype=
• &constructor.prototype=
• Object.prototype
• node_modules/minimist/package.json
• "minimist": "1.2.0"
• "minimist": "1.2.1"
• minimist@1.2.0
• minimist@1.2.1

What your security team should do

• Inventory applications, containers, and bundled products that include minimist before 1.2.2, with priority on internet-facing services and systems that parse user-controlled input.
• Upgrade affected dependencies or affected product builds; for cacti/cacti Git, move to commit 6ea486a00a56c1e43fac07a3ccb7c56acca17b3c or later.
• Search application, API gateway, WAF, and job execution logs for prototype pollution payloads containing __proto__, constructor.prototype, constructor[prototype], or encoded equivalents.
• Add input validation or WAF rules to block prototype pollution keys at exposed boundaries while patching is in progress.
• Review code paths that use parsed arguments to influence authorization, templating, subprocess execution, serialization, or configuration defaults.
• Add dependency scanning to CI/CD and fail builds that introduce vulnerable minimist versions or other known prototype pollution packages.