CVE-2026-19884 in Theia
Summary
by MITRE • 08/14/2026
In Eclipse Theia versions up to and including 1.69.0, opening a folder starts source control integration without requiring the user to trust the folder first. This affects applications built on Theia that include the git integration, such as the Theia IDE. Both Theia's own `@theia/git` extension and the builtin VS Code `git` extension run git commands such as `git status` as soon as a repository is detected. Since git honors repository-local configuration, a folder containing an attacker-controlled `.git/config` with `core.fsmonitor` (or a comparable hook-like setting) causes the configured command to be executed. The configuration can be delivered by burying a bare repository inside a regular repository (OVE-20210718-0001), so cloning an attacker-supplied repository and opening it in a Theia-based application is sufficient to execute arbitrary commands with the privileges of the user, without any confirmation prompt.
As of 1.70.0, plugins that declare `capabilities.untrustedWorkspaces.supported: false`, which includes the builtin git extension, are no longer loaded or activated in an untrusted workspace, and the deprecated `@theia/git` extension has been removed, so no git command is executed against an untrusted folder.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/14/2026
The vulnerability described in this CVE affects Eclipse Theia versions up to 1.69.0 where source control integration is automatically initiated upon folder opening without requiring user trust confirmation. This represents a critical security flaw that enables arbitrary code execution through malicious git configuration files. The issue stems from the automatic activation of git commands such as `git status` when a repository is detected, regardless of workspace trust status. When an attacker places a malicious `.git/config` file containing `core.fsmonitor` or similar hook-like settings within a repository, these commands execute with the privileges of the user running the Theia application, creating a significant attack surface.
This vulnerability operates through a specific exploitation technique involving repository manipulation where attackers can embed a bare repository within a regular repository to deliver malicious configuration files. The flaw is particularly dangerous because it requires no user interaction or confirmation prompts, making it a prime example of an automated privilege escalation vector. The technical implementation leverages git's native configuration handling mechanism, which processes repository-local settings without proper sandboxing or validation against workspace trust levels. This behavior aligns with CWE-434 Unrestricted Upload of File with Dangerous Type and follows ATT&CK technique T1059 Command and Scripting Interpreter for executing arbitrary commands.
The operational impact of this vulnerability extends beyond simple code execution to encompass full system compromise potential, as attackers can leverage the privileges of the running user to perform malicious actions. The vulnerability affects both Theia's native `@theia/git` extension and VS Code's built-in git extension, creating widespread exposure across applications built on Theia. The flaw represents a fundamental breakdown in workspace trust boundaries, where repository-local configuration settings are honored without proper verification of the workspace's trust status.
The remediation implemented in version 1.70.0 addresses this vulnerability by introducing stricter workspace trust controls that prevent plugins declaring `capabilities.untrustedWorkspaces.supported: false` from loading or activating in untrusted workspaces. This change specifically affects the builtin git extension and removes the deprecated `@theia/git` extension, ensuring that no git commands execute against potentially malicious folders. The solution follows security best practices by implementing proper workspace isolation mechanisms and aligns with ATT&CK technique T1566 Impair Defenses to prevent unauthorized command execution in compromised environments. This mitigation approach effectively closes the attack vector by establishing clear boundaries between trusted and untrusted workspaces, preventing automatic execution of potentially malicious git configuration settings while maintaining functionality for legitimate use cases in trusted environments.