CVE-2026-105135, a code-injection flaw in InternLM MindSearch's Planner Agent, has a public PoC and no known fix. CVSS v3.1 10.0 (VulDB).
A critical code-injection flaw, CVE-2026-105135, affects InternLM's open-source MindSearch AI search agent. The bug sits in the Planner Agent, which runs Python generated by a language model. VulDB, acting as CNA, says the vendor was contacted early and never responded. No patch is known. A public proof of concept exists. Anyone running the MindSearch backend reachable from a network is exposed.
What happened
VulDB published CVE-2026-105135 on 4 October 2026. The record describes a code injection in ExecutionAction.run in mindsearch/agent/graph.py (component: Planner Agent) in MindSearch 0.1.0. It says the attack can be started remotely, the exploit is public, and the vendor did not respond. The weakness is CWE-74 (injection). GitHub has mirrored it as an unreviewed advisory, GHSA-4535-w5r2-pmqp, with no patched version listed.
A proof-of-concept gist dated 22 August 2026, linked from the advisory, says the flaw affects all public versions up to the latest main branch. There is no evidence of exploitation in the wild in the sources we read, and we have not seen the CVE on CISA's KEV catalogue. "Public PoC" is the accurate description today.
Why it matters
MindSearch is a popular project (6,935 GitHub stars, Apache-2.0). It is a multi-agent web search tool: a planner model breaks a question into a graph of sub-queries, which it expresses as Python code. The application then executes that code. If an attacker can influence what the model writes, they can make the server run their code.
Maintenance looks stalled. The last commit to main was on 4 July 2025, there are 48 open issues and 13 open pull requests, and one user asked in February 2025 whether the project is still maintained.
The risk is not new. In August 2024 a user opened issue #107, "Security: executing untrusted LLM generated code without sandboxing or sanitization", which reports this same exec-of-model-code problem through prompt injection, with a demo. A maintainer closed it as completed on 5 November 2024, with no comment and no linked commit. That is the day v0.1.0 was tagged, and exec is still on main. A vendor fix is therefore not something to wait for (we covered a similar public exploit with no fix in the MCP Fetch server).
Scores differ by version and source. VulDB's CVSS v3.1 base score is 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) and its CVSS v4.0 score is 9.3. NVD lists both as supplied by VulDB and has not yet analysed or scored the CVE itself. NVD lists CWE-74 and CWE-94 (code injection); GitHub lists only CWE-74. GitHub's advisory page displays the v4.0 score of 9.3, which explains the apparent mismatch. Its EPSS is 0.77%.
Technical details
How a request becomes code on the host.
On the current main branch, ExecutionAction.run in graph.py still passes the planner's code string to Python's exec with a globals and locals dictionary. We read the file on 5 October 2026; nothing in the code isolates the execution from the host.
The backend is a FastAPI app in mindsearch/app.py. By default it binds to 0.0.0.0 on port 8002, sets CORS allow_origins=["*"] together with allow_credentials=True, and exposes a POST /solve route. We saw no authentication in that file (we covered the same open-API-to-root pattern in Vibe-Trading). The README pairs the backend with React, Gradio or Streamlit frontends, all of which talk to port 8002.
At a high level, the public PoC does the following (we are not reproducing it). It sends a crafted query to /solve so that the model emits attacker-chosen Python in its plan, and the service then executes it. The gist says this needs only network access to the port, no credentials and no user interaction, and that it requires a working model behind the service. It says the code runs as the API process user, and its output shows uid=0(root). The repository's own Dockerfiles set no non-root user, so the API runs as root in them by default. The repo's Dockerfile also starts the server with --host 0.0.0.0 --port 8002, and docker/msdl/templates/docker-compose.yaml publishes 8002:8002 on all host interfaces.
This is prompt injection leading to code execution. The model is the bridge between untrusted text (the user's question, or web content the agent reads) and exec. Filtering the prompt is a weak defence, because the attacker only needs the model to emit the code.
What defenders should do
- Find every MindSearch deployment, including Docker containers, demos and internal tools, and check whether port 8002 is reachable from anywhere untrusted.
- Take it off the internet. Bind it to localhost or put it behind an authenticating reverse proxy or VPN, and do not rely on the frontend for access control. Check Docker port mappings: the repo's defaults publish 8002 on every interface.
- Localhost alone is not enough. The gist says the permissive CORS setting lets a malicious web page call
http://127.0.0.1:8002/solveon a developer's machine (we confirmed the CORS configuration in the code, not the drive-by itself). Restrict CORS to known origins or use an authenticating proxy even for local use, and do not leave a dev instance running while you browse. - Run it in a disposable container as a non-root user, with a read-only filesystem, no mounted secrets and egress limited to the model and search APIs.
- Remove API keys for the search engine and model from the process environment where you can, or rotate them if the service was exposed.
- Review logs for unexpected
/solverequests and for outbound connections or child processes from the service. - If you need the code path, consider replacing
execwith a sandboxed executor or a restricted graph-building API. This is our suggestion, not a vendor fix. - Watch the repository and the GHSA entry for a patch, and treat any later fix as unverified until you test it.
What is still unclear
- Whether any version other than 0.1.0 is affected. NVD lists only 0.1.0; the PoC claims everything through
main, and the code onmainstill usesexec. - Whether the vendor will ship a fix. None is known, issue #107 was closed with no visible fix, and the repository has had no commits since July 2025.
- Whether the flaw is being exploited. We found no reports.
- The final NVD scoring, since NVD's status is still "Received". We could not read VulDB's own page (HTTP 403) and relied on the NVD API record, which carries VulDB's data.
NVD returned no other MindSearch CVEs in a keyword search.