CVE-2026-30861 - WeKnora MCP stdio command injection

WeKnora versions 0.2.5 through 0.2.9 expose a command-injection risk in MCP stdio configuration validation. The dangerous production shape is not just the argument parser: a user who can register or obtain an API token, create an MCP service, and test or run that service can turn user-controlled stdio launch configuration into code execution with the WeKnora process privileges.

The fixed version is 0.2.10+. Reviewers should expect more than a version bump: the PR should remove untrusted stdio launch authority, make MCP service creation policy explicit, and close unauthenticated or self-service paths that let untrusted users reach MCP service execution.

When to use it

Use this recipe when a repository, WeKnora deployment, or agent service lets users create MCP services or configure stdio launch settings. It is designed for source-code remediation, MCP process-launch hardening, registration-policy review, and audit evidence that untrusted users cannot turn service creation into command execution.

Inputs

  • WeKnora version, MCP service registration flow, API token policy, stdio launch config, auth settings, and deployment manifest.
  • Source paths that validate MCP service definitions, parse executable/argument fields, launch stdio processes, test services, or grant API tokens.
  • Regression fixtures for arbitrary executables, absolute paths, package manager commands, allowed service templates, and low-privilege callers.
  • Runtime boundary evidence: service account privileges, filesystem reach, environment variables, credentials, network egress, and who can register MCP services.

Affected versions

Package Vulnerable versions Fixed versions
github.com/Tencent/WeKnora >=0.2.5, <0.2.10 0.2.10+

Indicator-of-exposure

  • The repository builds, vendors, deploys, wraps, or pins WeKnora versions 0.2.5 through 0.2.9, including Docker images, Helm charts, compose files, Terraform modules, runner images, or forked source.
  • WeKnora registration, invitation, API-token creation, or workspace creation is reachable by untrusted users, trial users, tenants, public internet traffic, or identity providers without explicit admin approval.
  • MCP service creation, testing, or execution accepts user-controlled stdio transport configuration, command names, arguments, environment variables, or package-runner tools such as npx or uvx.
  • The WeKnora process can access document stores, embeddings, model-provider keys, cloud credentials, package-manager tokens, internal networks, mounted workspaces, or deployment secrets.

Quick checks:

rg -n "Tencent/WeKnora|weknora|mcp-services|transport_type|stdio_config|ValidateStdioConfig|ValidateStdioArgs|npx|uvx|register|signup|invitation|allow.*registration" .
go list -m all | rg "github.com/Tencent/WeKnora"
rg -n "weknora:(0\\.2\\.[5-9]|v0\\.2\\.[5-9])|github.com/Tencent/WeKnora v0\\.2\\.[5-9]" .

If this repository deploys WeKnora only through images or charts, inspect the rendered deployment output and image tags, not just Go module files.

Remediation strategy

  • Upgrade all controlled WeKnora dependencies, forks, images, charts, manifests, SBOMs, and deployment references to 0.2.10+.
  • Disable user-defined MCP stdio transport unless the service definition comes from a reviewed, signed, administrator-owned catalog.
  • Replace command and argument blocklists with a fail-closed MCP launch policy: users select approved tools by ID; the server owns command paths, arguments, environment variables, working directories, and network/filesystem limits.
  • Require explicit admin approval, verified identity, or tenant policy before a user can create, test, or run an MCP service.
  • Run MCP servers with a low-privilege runtime identity, no package-manager tokens, no model-provider keys unless required, constrained filesystem and network access, and auditable per-service execution logs.
  • Review MCP service records and execution logs for suspicious stdio services if affected versions were exposed.

The prompt

You are remediating CVE-2026-30861 / GHSA-r55h-3rwj-hcmg, a WeKnora MCP stdio
configuration command-injection vulnerability. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades WeKnora, removes untrusted
  stdio launch authority, hardens MCP service registration and execution
  policy, refreshes generated artifacts, and documents operator review, or
- TRIAGE.md if this repository does not own an affected WeKnora runtime or
  cannot make a safe patch.

## Rules

- Scope only CVE-2026-30861 and directly related WeKnora MCP stdio launch,
  registration, and service-execution hardening.
- Do not reproduce the public exploit, run command-execution probes, create
  malicious MCP services, or test against live WeKnora deployments.
- Do not print, commit, or expose JWTs, API tokens, model-provider keys,
  package-manager tokens, document contents, embeddings, tenant IDs, or MCP
  service secrets.
- Do not keep user-controlled stdio command or argument fields reachable by
  untrusted users behind a larger blacklist.
