VulnerabilityPublished 22 Apr 2026Updated 5 May 2026

@samanhappy/mcphub · MCPHub has Path Traversal via Malicious MCPB Manifest Name

Affects @samanhappy/mcphubSource GCVE Database

CVSS 7.2 High : upgrade to 0.12.13 soon.

Data as of 27 Oct 2026, 00:07 UTC

CVSS 4.0 base score

7.2High

How severe the flaw is on the 0–10 CVSS scale.

Patch: Available – fixed in 0.12.13

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

Attack Vector: Network
Attack Complexity: Low
Attack Requirements: None
Privileges Required: Low
User Interaction: None
Vulnerable system confidentiality: None
Vulnerable system integrity: High
Vulnerable system availability: High
Subsequent system confidentiality: None
Subsequent system integrity: None
Subsequent system availability: None

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: Low: The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Attack Requirements: None: The successful attack does not depend on the deployment and execution conditions of the vulnerable system. The attacker can expect to be able to reach the vulnerability and execute the exploit under all or most instances of the vulnerability.
Privileges Required: Low: The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
User Interaction: None: The vulnerable system can be exploited without interaction from any human user, other than the attacker.
Vulnerable system confidentiality: None: There is no loss of confidentiality within the Vulnerable System.
Vulnerable system integrity: High: There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the vulnerable system. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the vulnerable system.
Vulnerable system availability: High: There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the Vulnerable System; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the Vulnerable System (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).
Subsequent system confidentiality: None: There is no loss of confidentiality within the Subsequent System or all confidentiality impact is constrained to the Vulnerable System.
Subsequent system integrity: None: There is no loss of integrity within the Subsequent System or all integrity impact is constrained to the Vulnerable System.
Subsequent system availability: None: There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System.

Definitions: FIRST CVSS v4.0 specification.

What to do

Upgrade @samanhappy/mcphub to 0.12.13.

Affected software

Product	Affected	Fixed in
npm@samanhappy/mcphub	Affected <0.12.13	Fixed in 0.12.13

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

**MCPB File Upload Handler** extracts a ZIP file and reads `manifest.json` from it. The `name` field in the manifest is directly concatenated into a file path (line 107) without any sanitization or path traversal character validation. An attacker can craft a malicious MCPB file where `manifest.name` is set to something like `../../../etc/malicious`, causing the file to be extracted to an arbitrary location on the file system. The `cleanupOldMcpbServer` function (line 110) also uses the unsanitized name, potentially allowing deletion of arbitrary directories. ## 1. Summary - **Vulnerability Type**: Path Traversal (CWE-22) - **Sink Location**: src/controllers/mcpbController.ts:107 - **Vulnerability Description**: The `name` field from an uploaded MCPB manifest is used directly, without sanitization or normalization, to construct a file system path for directory creation and move operations, which may lead to path traversal attacks. ## 2. Analysis Logic ### Step 1: Inspect the identified sink (src/controllers/mcpbController.ts:106-116) I examined the upload handler and located the file system sink where `manifest.name` is used to build the final extraction path and write files to that path. ```ts // src/controllers/mcpbController.ts:106-116 // Use server name as the final extract directory for automatic version management const finalExtractDir = path.join(path.dirname(mcpbFilePath), `server-${manifest.name}`); // Clean up any existing version of this server cleanupOldMcpbServer(manifest.name); if (!fs.existsSync(finalExtractDir)) { fs.mkdirSync(finalExtractDir, { recursive: true }); } // Move the temporary directory to the final location fs.renameSync(tempExtractDir, finalExtractDir); ``` Analysis: `manifest.name` is used to build `finalExtractDir`, which is then operated on by `fs.mkdirSync` and `fs.renameSync`. These are file system write/move operations, so if `name` is user-controlled and unsanitized, this is a path traversal sink. Next, I traced the origin of `manifest.name`. ### Step 2: Trace the source of `manifest.name` in the upload handler (src/controllers/mcpbController.ts:83-104) I traced back the data flow to see how the manifest is read and validated. ```ts // src/controllers/mcpbController.ts:83-104 const manifestPath = path.join(tempExtractDir, 'manifest.json'); if (!fs.existsSync(manifestPath)) { throw new Error('manifest.json not found in MCPB file'); } const manifestContent = fs.readFileSync(manifestPath, 'utf-8'); const manifest = JSON.parse(manifestContent); // Validate required fields in manifest if (!manifest.manifest_version) { throw new Error('Invalid manifest: missing manifest_version'); } if (!manifest.name) { throw new Error('Invalid manifest: missing name'); } ``` Analysis: `manifest` is parsed directly from `manifest.json` inside the uploaded archive. The only check on `manifest.name` is that it is non‑empty; there is no sanitization, normalization, or allow‑list validation. Next, I confirmed the entry point for uploading MCPB files to verify user control. ### Step 3: Trace the HTTP entry point in src/routes/index.ts:297-299 I located the route that exposes the upload handler. ```ts // src/routes/index.ts:297-299 // MCPB upload routes router.post('/mcpb/upload', uploadMiddleware, uploadMcpbFile); ``` Analysis: The `/mcpb/upload` endpoint invokes `uploadMiddleware` and `uploadMcpbFile`, so user‑supplied uploads are the source of the manifest content. Next, I verified the upload middleware behavior. ### Step 4: Confirm the upload middleware (src/controllers/mcpbController.ts:8-38) I inspected how the uploaded file is received and stored. ```ts // src/controllers/mcpbController.ts:8-38 const storage = multer.diskStorage({ destination: (_req, _file, cb) => { const uploadDir = path.join(process.cwd(), 'data/uploads/mcpb'); if (!fs.existsSync(uploadDir)) { fs.mkdirSync(uploadDir, { recursive: true }); } cb(null, uploadDir); }, filename: (_req, file, cb) => { const timestamp = Date.now(); const originalName = path.parse(file.originalname).name; cb(null, `${originalName}-${timestamp}.mcpb`); }, }); const upload = multer({ storage, fileFilter: (_req, file, cb) => { if (file.originalname.endsWith('.mcpb')) { cb(null, true); } else { cb(new Error('Only .mcpb files are allowed')); } }, limits: { fileSize: 500 * 1024 * 1024, // 500MB limit }, }); export const uploadMiddleware = upload.single('mcpbFile'); ``` Analysis: The upload middleware only checks file extension and size. It does not restrict or validate the contents of the archive or `manifest.name`. Therefore, `manifest.name` is user‑controlled input. Next, I checked whether any sanitization or normalization is applied before reaching the sink. ### Step 5: Verify lack of path validation on `manifest.name` in src/controllers/mcpbController.ts:92-110 I verified that no path sanitization occurs between parsing and usage. ```ts // sr

CWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (opens in a new tab)
Base weaknessLikelihood of exploit: HighCWE Top 25 (2025): #6OWASP Top 10 A01:2025: Broken Access Control (opens in a new tab)
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
Implementation · Input Validation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks…
Implementation · Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174).
OWASP Cheat Sheets
Authorization (opens in a new tab)
OWASP ASVS 4.0.3
V12.3.1 (opens in a new tab)
Attack patterns
Path Traversal (opens in a new tab)
Using Slashes and URL Encoding Combined to Bypass Validation Logic (opens in a new tab)
Manipulating Web Input to File System Calls (opens in a new tab)
Using Escaped Slashes in Alternate Encoding (opens in a new tab)
Using Slashes in Alternate Encoding (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…

What to do

Affected software

Description

WeaknessesCWE-22

Technical details

References

Community reviews

Related threats