[BUG] Follow-up on MCPJam inspector critical RCE Vulnerability Report

[c2an1]

Issue

• On October 27, I submitted a detailed report titled “MCPJam Inspector Critical RCE Vulnerability Report” via email to mcpjams@gmail.com
• On November 14, I received a response from founders@mcpjam.com indicating that the issue would be fixed as soon as possible.
• However, as of today, there has been no further communication, and after verification, the vulnerability still exists in the latest release (v1.3.12).
• This is a critical RCE vulnerability. Given that MCPJam Inspector is widely used, the continued presence of this vulnerability poses a significant security risk to users.
• Could you please clarify whether this vulnerability is currently being tracked and what the planned remediation approach is?

[matteo8p]

@c2an1 Thanks for following up. We chose to take no action on this issue after looking into the 0.0.0.0 day exploit that is the root cause of this vulnerability. My understanding is that it is a browser vulnerability that enables remote executions for any localhost process. Any localhost process is vulnerable to this. The fix should be on the browser side, with some remediation on the application side.

From the latest article discussing this vulnerability, we saw that browsers have already implemented blocking access to 0.0.0.0. I believe this issue is resolved, I'm interested to hear if you think this is valid take. If not, curious to hear what you believe is the best remediation steps!

[c2an1]

@matteo8p I believe there is a misunderstanding, and I would like to clarify that the vulnerability I reported is not the same as the “0.0.0.0-Day” browser vulnerability discussed in the article you referenced. In the detailed vulnerability report I sent to mcpjams@gmail.com, the PoC does not use 0.0.0.0 as the target IP.
The vulnerability I reported is an application-level service exposure issue:

• The application is binding/listening on 0.0.0.0, which means it listens on all network interfaces, not just 127.0.0.1.
• As a result, the service can be accessed directly from external networks, independent of any browser behavior.

In contrast, the article you referenced describes a browser-side vulnerability, where browsers historically allowed web pages to send requests to 0.0.0.0, potentially enabling attacks against localhost services. That issue is about how browsers interpret and allow access to 0.0.0.0 as a request destination.
These are two different threat models:

• Your article: Browser security boundary issue (payload target = 0.0.0.0)
• Reported issue: Service/network configuration issue (listener bound to 0.0.0.0)

The remediation is to change
server.listen(port, () => {
in inspector/bin/start.js to
server.listen(port, '127.0.0.1', () => {

This is due to server.listen(port, () => { is listening on 0.0.0.0

You may refer to the following patch, which addresses the same vulnerability that I discovered in witsy :
nbonamy/witsy@a23d4e5

[matteo8p]

Merged!

[matteo8p]

@c2an1 Really appreciate the help here.

[c2an1]

@matteo8p Thank you for the quick response and for addressing this critical RCE vulnerability. Given the popularity of this project (over 1.5k GitHub stars) and the severity of the vulnerability, can you request a CVE ID via the project’s GitHub Security page to ensure proper tracking and downstream user awareness? If any additional information or assistance is needed, I’m happy to help, thanks.

[c2an1]

@matteo8p After retesting the latest release, I would like to clarify that the fix for this critical vulnerability is not yet complete. The issue is still reproducible in the current version v1.4.2. Specifically, the vulnerability remains in the following location:
https://github.com/MCPJam/inspector/blob/v1.4.2/server/index.ts#L286 hostname: "0.0.0.0",