The report
Two vulnerability records published October 11 describe independent ways for a Hyper-MCP OCI WebAssembly plugin to pass a misleading signature check. One concerns the artifact that was checked. The other concerns the identity that was allowed to sign it. Both require attention before loading third-party plugins with host, filesystem or environment capabilities.
In CVE-2026-108698, the loader resolves a mutable OCI tag to obtain a manifest and Cosign subsequently verifies a separately resolved tag. A registry capable of returning different content for the two resolutions can lead to an unsigned manifest being loaded while a signed manifest passes verification. The decisive mistake is not the absence of cryptography but the lack of a binding between the object verified and the object consumed.
In CVE-2026-108699, the default keyless-verification configuration accepted any signer certificate identity and OIDC issuer. An attacker controlling the plugin image reference could use a legitimately issued Sigstore keyless certificate for an unintended publisher. A signature here proves the image was signed, but not that it came from the publisher the deployment intended to trust.
Three separate checks before loading a plugin
| Question | Why it matters | Relevant disclosure |
|---|---|---|
| Did the verifier and loader bind to the same digest? | Mutable tags can resolve to different manifests over time | Tag-resolution race |
| Is the signer explicitly authorized for this plugin? | Any valid keyless identity is not an authorized publisher | Permissive signer policy |
| What host capabilities can the resulting WASM module exercise? | A malicious plugin's effects depend on host-granted authority | Both disclosures |
The records describe hyper-mcp through 0.8.3 as affected. Their OSV conversion also contains an inconsistent version range that simultaneously marks 0.8.3 last_affected and fixed. That derived field is not a reliable safe-upgrade claim. Each record gives a fixing Git commit; an operator should confirm the exact deployed commit or a release demonstrably containing the change, rather than assume that version 0.8.3 is safe.
Neither the race disclosure nor the signer disclosure establishes a production breach. They explain why a passing signature check needs an authenticated publisher, immutable artifact identity and controlled runtime authority as independent properties. Fixing only one leaves the other checks unresolved.