A path-traversal flaw let Theia’s AI Agent Mode write and delete files anywhere the backend user could reach, and the release that closed it described the change only as a breaking API change.
What happened
CVE-2026-82217 entered the National Vulnerability Database on Monday, August 31, 2026 at 9:17 a.m. Central. The Eclipse Foundation is the assigning authority, and the record scores the flaw 8.8 with the CVSS v3.1 vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, classified as CWE-22, path traversal.
The record’s own description is unusually specific about the mechanism: “In Eclipse Theia versions 1.73.0 up to but not including 1.75.0, the AI ‘Agent Mode’ file-change tools (writeFileContent, suggestFileContent, and the replacement and state helpers) resolved a model-supplied file path without a workspace-containment check.” A crafted relative path, an absolute path, or a tilde-expanded path lets the agent write or delete files outside the workspace. Because the path argument comes from model output, indirect prompt injection can steer it. Agent Mode applies its writes without a confirmation dialog.
Eclipse’s own vulnerability report, filed on its GitLab as work item 624, is blunter. It is titled “Remote Code Execution via AI Agent-Mode workspace-escape file write,” and it gives the payload directly: “a tool call such as writeFileContent({ path: "../.bashrc", content: "…" }) writes (or deletes) files outside the workspace with the privileges of the Theia backend OS user.” The route from a file write to code execution is the obvious one — shell startup files, or authorized_keys — and the report names both.
The root cause named in the report is that five tool handlers in file-changeset-functions.ts called resolveRelativePath() directly, skipping the containment helpers that existed alongside it — resolveToUri(), ensureWithinWorkspace(), and ensureAccessible(). The path-normalization logic preserved leading .. segments. The guards were in the codebase. Five call sites did not use them.
The report credits zenniskayy and gives a report date of July 24, 2026. Its remediation section closes with a line worth reading twice: “Do not rely on the model declining the request.”
The fix is in 1.75.0, and the release notes do not say so
Theia 1.75.0 reached npm on August 27, 2026 at 1:52 p.m. UTC, four days before the CVE record existed. It is the fixed version according to the CVE’s affected range, and it is the current release.
The 1.75.0 changelog does document the change. It documents it as a breaking API change: “[ai-ide] removed WorkspaceFunctionScope.ensureWithinWorkspace(targetUri, workspaceRootUri). Every path-taking AI tool now resolves and checks its argument through WorkspaceFunctionScope.resolveAccessiblePath(pathOrUri), which in addition to the workspace roots accepts locations covered by the ai-features.workspaceFunctions.allowedExternalPaths preference or contributed via the new AccessibleRootContribution.”
That entry is accurate and it is technically complete. It says nothing about security, a vulnerability, path traversal, or a workspace escape, and it names no CVE. A maintainer reading the 1.75.0 notes on August 27 to decide whether to upgrade would have read that paragraph as a refactor of a path-resolution API — one that broadened access, in fact, since the new resolver accepts allowlisted external paths the old one did not. Nothing in it says that the version they are running lets a prompt-injected agent write to ~/.bashrc.
The commit the CVE record cites as its reference points the same direction. It is 28da106c254, and its message is “ai-ide: add Memory prompt capability (#17865)” — a feature commit touching seventeen files, adding a workspace memory feature, with the containment change carried inside it.
Two conflicts in the record
The Eclipse advisory and the CVE record do not agree on what is affected. The GitLab report names version 1.73.x, noting it was verified against a local commit, and does not name a fixed version at all. The CVE record names 1.73.0 up to but not including 1.75.0. The difference is the entire 1.74 line, released July 31, 2026 and current for most of August. Anyone who read the Eclipse report and concluded that 1.74 was clear read it correctly and was wrong.
The two also disagree on severity language. Both carry the same 8.8 base score, but the Eclipse report labels that score “Critical.” On the CVSS v3.1 scale, 8.8 is High, which is what NVD’s record says. That gap matters only because a great many triage processes route on the word rather than the number.
Why it matters
The interesting thing here is not the path traversal. Unsanitized .. is the oldest bug in the catalog, and a fix that consists of calling the containment helper that was already sitting in the same file is not a research contribution. What is worth attention is where it was found, and what the surrounding design assumed.
Agent Mode in an IDE is a component whose whole purpose is to take untrusted text — a model’s output, itself shaped by whatever files, issues, dependencies, and documentation the model was fed — and turn it into filesystem writes. That is the feature. Every argument that reaches those tools is attacker-influenceable by construction, in the same way every value in an HTTP request is. The IDE is not being tricked into an unusual state; it is doing exactly its job on input it was never in a position to trust.
Which is why the Eclipse report’s closing line is the most useful sentence in the whole disclosure. “Do not rely on the model declining the request” is a statement about where the security boundary sits, and it points at the boundary that a lot of agent tooling currently gets wrong. Refusal is an alignment property of a model, not an access-control property of a system. It fails open, it is non-deterministic, and it is the thing an injection attack is specifically built to move. A containment check in resolveAccessiblePath fails closed and does not negotiate.
The second point is about disclosure practice, and it is a pattern this publication keeps running into from a different angle. Nothing here was hidden. The report is public on Eclipse’s GitLab, the changelog entry is present and honest, the commit is in the tree, and the CVE arrived four days after the fix, which by the standards of the last week is fast. The problem is that none of those artifacts, on the day they appeared, told a user that they were exposed. The changelog described a mechanism, not a risk. The commit described a feature. The CVE, which is the artifact that would have said “you are exposed,” arrived after the upgrade decision had already been made by anyone who was paying attention on August 27.
For conventional dependencies that lag is tolerable, because most shops upgrade on a schedule and the CVE catches the stragglers. For an AI agent with unconfirmed write access to a developer’s home directory, the population at risk is developer workstations and hosted browser IDEs, the exposure window is however long someone stays on 1.73 or 1.74, and the trigger is a poisoned README in a repository someone asked the agent to look at.
What to do
Upgrade Theia to 1.75.0 or later. Anything from 1.73.0 through the 1.74 line is affected per the CVE record, including 1.74 builds that the Eclipse report’s narrower version statement appears to clear.
The upgrade is a breaking change for anyone who built on the old API: WorkspaceFunctionScope.ensureWithinWorkspace(targetUri, workspaceRootUri) is gone, replaced by resolveAccessiblePath(pathOrUri). If you maintain custom AI tools on top of Theia, that is the call to audit — any handler of your own that resolves a model-supplied path without going through the new resolver has the same bug the five built-in handlers had.
Review the ai-features.workspaceFunctions.allowedExternalPaths preference after upgrading. The new resolver is an allowlist, and an over-broad entry there reopens the door deliberately.
For hosted or browser deployments, the report’s defense-in-depth list is worth applying regardless of version: run the agent backend as an unprivileged user, canonicalize paths so symlinks cannot escape, and require explicit confirmation for any write outside the workspace. On unpatched builds where an immediate upgrade is not possible, disabling Agent Mode’s file-change tools removes the exposure, since the vulnerable path is reachable only through them.
Sourcing note
Checked: NVD’s API record for CVE-2026-82217, including its publication timestamp, source identifier, CVSS vector, CWE, affected version range, and description; the Eclipse Foundation vulnerability report at work item 624 on gitlab.eclipse.org, which supplied the title, the payload example, the root-cause analysis, the reporter credit, the July 24, 2026 report date, and the remediation guidance quoted above; the Theia CHANGELOG at the v1.75.0 tag; the commit referenced by the CVE record; and npm registry metadata for @theia/core, which supplied the 1.75.0 release timestamp.
Not resolved: no exploitation has been reported by Eclipse, by the reporter, or by any vendor, and none is claimed here. NVD has not published an independent score, so the 8.8 is the Eclipse Foundation’s. The version-range difference between the Eclipse report and the CVE record is reproduced as found and has not been reconciled by either party; the CVE record’s wider range is the one used above, as it is the more conservative. The Eclipse report does not name a fixed version, so the identification of 1.75.0 as the fix rests on the CVE record’s affected range and the changelog entry, not on a statement from the project that 1.75.0 is a security release. Whether the containment change was deliberately bundled into the Memory feature commit or arrived alongside it is not established from the public record.