Moonshot CVE, separating the signal from the noise around CVE-2026-25046 and the build pipeline attack surface

What people usually mean when they type “moonshot cve”

Search traffic for moonshot cve is unusually messy because “Moonshot” is not a single product line, and “CVE” is both a global vulnerability identifier system and part of at least one company name. In practice, your search results tend to collapse into one of these buckets:

1. MoonshotAI (Kimi ecosystem), where the top result is commonly CVE-2026-25046 tied to Kimi Agent SDK publishing scripts. (NVD)
2. HPE Moonshot hardware management components, where older CVEs like CVE-2021-25140 show up. (NVD)
3. Moonshot CVE as a company (countering online violence), where the “CVE” in the name has nothing to do with vulnerability IDs. (moonshotteam.com)

If you came here as a security engineer trying to respond to an alert, write a risk note, or harden a release pipeline, you want bucket #1 first—then you want to explicitly rule out bucket #2/#3 so you don’t brief the wrong stakeholders.

The high-intent keyword variant that dominates: CVE-2026-25046

Across current top-ranking pages for “moonshot cve,” the most consistently clicked, high-intent refinement is simply the full identifier: CVE-2026-25046, often paired with “Kimi Agent SDK,” “execSync,” “command injection,” or “VS Code extension.” You see that phrasing repeated in the NVD entry, the GitHub Security Advisory, and vendor write-ups, which is why it becomes the natural “next query” people click. (NVD)

So let’s treat CVE-2026-25046 as the canonical meaning of “moonshot cve” in today’s engineering/security context, then we’ll circle back to the other Moonshot CVEs afterward.

CVE-2026-25046 in one paragraph, what’s vulnerable and what is not

CVE-2026-25046 הוא הזרקת פקודות issue in MoonshotAI’s Kimi Agent SDK repository where development-time publishing scripts (vsix-publish.js ו ovsx-publish.js) pass filenames into Node.js execSync() as a shell command string. Filenames containing shell metacharacters like $(cmd) can be interpreted by the shell, potentially executing arbitrary commands. The key constraint: the vulnerability is in repository development scripts; the published VS Code extension does not include those files, and typical end users are not affected. (NVD)

That single “note” is the difference between a consumer-impact incident and a release-pipeline risk.

Why this bug matters even if the CVSS looks “low”

Databases may label it low severity because they’re modeling a narrower path: the vulnerable scripts usually run in a maintainer’s environment or CI, not on every user’s machine. But if your organization builds or publishes anything—extensions, packages, containers, internal tools—CI is where high-value secrets live:

• registry tokens
• signing keys
• release credentials
• cloud credentials
• “god-mode” automation permissions

A “minor” injection primitive that fires inside CI can become a supply-chain event if it compromises what you ship.

This is exactly why the NVD wording emphasizes the mechanism (filenames → execSync string → shell interpretation) and adds the “end users not affected” scoping note—because the blast radius depends on where those scripts execute. (NVD)

The root cause pattern: string-to-shell execution with a disguised input channel

At its core, CVE-2026-25046 is not “AI agents are dangerous.” It’s a classic, evergreen foot-gun:

1. Build a command string
2. Insert a value you think is safe (here: a filename)
3. Execute it through a shell
4. The shell parses metacharacters and expands them

In the NVD description, the key phrase is that scripts “pass filenames to execSync() as shell command strings,” and filenames with metacharacters could execute arbitrary commands. (NVD)

Why filenames are an input channel in real pipelines

Security teams often say: “We don’t accept filenames from users.” That’s true for many apps—and irrelevant for CI. In CI/CD, filenames can originate from:

• artifacts downloaded from external locations
• archives extracted into the workspace
• caches restored from previous runs
• generated outputs whose names are templated from branch names, PR titles, tags, or commit messages
• malicious contributions in a repo (including dependency repos)

If any step can cause an attacker-controlled string to become a filename that later gets interpolated into a shell command, you’ve built the same primitive as CVE-2026-25046—whether or not you use Kimi Agent SDK.

What the advisory says, mapped to real exploit preconditions

Let’s translate the advisory statements into concrete “what must be true.”

What must be true to exploit

