CVE-2026-23744 – MCPJam Inspector Docker Lab

This repo is a tiny Docker lab to compare a vulnerable vs patched build of MCPJam Inspector for CVE-2026-23744.

It’s meant for learning and for building a public security portfolio: quick setup, clear evidence, and screenshots.

⚠️ Ethics / scope: Only test on systems you own or have explicit permission to test. This repo is for local reproduction and documentation.

What this lab demonstrates

• Vulnerable version (1.4.2) listens on 0.0.0.0:6274 inside the container (network-reachable if you publish the port).
• Patched version (1.4.3) listens on 127.0.0.1:6274 inside the container (loopback-only), which prevents access from outside the container even if you publish a host port.
• The API surface (/api/mcp/connect) exists and responds without an auth challenge in the vulnerable setup.

This matches the vendor advisory / public reports:

• GitHub Advisory (GHSA): https://github.com/advisories/GHSA-232v-j27c-5pp6
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-23744

Repo layout

.
├── docker-compose.yml
├── vuln/
│   └── Dockerfile
├── patched/
│   └── Dockerfile
└── docs/
    └── (screenshots go here)

Prerequisites

• Docker + Docker Compose
• curl

Quick start

Build and run both containers:

docker compose up -d --build

Check they’re up:

docker compose ps

Expected:

• inspector_vuln_142 published on 127.0.0.1:6274
• inspector_patched_143 published on 127.0.0.1:6275 (but it should not be reachable from the host)

Validation steps

2) API responds (no auth gate visible)

The endpoint is present and responds with a validation error when required fields are missing:

curl -i -X POST http://127.0.0.1:6274/api/mcp/connect \
  -H 'Content-Type: application/json' \
  -d '{}'

Expect HTTP/1.1 400 and something like:

{"success":false,"error":"Failed to parse request body","details":"Unexpected end of JSON input"}

3) Binding difference (the real patch behavior)

Inside the containers, check which address is listening on port 6274:

# vulnerable
docker exec -it inspector_vuln_142 sh -lc "apk add --no-cache iproute2 >/dev/null 2>&1; ss -lnt | grep 6274"

# patched
docker exec -it inspector_patched_143 sh -lc "apk add --no-cache iproute2 >/dev/null 2>&1; ss -lnt | grep 6274"

Expected result:

• vuln: 0.0.0.0:6274
• patched: 127.0.0.1:6274

4) Why the patched port mapping “doesn’t work” (expected)

Even though we map 127.0.0.1:6275 -> container:6274, the patched container listens only on its own loopback interface. So from the host, you should see a connection close / empty reply.

curl -v http://127.0.0.1:6275/

Expected: not reachable (this is the mitigation working).

To prove the patched UI still works, curl from inside the container:

docker exec -it inspector_patched_143 sh -lc "apk add --no-cache curl >/dev/null 2>&1; curl -i http://127.0.0.1:6274/"

Expected: HTTP/1.1 200.

5) Proof of process execution

During local testing on the vulnerable container, I attached strace to the Inspector server process and observed it spawning a child process and calling execve().

I’m intentionally not including a ready-to-run exploit payload here.

What to capture:

execve("/bin/sh", ["sh","-c", "..."], ...) = 0

execve("/usr/bin/...", [...], ...) = 0

the child process exiting normally (status 0)

Credits / references

• GitHub Advisory (GHSA-232v-j27c-5pp6): https://github.com/advisories/GHSA-232v-j27c-5pp6
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-23744

Disclaimer

This repository is for defensive research, education, and reproducible verification in a controlled environment. Do not use it against systems you don’t own or have permission to test.