Signature validity and publisher trust answer different questions. A signature can show that a key or identity signed an image, but a deployment must still restrict which identity is allowed to ship plugins. The reported Hyper-MCP default accepted arbitrary keyless identities and issuers, so the signature could pass without binding the plugin to a trusted…
Inspect the ClaimsCase · DiggingBeagle record
Hyper-MCP accepted any keyless signer for OCI WebAssembly plugins
A second Hyper-MCP issue allowed a keyless-signed OCI plugin from any accepted signer identity because publisher and issuer patterns were permissive by default.
Scope
Reported finding as of 2026-10-13; publication and observation dates are distinguished in the linked source. No production exploitation is inferred without explicit evidence.
Assessment profile
Assessment method- Exploitation
- not established
- Evidence
- Grade C
- AI role
- AGAINST AI
Basis and provenance
Evidence desk assessment of the pinned Claims and source provenance, checked against the public primary report or advisory. The OSV/CVE record describes permissive wildcard keyless signer and issuer matching. The listing does not independently establish field exploitation or an unambiguous fixed release; generated metadata is internally inconsistent. Impact remains unbanded because verified real-world affected scope and realized harm are not established. Findings are not independent reproduction by DiggingBeagle.
Assessed Oct 14, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-CP5-HYPERMCP-ANY-SIGNER-1 · CLM-CP5-HYPERMCP-ANY-SIGNER-2 · OSV CVE-2026-108699: Hyper-MCP unsigned publisher identity restriction
At a glance
Authenticating that an OCI image was signed is insufficient when the accepted signer identity is not limited to an approved publisher. A malicious plugin can be self-signed under an unrelated identity and still satisfy the permissive policy, with effects bounded by the WebAssembly host capabilities. Digest pinning alone does not repair this…
Read the implicationsNo deployment-specific exploitation was verified. Upstream default-policy changes and reliable fixed releases require direct maintainer verification.
Limits and uncertaintyFull account
Signature validity and publisher trust answer different questions. A signature can show that a key or identity signed an image, but a deployment must still restrict which identity is allowed to ship plugins. The reported Hyper-MCP default accepted arbitrary keyless identities and issuers, so the signature could pass without binding the plugin to a trusted publisher.
This is independent of the mutable-tag time-of-check problem in CVE-2026-108698. A digest-pinned, consistently resolved image still needs signer policy, and a perfectly constrained publisher identity still needs verification of the exact loaded digest. The described effect remains limited by the capabilities configured for the WebAssembly plugin.
Claims & evidence
CLM-CP5-HYPERMCP-ANY-SIGNER-1CVE-2026-108699 describes cosign_verify_args accepting arbitrary signer identities and OIDC issuers in affected Hyper-MCP versions through 0.8.3.supported
Basis: reported finding
- supportsOSV CVE-2026-108699: Hyper-MCP unsigned publisher identity restrictionprimary disclosure
Summary and Details: cosign_verify_args; signer and issuer matching
CLM-CP5-HYPERMCP-ANY-SIGNER-2An adversary able to control the plugin image reference could sign malicious WebAssembly using a keyless certificate and run it with configured host, filesystem or environment capabilities.supported
Basis: reported finding
- supportsOSV CVE-2026-108699: Hyper-MCP unsigned publisher identity restrictionprimary disclosure
Details: malicious signed plugin and capability scope
Implications
Authenticating that an OCI image was signed is insufficient when the accepted signer identity is not limited to an approved publisher. A malicious plugin can be self-signed under an unrelated identity and still satisfy the permissive policy, with effects bounded by the WebAssembly host capabilities. Digest pinning alone does not repair this publisher-authorization mistake.
Controls and mitigations
- Require explicit allowed signer identities and OIDC issuers in Cosign verification policy instead of wildcard expressions.
- Bind plugin approval to the expected publisher and exact digest, and limit WASM host filesystem, network and environment capabilities even for signed plugins.
Unknowns and contradictions
- No deployment-specific exploitation was verified.
- Upstream default-policy changes and reliable fixed releases require direct maintainer verification.
Sources and citation
Material revision history
- Oct 13, 2026 · Published version · first publication · revision 144