al-ice.ai

The Project Brings Its Own Tools: Junie CLI and the MCP Config That Came With the Repository

AI Vulnerabilities & CVEs by al-ice.ai Editorial

JetBrains published six CVE records at 16:17Z on 15 October 2026, all sourced to cve@jetbrains.com. Five are the kind of thing a vendor security page is for: two stored XSS in TeamCity, a deserialization RCE in the TeamCity build messages protocol, an unauthenticated path traversal in Datalore, a missing authorisation check in YouTrack mail rules. The sixth is a single sentence that describes the central unsolved problem in agentic coding tools.

CVE-2026-111091, from JetBrains’ own advisory table, verbatim: “Code execution was possible via an untrusted project’s MCP server configuration.” Reported by syaifmax under the internal ticket JUNIE-3056, rated High by the vendor, fixed version given as 26.8.3, weakness CWE-829 — inclusion of functionality from an untrusted control sphere. The NVD record carries CVSS 3.1 7.8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), vulnStatus Awaiting Analysis, and a CISA SSVC decision recorded twelve minutes before publication reading exploitation: none, automatable: no, technicalImpact: total.

Junie is JetBrains’ coding agent; the CLI is its terminal form, the one you run inside a checkout. The advisory does not elaborate, and we will not invent a reproduction. But the mechanism does not need guessing, because JetBrains documents it in detail in the Junie CLI MCP configuration page.

The documentation is the threat model

Junie CLI supports two scopes for MCP server configuration. The user scope lives at ~/.junie/mcp/mcp.json and is, in the docs’ words, “available across all projects on your machine while remaining private to your user account.” The project scope is the interesting one, quoted verbatim:

Project scope: MCP server configs are stored in the
.junie/mcp/mcp.json file at the root of your project.
This file can be checked into version control and
shared across all team members.

And the connection types, also verbatim:

Remote: connect to a hosted server via HTTP/HTTPS.
Local: run on your machine (Docker, npx, or binary).

Put those two paragraphs together and the shape of CWE-829 is complete without a single line of reverse engineering. A file at a well-known path inside the repository names a command. The documented, intended, team-friendly behaviour is that the command is checked into version control and travels with the project. A local MCP server is a process Junie starts via Docker, npx, or a binary — which is to say, the config file is not data describing a tool, it is an instruction to execute something. Every property that makes project-scope MCP useful to a team also makes it a delivery mechanism when the project came from somewhere you do not control.

This is why the vector reads AV:L with UI:R rather than anything network-borne. Nobody attacks your machine across the wire. You clone a repository — a dependency you are evaluating, a fork you are reviewing, an issue reproduction someone attached, a template you are trying — and start the agent in it. That is the entire user interaction the metric requires, and it is an action developers perform without deliberation many times a week. The impact triple is C:H/I:H/A:H and the SSVC technical impact is total, which is correct: the server runs with your user’s privileges, in a session where the agent already holds whatever credentials you gave it.

A pattern this site keeps writing up

The repository-supplied agent configuration file is now one of the most reliably productive bug classes in the category. We covered Cursor’s MCP special-files handling in February and the TrapDoor supply-chain technique in May, which turned .cursorrules and CLAUDE.md into hijack surfaces by the same logic: a file the agent reads because the project author put it there, in a project whose author is a stranger. In October we found the same config files leaking credentials because the ecosystem treats them as ordinary committed artefacts. CVE-2026-111091 is the direct form of the problem rather than the oblique one — not instructions that persuade a model, but a command the runtime starts.

That distinction matters for defence. Prompt injection through a repository file is a probabilistic attack on a model’s judgement; a project-scope MCP entry is a deterministic attack on a launcher. No model is involved in deciding whether to run it, so no amount of model alignment, system-prompt hardening or tool-approval policy in the agent layer is in the path. The only control that can work sits where the config is loaded: a trust decision made before the file is honoured. This is the same place the five Roo Code approval bypasses failed — the gate was downstream of where the decision actually got made.

JetBrains appears to be converging on exactly that control. The Junie release notes for Release 26.10.5 (3579.5), dated 6 October 2026, list among the changes: “UX changes: trusted project on start, Notification Center, in-CLI notifications, removed the ○ ANSWER heading, mid-run steering”. A trust prompt when a project opens is the right primitive. We note, as the vendor presents it, that it appears under UX changes rather than under security, and we draw no connection between that line and this CVE — the advisory names 26.8.3, which is earlier.

The version you need is harder to identify than it should be

Which brings up the one piece of practical friction. JetBrains’ advisory and the CVE both say “before 26.8.3”. We scanned 500 published releases on the JetBrains/junie repository and found no release named exactly 26.8.3. The 26.8 line appears as Junie Release 26.8.31 (3013.5), published 2 September 2026 at 15:11:37Z, and 26.8.31 (3013.7) on 4 September at 21:37:10Z; subsequent stable lines run 26.9.7, 26.9.14, 26.9.21, 26.9.22, 26.10.5 and 26.10.12, the last published 15 October at 14:52:49Z — about ninety minutes before the CVE. Every shipped artefact also carries a build number in parentheses, and the npm packages use that build numbering rather than the marketing version at all: @jetbrains/junie-cli is at 1468.30.0 (27 April 2026) and @jetbrains/junie at 3110.7.0 (9 September 2026).

