Eclipse Theia CVE-2026-82217: Agent Mode could write outside the workspace
Missing workspace containment in Agent Mode file tools let model-supplied paths reach files available to the Theia backend. Version 1.75.0 fixes it.
- AUTHOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLISHED
- 31 August 2026
- READING TIME
- 17 min read
- TOPIC
- AI Security
Today’s CVE-2026-82217 shows how a defect in a seemingly simple file tool can turn prompt injection into a host-level integrity failure. In Eclipse Theia 1.73.0 up to, but not including, 1.75.0, file-change tools used by AI Agent Mode resolved a model-supplied path without verifying that the result remained inside the active workspace. The model could consequently write or delete a file outside the project with the privileges of the Theia backend’s operating-system user.
The record carries CVSS 3.1: 8.8 (High) and CWE-22, improper limitation of a pathname to a restricted directory. Eclipse Theia 1.75.0 is the fixed version. The source record names writeFileContent, suggestFileContent, and replacement and state helpers. Agent Mode raises the stakes because changes can be applied without a separate confirmation dialog.
This does not mean every instruction in Theia instantly executes code. It does create a clear chain: untrusted content influences the model, the model selects a path, the backend performs an operation outside the workspace, and a shell, SSH service, build tool or application later consumes the modified file.
Where the expected boundary ended
A user opening a repository normally assumes that an agent with editing permission can change that repository. This is more than a convenient mental model. The workspace is the boundary used to assess a diff, review history, recover files and limit automation scope.
In affected releases, a model-generated path reached the resolver but the result did not undergo reliable containment validation. A sequence containing .. could move into a parent directory. An absolute path bypassed the starting point, while a home-expanded path could reach the account running the backend. The same weakness covered more than file creation; helpers for suggestions, replacements and change state were involved.
Safe validation cannot simply search for the string ... Code must normalise and resolve the path, account for operating-system syntax, symbolic links and case behaviour, and then compare the result with a canonical base directory. The check must also hold at the moment of use: a decision made before a symbolic-link change may be invalidated by a race.
Why a model increases reachability
In a conventional editor, a file-write argument originates from a user’s direct action or extension code. In an agent tool, the model generates that argument from its entire context: the user message, repository files, search results, documentation, logs and externally retrieved text. Some of that context is untrusted.
An attacker therefore need not persuade an operator to type an out-of-project path. They can place an instruction in a dependency README, issue, code comment, data file or web page processed by the agent. This is indirect prompt injection: the human requests a legitimate task, while working material contains an instruction attempting to take over model decisions.
Prompt injection does not create magical privileges. It exercises tools already granted to the agent. Here, the broken path boundary meant that advertised “workspace editing” effectively became “file operations available to the backend account.” That is the difference between a response-quality problem and a security vulnerability.
From a file write to code execution
An out-of-workspace write can directly affect confidentiality or integrity, but the most consequential targets are files later consumed as instructions. The CVE record identifies shell startup files and ~/.ssh/authorized_keys. The same analysis should cover package-manager configuration, version-control hooks, IDE tasks, user services, host-mounted CI scripts and directories watched by another service.
Not every target is reachable in every deployment. A container may expose a read-only home, the backend may use an account without a real home directory, and SSH may be absent. Conversely, a development environment often has broad access to source code, repository credentials, package-registry tokens and tooling sockets. That makes the 8.8 score consistent with potential impact even though steering model output is a prerequisite.
Deletion matters too. An agent could damage configuration, sources outside the current project or data shared by multiple workspaces. A repository snapshot does not restore a target that was never part of the repository.
Who is affected by CVE-2026-82217
Products and environments built on Eclipse Theia 1.73.x or 1.74.x are in scope when they expose AI Agent Mode with file-change tools. A Theia package in a dependency tree does not by itself prove reachability. Answer four questions:
- which version is present in the running image or application;
- whether Agent Mode and the named tools are available to users;
- which privileges, home directory and mounts the backend receives;
- whether the agent processes untrusted repositories or external content.
For white-label products, the product version may not match underlying Theia package versions. Inspect the lockfile, SBOM and image. Desktop, remote workspace and browser frontend with a server backend have different impact areas: the operation runs wherever the component executing the file tool resides.
Priority: upgrade and constrain the process
The primary fix is upgrading to Eclipse Theia 1.75.0 or a later compatible release and rebuilding the product that embeds it. If rapid rollout is impossible, disable Agent Mode or remove its write, suggest and delete capabilities. A system prompt telling the agent not to leave the workspace is not a security control.
The operating-system layer should contain the next failure. Run the backend under a dedicated non-administrative user. Mount only required directories, expose secrets briefly and at minimal scope, and consider a read-only home plus an isolated ephemeral workspace. Do not provide a Docker socket or broad cloud credentials to an agent environment without a documented need.
Capability design matters as well. A tool should receive a workspace-scoped handle or resource identifier, not an arbitrary system pathname. The backend—not the model and not the frontend—must enforce canonical containment. High-impact operations should require approval that displays the full normalised path and proposed change.
Safely validating the fix
A regression test does not need to touch a real home directory. Create an isolated temporary directory containing a workspace and a neighbouring canary file. Exercise a small path matrix: a normal project file should work; parent traversal, an absolute path, a home-directory form and a symbolic-link escape should all fail before writing or deletion.
Test every function named in the advisory, not only writeFileContent. Regressions often arise when one entry point is fixed while a shared helper or alternate path retains old behaviour. On Windows, include drive letters, UNC paths, separators and case normalisation; on POSIX systems, cover symlinks and mounts.
After upgrading, inspect failure behaviour. The user should receive a clear workspace-boundary error, but output should not reveal unnecessary host structure. Trusted telemetry should record the session identifier, tool and normalised destination for denied operations.
Hunting for abuse
Search tool logs for parent-directory components, home paths, drive letters or resolved targets outside the project root. Correlate operation time with prompts, context sources and model identifiers. Prioritise changes to startup files, SSH keys, shell configuration, package-manager settings and automatically executed files.
If agent telemetry did not retain destinations, use auditd, EDR, filesystem journals, shell history and snapshot metadata. Review child processes and outbound connections after suspicious modifications. In an ephemeral environment, examine the base host and secret systems rather than only a destroyed container.
The absence of a suspicious repository diff does not rule out exploitation—the essence of the CVE is writing outside Git’s observed scope. When a credible modification of executable or configuration material is suspected, rebuild the environment from a trusted image and rotate credentials available to the backend.
Source facts and Breachroad conclusions
The 1.73.0–<1.75.0 range, affected tool classes, missing containment check and possible escalation through host-consumed files come from the CVE record prepared by the Eclipse Foundation. Deployment threat modelling, mount recommendations, telemetry and the regression plan are Breachroad’s conclusions. The sources do not report confirmed exploitation in production.
Primary sources
- Eclipse Security report for CVE-2026-82217
- Eclipse Theia 1.75.0
- Eclipse Theia repository — referenced commit
- NVD: CVE-2026-82217
The workspace boundary must be enforced by code, not an instruction to the model. Our secure AI implementation workshops teach teams to design agent capabilities, approval and environment isolation. For products with high-impact tools, controlled AI red teaming can establish whether untrusted context can capture real operations.


