CVE-2026-108698 in hyper-mcp
Summary
by MITRE • 10/11/2026
hyper-mcp through 0.8.3 contains a signature verification bypass vulnerability in load_wasm in src/wasm/oci.rs that verifies the Cosign signature of a separately resolved tag rather than the loaded manifest. Attackers controlling registry responses for the tag can serve an unsigned malicious manifest to the loader and a signed one to Cosign, executing unsigned WebAssembly plugins with configured host capabilities.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in hyper-mcp versions through 0.8.3 represents a critical flaw in the signature verification logic within the load_wasm function located in src/wasm/oci.rs. This component is responsible for loading and validating WebAssembly modules from an OCI registry, specifically checking signatures generated by Cosign to ensure integrity and authenticity of the loaded artifacts. The core technical deficiency lies in how the system handles reference resolution during this validation process. Instead of verifying the signature against the exact manifest that is subsequently executed or loaded into memory, the implementation resolves a separate tag for verification purposes. This architectural decision introduces a fundamental mismatch between what is being signed and what is actually being used by the application runtime.
This discrepancy creates an opportunity for a sophisticated attack scenario where an adversary with control over registry responses can exploit this separation of concerns. By manipulating the DNS or HTTP responses directed at different endpoints, an attacker can serve two distinct artifacts to the same client process depending on which endpoint is queried during specific phases of execution. Specifically, when the Cosign verification module queries for signature validation, it receives a legitimate, properly signed manifest associated with the resolved tag. However, when the actual loader component retrieves the WebAssembly binary to execute or load into memory, it fetches a different manifest that has not been subjected to the same rigorous cryptographic checks and may contain unsigned, malicious code.
The operational impact of this signature verification bypass is severe, particularly in environments where hyper-mcp executes plugins with elevated host capabilities. Since the loaded WebAssembly module lacks verified integrity guarantees, an attacker can inject arbitrary code into the execution environment. This effectively neutralizes the security boundary provided by Cosign signatures and allows for remote code execution within the context of the application running hyper-mcp. The ability to execute unsigned plugins means that any pre-existing vulnerabilities in the host system or sensitive data accessible to the process could be compromised, leading to potential full system takeover depending on the privileges granted to the WebAssembly runtime.
This vulnerability aligns with CWE-345, which describes issues related to insufficient verification of data authenticity, and specifically maps to MITRE ATT&CK technique T1608, involving the upload of malicious tools or implants via compromised registries. The attack vector relies on supply chain compromise tactics where trust is established through cryptographic signatures but applied incorrectly due to implementation flaws in reference resolution. To mitigate this risk, immediate updates to hyper-mcp beyond version 0.8.3 are required as they address the logic error by ensuring that signature verification targets the exact manifest instance being loaded. Additionally, organizations should implement strict registry access controls and monitor for anomalous behavior such as multiple distinct manifests being served under similar tags during validation phases.