We are not going to assert which build first contained the fix, because the vendor has not said and the published release names do not resolve to the string in the advisory. What we can say is the operationally useful part: the fix predates the CVE record by weeks, every current release line is numbered far above it, and the correct action is to move to the current release rather than to hunt for a version string that may not exist as a tag. If you need certainty for a change record, the advisory’s ticket reference (JUNIE-3056) is the handle to ask JetBrains support about.

The rest of the batch

The five companions, with vendor severity and the fixed versions from the JetBrains table:

  • CVE-2026-111094 (High, NVD 8.1, CWE-502) — TeamCity: “Remote code execution via a whitelist bypass in the build messages protocol was possible.” Reported by HoYoSec Lufei. Fixed in 2026.2, 2026.1.4, 2025.11.8. This is the one to prioritise after Junie: deserialization RCE on a build server, on a product that spent earlier this month in KEV with ransomware behind it.
  • CVE-2026-111093 (High, NVD 7.5, CWE-23) — Datalore: unauthenticated path traversal via the report blob endpoint allowing arbitrary file reads. Reported by hieudc. Fixed in 2026.2.1. Note PR:N and UI:N on this one.
  • CVE-2026-111095 (High, NVD 8.0, CWE-79) and CVE-2026-111096 (Medium, NVD 6.7, CWE-79) — TeamCity stored XSS in the classic project overview and the classic build log. Both reported by Antoni Tremblay, both fixed in the same three releases.
  • CVE-2026-111092 (Medium, NVD 6.5, CWE-862) — YouTrack: mail rules allowed a project admin to execute cross-project issue commands. Reported by Antoni Tremblay.

What to do

  • Upgrade Junie CLI to the current release. The advisory’s 26.8.3 is well behind the 26.10.x line; moving to current is both simpler and strictly safer than trying to match the string.
  • Do not start an agent in a repository you have not read, and treat .junie/mcp/mcp.json as an executable file. Same for the equivalents in every other agent you run. Before the first agent run on any unfamiliar checkout, inspect the agent-config paths the way you would inspect a Makefile or a git hook — the question is “what command does this start”, not “does this look like config”.
  • Add agent-config paths to code review and to CI. A pull request that adds or edits .junie/mcp/mcp.json, .mcp.json, .cursorrules, CLAUDE.md or their siblings is a change to what executes on every reviewer’s machine. Most review processes still classify these as documentation. A path-based required-reviewer rule costs nothing and catches the untrusted-fork case before anyone clones.
  • Prefer user scope for anything that holds authority. JetBrains’ own documentation already carries the warning for the adjacent risk — “For project-scope installations, avoid sharing secrets or sensitive environment variables if the .junie/mcp/mcp.json file is committed to version control” — and the same boundary applies to execution. Servers you rely on belong in ~/.junie/mcp/mcp.json, where the project cannot define them.
  • Run untrusted-code review inside a container or VM. This is the only control that holds when a config-loading path turns out to be executable, and the class of bug it defends against is now recurring often enough to be an assumption rather than a precaution.
  • Patch TeamCity in the same change window. CVE-2026-111094 is a deserialization RCE on infrastructure that holds your signing keys and deploy credentials, and the product’s recent history argues for not deferring it.

Verification note. All six CVE identifiers, publication timestamps, CVSS 3.1 scores and vectors, CWE assignments, affected and fixed version data, vulnStatus values, the cve@jetbrains.com source identifier and the CISA SSVC decision points were read first-hand from the NVD 2.0 API. The advisory text, severity ratings, fixed versions, reporter credits and internal ticket references were read first-hand from the JetBrains security issues-fixed page; every sentence in quotation marks attributed to JetBrains is verbatim from that page, from the Junie CLI MCP configuration documentation (last modified 15 October 2026) or from the Junie release notes. Release names, tags and publication timestamps, including the absence of a release named exactly 26.8.3 across 500 published releases, were read first-hand from the GitHub API for JetBrains/junie; npm package versions and publication dates from the npm registry API. Brave Search was used for discovery and returned only CVE-mirror aggregators and automated scoring pages — no independent technical analysis of CVE-2026-111091 exists at time of writing. Nothing was installed, no Junie instance was run, no MCP configuration was authored, no repository was crafted or cloned to test this, and no third-party request was sent. The mechanism described is derived from JetBrains’ published documentation and the advisory’s own wording; we did not reproduce the vulnerability and make no claim about the specific code path, and the remediation guidance is our editorial analysis. We have no evidence of exploitation and imply none — the vendor-coordinated SSVC record states exploitation none.

Sources: