SURIQ
A booby-trapped code repository can run an attacker's commands the moment you open it in a code editor built on Eclipse Theia, with no trust prompt standing in the way. The Eclipse Foundation published CVE-2026-19884 today, rating it 8.4 out of 10. The flaw was quietly fixed months ago in Theia 1.70.0, but the public record only landed now, and that gap is the story for anyone running a tool built on Theia.
Eclipse Theia is not an app most people install by name. It is a framework for building code editors, and it sits underneath products a lot of engineers do run: the Arduino IDE 2.x, Texas Instruments Code Composer Studio, and a range of browser-based cloud editors. If you use one of those, you are running Theia whether you think of it that way or not.
Why opening a folder was enough
When a Theia-based editor opens a folder, it starts its source control features straight away, before asking the user to trust the folder. To fill the source control panel, the git integration fires off ordinary read commands like git status the instant it detects a repository.
Git reads configuration from inside the repository it is working on. That is normal behavior, and it is also the problem here. A repository can carry its own .git/config, and a handful of git settings hold a command that git will execute. Point one of those settings, such as core.fsmonitor, at an attacker's command, and the editor's routine startup runs it. According to the Eclipse advisory, the payload can be smuggled in by nesting a bare repository inside an ordinary one, a delivery trick catalogued years ago as OVE-20210718-0001. Cloning the repository and opening it is enough, and the command runs with the signed-in user's privileges. A proof-of-concept is public, and the researcher credited with the report is Sudhanshu. There are no reports of exploitation in the wild.
Every Theia release through 1.69.0 carries the flaw. Version 1.70.0 is the first fixed build.
| Editor or tool | What runs the code on open | Status |
|---|---|---|
| Eclipse Theia (CVE-2026-19884) | Git integration runs on folder open; a crafted repository config points a git setting at a command | Fixed in Theia 1.70.0 |
| Cursor on Windows (CVE-2026-63093) | A fake git.exe planted in the repository root runs at startup | No fix at disclosure |
| AI coding agents | The agent runs a repository's own tooling before the user clicks trust | Vendor-specific fixes |
We have watched this same trap surface in editor after editor. A malicious repository ran code on open in Cursor on Windows through a planted git.exe, an AI coding agent handed out a shell from a repository that held no malicious code of its own, and simply opening a folder in an editor kicked off npm install logic. The common thread is that the editor touches a repository's git machinery before the human has decided the repository is safe. Theia is the newest name on that list, not a new class of bug. The toolchain itself keeps turning out to be the attack surface.
The real exposure is the tools built on Theia
Because Theia is a framework, the vulnerable behavior ships inside whatever bundles it, and each of those products pins its own Theia version. The Theia project fixing this in 1.70.0 does not mean the editor on your disk is fixed. A downstream tool that bundles Theia 1.67 stays vulnerable until its own maintainers bump the dependency and cut a release, and they may not have known to, because until today there was no CVE to track. That is the sharp end of a fix-before-CVE gap: the people who most needed a number to prioritize the upgrade did not have one for four months.
So the question is not only whether you updated Theia. It is whether the Theia-based tool you actually use ships a build with 1.70.0 or later inside it. For Arduino IDE, Code Composer Studio, or a hosted cloud editor, that answer comes from the vendor's release notes, not from Theia's.
How to tell if a repo is trying this
The behavior leaves a clean signal: a git process spawning a child it has no reason to spawn, right after a folder opens. On any developer host you collect logs from, watch process-creation events for git launching an interpreter or shell, such as sh, bash, cmd, or powershell, in the seconds after an editor loads a project. That parent-child pair is unusual enough to alert on.
The second angle is the file itself. In an untrusted clone, a repository-local .git/config that assigns a command to a setting like core.fsmonitor, core.hooksPath, core.sshCommand, or core.pager is the artifact. File integrity monitoring on cloned project directories can flag those values before anyone opens the folder.
If Suriq monitors the host, the process-creation and file-integrity telemetry it already collects is where this pattern shows up, so catching it is a detection rule to write, not a new sensor to deploy. Response stays yours to approve.
What to do now
- Update Theia to 1.70.0 or later. The fix stops plugins that declare they do not support untrusted workspaces, including the built-in git extension, from loading in an untrusted folder, and it removes the deprecated
@theia/gitextension. - Check the tool, not just the framework. If you use Arduino IDE 2.x, TI Code Composer Studio, or a cloud editor built on Theia, confirm from the vendor's release notes that your build bundles Theia 1.70.0 or newer. Older bundles stay exposed.
- Open untrusted repositories in a sandbox. Clone and inspect unfamiliar code inside a disposable virtual machine or container, not on your daily workstation.
- Inspect the repository config before you open. Treat a repository-local
.git/configthat sets a command-valued key as hostile until you have proven otherwise.
Being second to a story is fine. Being the tool that shipped a four-month-old vulnerable Theia because nobody told you there was a CVE is not. Check your build.