Description

MCPHub is a unified hub for centrally managing and dynamically orchestrating multiple MCP servers/APIs into separate endpoints with flexible routing strategies. Prior to version 1.0.32, the built-in prompt and resource controllers perform no role checking. The mutating POST/PUT /api/prompts* and POST/PUT /api/resources* routes are attached to the authenticated router with no admin gate, and the handlers never read req.user. The DAO singletons they write are consulted first — ahead of any connected MCP server — for every session in handleGetPromptRequest / handleReadResourceRequest. A non-admin can therefore create, overwrite, and shadow global prompt templates and resources that all other users are served. The scored impact is the unauthorized integrity violation (creation/tampering/shadowing of globally-served records); stored prompt injection into other users' LLM sessions is a downstream consequence of that tampering. This issue has been patched in version 1.0.32.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-31T18:17:19.910Z",
  "pubdate": "2026-08-31T18:17:19.910Z",
  "executiveSummary": "MCPHub versions prior to 1.0.32 contain a critical broken access control vulnerability originating from insufficient authorization checks within prompt and resource controllers.\nThe vulnerability allows authenticated non-administrative users to perform unauthorized write operations, specifically via POST and PUT requests to /api/prompts* and /api/resources* endpoints.\nBecause the system lacks an admin gate and fails to validate user identity against the requested operation, unauthorized users can create, modify, or overwrite global prompt templates and resources.\nThese manipulated records are prioritized by DAO singletons over legitimate data from connected MCP servers, ensuring the malicious content is served to all users within the environment.\nThe risk implications include unauthorized integrity violations and the facilitation of stored prompt injection attacks, potentially compromising downstream LLM sessions by injecting malicious instructions or data into the user experience.\nSuccessful exploitation does not require administrative privileges, only a standard authenticated session within the MCPHub instance.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the prompt and resource controllers within MCPHub versions prior to 1.0.32. Although these routes are defined within an authenticated router context, the application logic fails to implement role-based access control (RBAC) or check the identity provided in the req.user object during state-changing operations.\nSpecifically, the POST and PUT methods targeting the /api/prompts* and /api/resources* endpoints lack an administrative gatekeeper. Consequently, the controller handlers process incoming requests without verifying if the authenticated user possesses the authorization to modify global configuration or prompt repositories.\nThe system architecture utilizes DAO (Data Access Object) singletons that serve as the primary source of truth for prompt and resource retrieval. During subsequent execution flow—specifically within the handleGetPromptRequest and handleReadResourceRequest functions—the application consults these DAO singletons before querying connected MCP servers. Because the DAO singletons store the attacker-controlled or modified content, this malicious data is effectively shadowed or served preferentially over legitimate service responses.\nAn attacker can exploit this by crafting malicious POST or PUT payloads that overwrite existing global templates or inject new ones. Once these records are written to the DAO, they become globally persistent. Any user or LLM session interacting with the MCPHub will then receive this tampered data. In the context of LLM sessions, this facilitates a stored prompt injection attack, where an attacker can supply malicious instructions that are ingested by other users' LLM environments, potentially leading to unauthorized data exfiltration, arbitrary code execution within the LLM context, or manipulation of the user's workflow.\nThe exploitation path is straightforward: 1. Authenticated user identifies valid resource/prompt paths; 2. Attacker submits a POST/PUT request with the desired payload to the vulnerable endpoint; 3. The controller processes the write operation without validating user roles; 4. The malicious entry is stored in the DAO; 5. Global requests trigger the DAO lookup, serving the malicious prompt/resource to all system consumers."
}