• The vulnerable scripts exist and are executed (vsix-publish.js, ovsx-publish.js). (NVD)
• A crafted filename containing shell metacharacters reaches the script. (NVD)
• The script constructs a shell command string and runs it with execSync() (which uses a shell when given a string). (NVD)

What an attacker typically needs

One of these conditions (not exhaustive):

• Control over an artifact that is downloaded/unzipped into the release workspace
• Ability to influence file naming via tags/branches/PR metadata that becomes a filename
• Compromise of a dependency or mirror that produces a file with a malicious name
• Direct repository contribution (in open source, a poisoned PR or compromised maintainer account is the nightmare scenario)

What the worst case looks like

If exploitation happens inside CI, “arbitrary command execution” can mean:

• exfiltrate CI secrets to an external host
• replace a release artifact with a trojan
• publish a malicious extension/package under a trusted name
• mint or steal tokens used for future releases

Again: this is why “end users not affected” does לא mean “ignore.”

The fix and the simplest safe rule: never feed filenames into a shell string

CVE-2026-25046 is fixed in Kimi Agent SDK 0.1.6 per NVD and the GitHub advisory. (NVD)

But the deeper fix is the engineering rule you can apply everywhere:

If you must run a system command, do not use a shell, do not build a single string, and never interpolate untrusted values (including filenames) into that string.

Bad pattern (what you’re trying to eliminate)

import { execSync } from "node:child_process";

// Attacker-controlled filename, directly or indirectly
const file = process.argv[2];

// ❌ Shell parses $(...) and other metacharacters
execSync(`some-tool publish ${file}`, { stdio: "inherit" });

Safe pattern A, use execFile/spawn with an argument array

import { spawnSync } from "node:child_process";

// Treat filenames as data, not syntax
const file = process.argv[2];

// ✅ No shell, arguments are passed as a list
const res = spawnSync("some-tool", ["publish", file], {
  stdio: "inherit",
  shell: false,
});

if (res.status !== 0) process.exit(res.status ?? 1);

Safe pattern B, if you absolutely must use a shell, hard-escape and constrain

This is the least preferred option. If business reality forces a shell, you still need:

• strict allow-lists
• canonicalization
• explicit escaping
• and you should log + fail closed on anomalies

But you should treat “must use shell” as technical debt with a deadline.

A practical CI hardening checklist that makes this class of bug much less scary

Even perfect code doesn’t fully save you if your CI is over-privileged. The playbook below is designed so that even if a string-to-shell primitive slips in, it can’t silently become a supply-chain breach.

1) Secrets discipline

• Use short-lived tokens (OIDC where possible) instead of long-lived registry secrets.
• Scope tokens to the minimal publish action; no broad repo admin tokens.
• Do not expose secrets to workflows triggered from untrusted forks.

2) Workflow isolation

• Separate “build/test” from “publish.”
• Only run publish on protected branches/tags with required approvals.
• Consider dedicated runners for release, with a clean workspace and no shared caches.

3) Artifact provenance

• Pin dependencies (lockfiles, digest-pinned containers).
• Verify downloaded artifacts (hash checks).
• Treat caches as untrusted unless you can prove they are immutable and controlled.

4) Pre-publish scanning