- Do not auto-merge.

## Steps

1. Inventory every WeKnora dependency, fork, image, Helm chart, compose file,
   Kubernetes manifest, Terraform module, deployment overlay, SBOM, generated
   manifest, and documentation reference controlled by this repository.
2. Determine every resolved WeKnora version. A target is vulnerable if it
   resolves to `>=0.2.5, <0.2.10`.
3. Search for MCP service creation, service testing, stdio transport, command
   validation, argument validation, environment variable handling, `npx`, `uvx`,
   registration, invitation, API-token issuance, tenant onboarding, and feature
   flags that expose MCP service execution.
4. Classify who can create or test MCP services:
   - repository operators only;
   - tenant administrators;
   - authenticated users;
   - self-registered users;
   - unauthenticated/public users through registration or invitation gaps.
5. Upgrade WeKnora to `0.2.10+` everywhere this repository controls versions.
   Refresh Go module files, lockfiles, images, charts, deployment render output,
   generated docs, SBOMs, vulnerability exceptions, and dependency reports.
6. Remove user-defined stdio launch authority. Where the product still needs
   MCP integrations, replace command and argument inputs with approved tool IDs
   backed by a repository-owned or administrator-owned catalog.
7. Add or update MCP launch policy so the server owns command paths, arguments,
   environment variables, working directories, filesystem mounts, package
   runner access, network egress, timeout, memory, and runtime identity.
8. Harden access to MCP service creation and testing:
   - require verified identity and explicit tenant or admin authorization;
   - disable open registration if it grants MCP service execution;
   - add rate limits and audit logs for service create/test actions;
   - fail closed when tenant policy is missing.
9. Add safe tests that do not execute commands:
   - dependency resolution rejects WeKnora versions before `0.2.10`;
   - untrusted users cannot create or test stdio MCP services;
   - command, args, env, and package-runner fields are ignored or rejected for
     non-catalog services;
   - approved catalog tools still resolve through server-owned configuration;
   - audit logs record service IDs and policy decisions without secrets.
10. Add a PR body section named `CVE-2026-30861 operator actions` that states:
    - WeKnora versions before and after;
    - every deployable WeKnora target changed or triaged;
    - who can create, test, and run MCP services after the patch;
    - whether stdio transport remains enabled, for which catalog entries, and
      who owns them;
    - which MCP service records and execution logs operators should review;
    - whether model-provider, package-manager, cloud, or document-store
      credentials should be rotated due to prior exposure.
11. Run relevant validation: Go tests, policy tests, API authorization tests,
    deployment rendering, container build, chart lint, SBOM refresh,
    dependency/security scans, and a non-executing MCP service policy test.
12. Use PR title:
    `fix(sec): remediate CVE-2026-30861 in WeKnora MCP stdio`.

## Stop conditions

- No affected WeKnora runtime, fork, image, deployment artifact, or generated
  manifest is controlled by this repository.
- All controlled targets already resolve WeKnora `0.2.10+`, generated artifacts
  are current, and stdio launch is not user-controlled.
- MCP stdio service creation is intentionally available to untrusted users;
  write TRIAGE.md with the product/security owner decision required before
  patching.
- Verification would require executing commands, creating malicious MCP
  services, using live tokens, or inspecting production tenant data.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades WeKnora, disables user-defined stdio launch, governs MCP service creation, adds negative tests, and documents operator cleanup.
  • Or a TRIAGE.md file that lists inspected files, owner, observed version, registration boundary, process-launch boundary, required fix, and residual risk.
  • The output must include exact validation commands and must not execute arbitrary commands, package managers, local files, or production MCP services.

Verification - what the reviewer looks for

  • No module, image tag, chart, manifest, SBOM, or deployment artifact resolves WeKnora >=0.2.5, <0.2.10.
  • User-controlled MCP service definitions cannot supply stdio commands, arguments, environment variables, package runners, or working directories.
  • MCP service creation and testing require explicit authorization beyond self-registration.
  • Tests cover denial of untrusted stdio service creation without executing command payloads.
  • Operator notes identify MCP service records, logs, and credentials that need post-upgrade review.

Watch for

  • Upgrading Go module files while deployment images, Helm values, or compose files still pin a vulnerable WeKnora release.
  • Replacing one argument blacklist with another blacklist instead of removing user-controlled process launch.
  • Self-service registration paths that still grant API access to create or test MCP services.
  • MCP catalog entries that secretly expand to package runners or shell-like commands in production.
  • Logs that include tokens, document contents, embeddings, or full MCP service environment variables.

References