Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain control of registry responses for the plugin tag
-
DeliveryServe signed benign manifest to Cosign verifier
-
ExploitServe unsigned malicious manifest to loader
-
ExecutionLoad unsigned WASM plugin as trusted
-
ImpactExecute with configured host capabilities
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture TOCTOU prevention
|
| Exploitation Conditions | Exploitation requires that hyper-mcp (≤0.8.3) be configured to load WASM plugins from an OCI registry with Cosign signature verification enabled as the trust control. The attacker must be able to control or tamper with registry responses for the resolved tag (malicious/compromised registry, man-in-the-middle on the registry connection, or registry cache poisoning) and must win the time-of-check/time-of-use gap so that Cosign and the loader resolve the tag to different manifests. Limiting factors: the AT:P / race-condition requirement means the attacker needs an active position on the registry channel rather than a single unauthenticated request, and the ultimate impact is bounded by the host capabilities the operator granted to plugins; deployments that pin digests instead of mutable tags, or do not expose registry traffic to tampering, are not realistically exploitable. |
| Impact | This is a genuine, well-characterized supply-chain integrity flaw rather than a hollow high-CVSS entry, but its real-world urgency is tempered by exploitation prerequisites. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) scores 8.3 and is dominated by VI:H - the core impact is execution of attacker-controlled, unsigned WebAssembly plugins with whatever host capabilities the operator configured. The AT:P (attack requirements present) metric is the critical qualifier: the attacker must be positioned to control registry responses for the OCI tag and win the time-of-check/time-of-use gap (CWE-367) between what Cosign verifies and what the loader actually pulls, serving a signed manifest to the verifier and an unsigned malicious one to the loader. No EPSS score, CISA KEV listing, or public POC was provided in the input, so there is no signal of active or widespread exploitation - consistent with a recently disclosed research finding (VulnCheck advisory plus a hackmd technical writeup) rather than a mass-exploited bug. Net: credible and impactful for anyone running hyper-mcp with signature verification as their trust control, but exploitation is conditional on registry/network control, which bounds it toward targeted scenarios over opportunistic mass abuse. |
| Exploit ScenarioDerived | An attacker who can manipulate OCI registry responses (via a compromised/malicious registry, MITM, or cache poisoning) serves hyper-mcp a signed, benign manifest when Cosign verifies the tag, then returns a different unsigned manifest pointing to a malicious WebAssembly plugin when load_wasm actually fetches it. hyper-mcp treats the plugin as verified and executes it with the configured host capabilities. No public exploit code was identified at time of analysis, though a detailed technical writeup of the TOCTOU exists. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 11, 2026
Signature verification bypass in hyper-mcp through 0.8.3 (src/wasm/oci.rs, load_wasm) lets an unauthenticated remote attacker who controls or tampers with OCI registry responses for a resolved tag load and execute unsigned WebAssembly plugins that were never covered by the Cosign signature check. The flaw is a time-of-check/time-of-use race (CWE-367): Cosign verifies a separately resolved tag while the loader consumes a different manifest, so a malicious registry can serve a signed manifest to the verifier and an unsigned malicious one to the plugin loader, with the payload then running under whatever host capabilities the operator granted. Exploitation is constrained - it requires signature-verified OCI plugin loading to be enabled, an active position on the registry channel, and winning the resolution race - and no public exploit code or confirmed active exploitation was identified at time of analysis.
RemediationAI
No vendor-released patch was identified at time of analysis, so mitigation must focus on removing the attacker's ability to make tag resolution diverge. The most effective compensating control is to stop consuming mutable tags: pin every plugin reference to an immutable manifest digest and validate that the digest loaded matches the digest verified, which collapses the TOCTOU window entirely - the trade-off is that plugin updates become manual and automation that relies on floating tags breaks. Additionally, treat the registry channel as untrusted: enforce TLS with certificate pinning or mTLS to the registry, restrict egress to an allowlist of approved registries to blunt man-in-the-middle and cache-poisoning paths, and avoid shared or untrusted registry proxies; these measures reduce but do not eliminate risk if a legitimate registry is itself compromised. Where the feature is not essential, disable OCI-based plugin loading with signature verification as the sole trust anchor and distribute plugins through a channel the host fully controls. Finally, run plugins with the minimum host capability set so that a bypassed signature yields limited integrity impact, and monitor plugin loads for manifest-digest changes between verification and execution. Consult the upstream project at https://github.com/hyper-mcp-rs/hyper-mcp and the VulnCheck advisory at https://www.vulncheck.com/advisories/hyper-mcp-through-0.8.3-oci-plugin-signature-verification-toctou-race-condition for updated fix guidance.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
hyper-mcp is a Rust MCP (Model Context Protocol) host that can fetch and run WebAssembly plugins distributed as OCI artifacts. In the affected code path (src/wasm/oci.rs, load_wasm), the plugin manifest is resolved by tag and the Cosign signature is validated against a separately resolved reference rather than against the exact manifest bytes ultimately passed to the loader - a classic CWE-367 TOCTOU split between the check and the use. OCI tags are mutable pointers, so any party able to influence registry responses (a malicious or compromised registry, a man-in-the-middle on the registry connection, or a poisoned cache/proxy) can make the two resolutions diverge and substitute an unsigned manifest. The CPE cpe:2.3:a:hyper-mcp-rs:hyper-mcp:*:*:*:*:*:*:*:* indicates all releases up to and including 0.8.3 are in scope; the trust boundary being bypassed is the Cosign signature control that is supposed to gate plugin code before it executes with host privileges. The assessed CVSS:3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N) reflects integrity as the dominant impact with high attack complexity driven by the race condition and the attacker's need for an active registry position, rather than a trivially replayable request.
Know when Hyper Mcp gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N
AC:H reflects the TOCTOU race and need to control registry responses; PR:N as no app authentication is required; I:H for execution of unsigned plugins, C:L minor exposure, A:N.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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 ViewAI
hyper-mcp deployments that pull WebAssembly plugins from OCI registries are exposed to a signature-verification bypass in versions through 0.8.3, where a tampered or malicious registry response can cause unsigned plugin code to execute with whatever host privileges the operator granted. Because hyper-mcp typically brokers access to backend tools and credentials on behalf of AI agents, a successful bypass would let an attacker run arbitrary plugin code inside trusted automation paths, undermining the integrity guarantees leadership relies on for the agent platform. No vendor-released patch has been identified, and no public exploit code or confirmed active exploitation was identified at time of analysis, so near-term risk must be managed through configuration and architecture changes rather than patching.
No vendor-released patch identified at time of analysis. Interim mitigations: disable signature-verified OCI plugin loading (or all remote OCI plugin loading) on exposed instances; pin plugins to immutable digests rather than mutable tags so a single resolved artifact is both verified and loaded; restrict egress to an allowlisted registry and require authenticated registry access; and run hyper-mcp with least-privilege host and service-account capabilities so any unsigned plugin executes with minimal authority.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
EUVD-2026-96998
GHSA-phv4-c98f-77h3
NVD
CVE.org
EPSS
Exploit-DB