Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-10-11T14:17:04.113Z",
  "pubdate": "2026-10-11T14:17:04.113Z",
  "executiveSummary": "The vulnerability identified in hyper-mcp versions through 0.8.3 involves a critical signature verification bypass within the OCI (Open Container Initiative) artifact loading process. The flaw resides in src/wasm/oci.rs, where the implementation fails to bind the cryptographic signature verification to the specific manifest being loaded. Instead, the system verifies the Cosign signature of a separately resolved tag.\nThis architectural flaw allows an attacker capable of manipulating registry responses to perform a Time-of-Check Time-of-Use (TOCTOU) style attack or a manifest confusion attack. By providing a signed manifest for verification and an unsigned malicious manifest for execution, an attacker can bypass integrity checks entirely. The impact is significant: the execution of arbitrary, unsigned WebAssembly plugins with elevated host capabilities. This compromises the security sandbox of the plugin runtime, potentially allowing unauthorized access to host resources, data exfiltration, or arbitrary code execution within the host environment. The vulnerability represents a high risk to systems deploying WebAssembly plugins via OCI registries, as it undermines the trust anchor for remote artifact execution.",
  "technicalDetails": "The root cause of this vulnerability is an improper implementation of OCI artifact verification in the load_wasm function within src/wasm/oci.rs. In secure OCI workflows, a signature (such as those generated by Cosign) must be cryptographically bound to the digest of the specific manifest intended for execution to ensure integrity and authenticity.\nIn hyper-mcp, the verification logic incorrectly decouples the signature check from the manifest payload. When the loader resolves a tag to an artifact, it performs signature verification against the resolved tag reference rather than verifying that the signature covers the specific content hash of the downloaded manifest blob. This creates a verification gap that can be exploited by an attacker who controls the registry traffic or can perform a Man-in-the-Middle (MitM) attack.\nThe attack flow occurs as follows: 1. The attacker publishes a benign, signed artifact at a target tag. 2. The attacker monitors or intercepts the registry request for the manifest associated with that tag. 3. During the validation phase, the system resolves the tag and verifies the signature of the 'authorized' manifest. 4. Upon successful validation, the loader fetches the actual manifest for execution. 5. The attacker serves a malicious, unsigned manifest during this fetch operation. Because the hyper-mcp loader does not re-verify the content hash of the downloaded binary against the verified signature, it executes the malicious WebAssembly code.\nThe exploitation bypasses the core security promise of Cosign, which is meant to ensure that only cryptographically signed images are executed. Because the malicious WebAssembly plugins are executed with configured host capabilities—which may include filesystem access, network sockets, or sensitive environment variables—the attacker gains the ability to escape the intended sandbox constraints. This vulnerability does not require authentication or specific privileges beyond the ability to manipulate registry responses. The post-exploitation impact allows for full control over the plugin execution context and potential lateral movement within the host system. Affected versions include all releases of hyper-mcp from inception through 0.8.3, as the logic lacks a direct digest-to-signature binding requirement."
}