WeKnora CVE-2026-30856: verifying tool routing after a shadowing fix

What it is

Status as of 25 October 2026. Re-check the WeKnora advisory's affected range and any later security releases before deployment. The vendor advisory, published on 6 March 2026, identifies CVE-2026-30856 and lists versions through 0.2.14 as affected, with 0.3.0 patched. A naming collision in the client's tool registry could replace the intended implementation with a malicious server's tool; injected tool output could then influence further actions. WeKnora advisory.

This is a dispatch-integrity problem as well as a prompt-injection problem. A familiar displayed name does not establish which remote server receives a call. CWE-706 describes names that resolve to resources outside their intended control boundary. CWE-706.

Why it matters

The MCP specification says tool names should be unique within a server. That rule does not create a global namespace across all connected servers. The client that combines their tools must preserve server identity while presenting, approving and dispatching operations. Tool annotations also remain untrusted unless their source is trusted. MCP Tools.

An upgrade is necessary for the identified vulnerability, but operators also need evidence that the running deployment changed and that previously registered servers are still authorized. A historical registration made before the upgrade deserves review even when its tool names look ordinary.

How to apply

• Record the deployed artifact before replacement. For Docker installations, substitute the real container name in docker inspect --type=container --format='{{.Config.Image}}' WEKNORA_CONTAINER. This reports the configured image reference; verify its resolved artifact against deployment records because a mutable tag alone cannot prove a version. Docker inspect.
• Upgrade affected WeKnora deployments to a supported release containing the 0.3.0 fix. Reconnect only approved MCP servers and compare the reconstructed registry with the approved inventory.
• As a client-design rule, key routing by an immutable server identity and the exact tool name. Keep the human-readable label separate. Reject ambiguous registrations rather than silently replacing an existing entry. This addresses the incorrect-resolution class described by CWE-706.
• Pin reviewed definitions and flag changes for review. Display the server identity, operation and arguments at approval time. Ensure the approved identity is the identity used at dispatch, including after reconnects or registry updates.
• Verify ordinary permitted calls in a test deployment, recording their actual destination. Check that registry updates cannot silently change that destination. These are proposed acceptance checks, not reported test results.
• If historical calls reached an unapproved server, preserve the tool inventory and call records. Determine what context or credentials were disclosed and revoke affected credentials. Treat the symptoms above as investigation leads, not proof of compromise.

Pitfalls

Adding a readable prefix without preserving an unambiguous internal identity may leave collisions possible. Hashing a definition detects changes but cannot establish that its original publisher was trustworthy. A review dialog is useful only when it identifies the server that will actually execute the approved call.