• Grep for dangerous primitives: execSync(, exec(, shell: true, backticks, bash -c, sh -c.
• Add guardrails that fail the build when these patterns appear in release scripts.

5) Release integrity

• Sign artifacts (where applicable).
• Generate SBOMs.
• Publish from reproducible builds when possible.

This is not hypothetical hygiene; it’s the direct operational answer to the mechanism described in the NVD entry. (NVD)

Detection, how to find “CVE-2026-25046-shaped” issues in your own repos

Quick repository-level search

If you maintain Node.js tooling:

• Find shell-string usage:
  • execSync(" and `execSync(“
  • exec(" and `exec(“
  • spawn( עם shell: true
• Find filename interpolation:
  • template strings that contain ${file}
  • concatenation "... " + file

Add a failing check to CI, simple but effective

# Fail the workflow if risky primitives appear in release scripts
grep -RIn --exclude-dir=node_modules \\
  -E 'execSync\\(|exec\\(|shell:\\s*true|bash\\s+-c|sh\\s+-c' \\
  scripts .github tools || true

This won’t prove exploitability. It will reliably surface the risky primitive at the heart of CVE-2026-25046. (NVD)

The table security teams actually need

פריט	What it means	Why you should care	Best action
Vulnerable component	Dev publishing scripts in Kimi Agent SDK repo	Impacts maintainers and CI, not typical end users	Upgrade to fixed version, remove shell-string execution (NVD)
Primitive	filename → execSync() string → shell	Filenames become an unexpected injection channel	שימוש spawnSync/execFile with args, shell:false
Typical blast radius	CI runner, publish environment	Secrets + signing + release creds live here	Split publish workflow, least privilege, protected releases
“End users not affected” note	Published VS Code extension doesn’t include these scripts	Don’t overreact with user-facing incident comms	Focus remediation on pipelines/maintainers (NVD)

Related CVEs you may see when searching “moonshot cve,” and why they’re different

CVE-2021-25140, HPE Moonshot Provisioning Manager

This is a separate universe: HPE Moonshot infrastructure management software. NVD describes an unauthenticated directory traversal in khuploadfile.cgi, and explicitly notes HPE recommends discontinuing use because the product is discontinued and not patched. (NVD)

If your environment still has this appliance, you’re not “patching a library.” You’re making an operational decision to remove/replace an unsupported component.

Don’t confuse “Moonshot CVE” the company with CVE identifiers

Moonshot (the company) works on countering online violence and threat reduction; “CVE” here is branding, not vulnerability numbering. (moonshotteam.com)

This distinction matters when you’re triaging tickets: I’ve seen teams waste hours trying to map “Moonshot CVE” into NVD because the acronym collides.

Two short, real-world scenarios

Scenario A, you’re a maintainer of a VS Code extension

You probably have scripts similar to vsix-publish.js. The lesson of CVE-2026-25046 is that release code deserves the same paranoia as production code—because it can become production code בעקיפין by shaping what you ship. (NVD)

פעולה: audit release scripts, remove shell-string execution, and lock down who can trigger publish.

Scenario B, you consume open-source tooling in CI

Even if you don’t use Kimi Agent SDK, you likely run third-party scripts during packaging/publishing. If your workflow downloads artifacts and uses shell-string commands, you are in the same risk class.

פעולה: treat artifacts and filenames as untrusted, and restrict secrets exposure in untrusted contexts.

Build-script vulnerabilities live in an awkward zone: they’re often “not exploitable for end users,” but they can be devastating in the wrong pipeline. The hard part for many teams is moving from “this seems risky” to verifiable evidence: what can an attacker actually reach, what tokens would be exposed, and which systems can be touched from the runner network?

That’s where an automated testing and verification workflow can help: model your CI runner environment as an attack surface (egress rules, reachable endpoints, secret scopes, publish permissions) and validate the assumptions quickly—especially when the question is not “is there a CVE” but “can this become a supply-chain incident in our setup.”

If you want a concrete example tied directly to moonshot cve / CVE-2026-25046, Penligent has already published a focused breakdown of this exact issue and why it’s fundamentally a publishing boundary problem rather than an end-user runtime problem. (penligent.ai)

הפניות

• NVD, CVE-2026-25046 (NVD)
• GitHub Security Advisory, MoonshotAI/kimi-agent-sdk, GHSA-mv58-gxx5-8hj3 (GitHub)
• SentinelOne vulnerability summary, CVE-2026-25046 (SentinelOne)
• NVD, CVE-2021-25140, HPE Moonshot Provisioning Manager (NVD)
• HPE security bulletin context around Moonshot Provisioning Manager lifecycle (HPE Support)
• Moonshot CVE — CVE-2026-25046 and the Publishing Script Trap That Turns Filenames Into Commands (penligent.ai)
• Log4Shell is the New SQLi, a modern retrospective on CVE-2021-44228 for the AI era (penligent.ai)
• AI Agents Hacking in 2026, defending the new execution boundary (penligent.ai)
• OpenClaw and VirusTotal, the skill marketplace became a supply-chain boundary (penligent.ai)
• Claude Code Security and Penligent, from white-box findings to black-box proof (penligent.ai)