Kiota is an OpenAPI based HTTP Client code generator. Prior to 1.29.1 and 1.32.5, Kiota resolved OpenAPI $ref values by fetching remote http(s) URLs and reading local absolute or out-of-tree file paths, allowing `kiota generate` on an attacker-controlled or attacker-influenced description to perform build-time SSRF, remote file inclusion, and local file inclusion by inlining external schemas such as REMOTE_KIOTA_PROP or Leaked into generated clients. This issue is fixed in version 1.29.1 and 1.32.5 by AllowedExternalOriginsStreamLoader and the --allowed-external-origins option.
Kiota is an OpenAPI based HTTP Client code generator. Prior to 1.29.1 and 1.32.5, `kiota plugin add` and `kiota plugin generate` (with `-t APIPlugin`) emitted attacker-controlled static_template.file values from x-ai-adaptive-card and x-ai-capabilities into generated Microsoft 365 Copilot and Teams plugin manifests without path validation, allowing ../, absolute, rooted, UNC, Windows drive, or URI paths in response_semantics.static_template.file to cause path traversal or out-of-package file inclusion when the generated plugin was deployed. This issue is fixed in version 1.29.1 and 1.32.5.
Kiota is an OpenAPI based HTTP Client code generator. Prior to 1.29.1 and 1.32.5, `kiota info` read x-ms-kiota-info.languagesInformation.<language>.dependencyInstallCommand plus dependency name and version values from an OpenAPI description and presented the spec-supplied command as Kiota's recommended install command, allowing an attacker-controlled or compromised description to cause command injection when the suggested command was run manually or through the Kiota VS Code extension's kiota info --json dependency-install flow. This issue is fixed in version 1.29.1 and 1.32.5.
Cherry Studio versions 1.2.2 through 1.9.12, fixed in commit 1518530, contain a remote code execution vulnerability in SearchService that allows remote attackers to execute arbitrary code by delivering malicious JavaScript through controlled search provider content loaded into an Electron BrowserWindow configured with nodeIntegration enabled and contextIsolation disabled. Attackers who control a search engine provider, individual search result pages, or provider settings pages can execute JavaScript with full Node.js privileges, gaining access to fs, child_process, os, and process.env under the operating-system account of the Cherry Studio process.
FastGPT is a knowledge-based AI application platform. At commit 22ebfacbb43311e9b73294040ae0eb87390c6bba and earlier, artifacts built from untrusted pull request code in .github/workflows/preview-docs-build.yml and .github/workflows/preview-fastgpt-build.yml can be downloaded by privileged workflow_run jobs in .github/workflows/preview-docs-push.yml and .github/workflows/preview-fastgpt-push.yml, allowing attacker-controlled Docker images from the document/ tree or FastGPT build context to be pushed to GHCR and, for documentation previews, deployed with secrets.KUBE_CONFIG_CN.
NVIDIA TensorRT-LLM for Linux has a vulnerability (CVE-2026-24226) involving improper control of code generation due to inclusion of functionality from an untrusted control sphere. Exploitation could lead to code execution, data tampering, and information disclosure. The vulnerability has a medium severity with a CVSS score of 6.3. No patch or official remediation guidance is currently available.
Inclusion of functionality from untrusted control sphere in Visual Studio Code allows an unauthorized attacker to bypass a security feature over a network.
A vulnerability was found in usestrix strix up to 1.0.2. This affects an unknown function of the file system_prompt.jinja of the component PyPI Handler. Performing a manipulation results in inclusion of functionality from untrusted control sphere. The attack is possible to be carried out remotely. The complexity of an attack is rather high. The exploitability is reported as difficult. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.
LLaMA-Factory through 0.9.5 contains a remote code execution vulnerability that allows attackers with WebUI access to execute arbitrary Python code by supplying a malicious model path in the Chat or Training interfaces. The application passes user-supplied model path input unvalidated into AutoTokenizer.from_pretrained() and AutoModel.from_pretrained() with a hardcoded trust_remote_code=True parameter, causing the Hugging Face transformers library to fetch and execute arbitrary code from a remote or local model repository with the privileges of the server process.
Improper handling of untrusted remote references in Snowflake CLI versions prior to 3.19 allowed server-side request forgery. The SQL statement reader's !source/!load directives could reference remote URLs that were retrieved at runtime without sufficient restriction on the request destination. By supplying crafted SQL content processed through a vulnerable command path, an attacker could cause the victim's environment to issue unintended outbound requests to internal or otherwise non-public network locations, and could cause remote SQL content to be retrieved and executed in the context of the victim user's session. Successful exploitation requires the victim to process attacker-controlled content through a vulnerable command path and is limited by the privileges available to that session and environment. The fix is available in Snowflake CLI version 3.19, which adds an option to disable remote URL retrieval.
# Pi loads project-local extensions without approval
Pi before 0.79.0 loaded project-local configuration and resources from a repository's `.pi` directory without first asking the user to trust that repository. This included project-local extensions, which are executable TypeScript or JavaScript modules loaded into the Pi process.
An attacker who controls a repository could place Pi-specific project resources in that repository. If a user then started Pi from that working tree, the project-local extension code could run with the same privileges as the local Pi process without the user having a convenient way to make a trust decision.
## Info
The affected component is Pi's project resource loading path. Before 0.79.0, startup loaded project `.pi/settings.json`, auto-discovered `.pi` resources, project package-managed resources, and project instruction files as part of normal session initialization. Project-local extensions were included in the same extension set as user/global extensions and were initialized before there was a project trust boundary.
Extensions like pi itself are not sandboxed. They run in the Pi process and can register commands, tools, and event handlers. The vulnerable behavior was not a privilege escalation across an operating-system boundary, but it allowed repository-controlled Pi extension code to execute implicitly when a user ran Pi in that repository.
## Impact
Exploitation requires user interaction: the attacker must get a user to open or otherwise work in an attacker-controlled repository and start Pi there. The attacker does not need an account on the user's machine or prior privileges in Pi.
If exploited, project-local extension code runs with the same permissions as the user running Pi. It can access files, environment variables, credentials available to the process, the network, and local tools available to that user. In CVSS terms, this advisory rates the impact as limited confidentiality and integrity impact without a distinct availability impact because exploitation requires local user action in an untrusted repository and does not cross a privilege boundary.
This risk is most relevant for users who run Pi in repositories they have not reviewed or do not trust. Pi's security guidance requires users to trust the codebases they work with, or to use an external sandbox or isolation boundary for untrusted repositories.
## Affected versions
- Affected: `< 0.79.0`
- Patched: `0.79.0`
## The solution
Pi 0.79.0 added project trust gating for project-local inputs. On interactive startup, Pi now asks before loading project-local settings, instructions, resources, package-managed resources, or extensions when a trust decision has not already been saved for the working directory.
Non-interactive modes do not prompt. Without a saved trust decision, they ignore project-local inputs unless `--approve` or `-a` is passed. Users can also pass `--no-approve` or `-na` to ignore project-local inputs for a single run even when a project is already trusted.
Before trust is resolved, Pi loads only user/global extensions and extensions passed explicitly on the command line. Those extensions can participate in the `project_trust` event; project-local extensions are not loaded until after the project is trusted.
## Recommendations
Upgrade `@earendil-works/pi-coding-agent` to version 0.79.0 or later.
After upgrading, review project trust prompts carefully and only trust repositories whose Pi-specific configuration and extensions you are willing to run. The upgrade makes this trust decision explicit, but it does not change Pi's security model: users should work only in trusted repositories, or use external isolation for untrusted code. Use `--no-approve` for one-off runs where project-local inputs should be ignored. For untrusted repositories or unattended automation, follow Pi's [security guidance](https://pi.dev/docs/latest/security) and run Pi inside an operating-system sandbox, container, VM, or other isolation boundary with only the files and credentials required for the task.
## Workarounds
Before and after this change, Pi users should only run Pi in repositories they trust, or in an external sandbox or isolation boundary when working with untrusted code. Pi 0.79.0 adds an explicit trust prompt as a defense-in-depth and user-safety improvement; it is not a sandbox and it does not make untrusted repositories safe.
If upgrading is not possible and your workflow already enforces this trust boundary, continue to avoid running Pi directly in untrusted repositories. Inspect and remove project-local Pi configuration and resources before use, especially project-local extensions and package configuration. Disabling extensions and other project resources with command-line flags can reduce exposure, but trusted or isolated execution remains the primary mitigation.
## Timeline
- 2026-05-25: Report received.
- 2026-06-05: Project trust gating committed.
- 2026-06-08: Project trust refi
Eclipse Theia versions prior to 1.69.0 allow execution of custom task definitions from workspace files without requiring workspace trust. This vulnerability enables an attacker to craft a malicious repository that, when opened in Theia, executes arbitrary commands with the user's privileges. The issue can be exacerbated by AI chat features combined with workspace settings that disable tool confirmation, potentially triggering automatic execution. The vulnerability is identified as CWE-829 and has a high severity with a CVSS score of 8.4.
In Eclipse Theia versions prior to 1.71.0, the AI chat rendered Markdown image tags from AI responses, triggering HTTP requests to arbitrary external URLs without restriction. Combined with prompt injection in a malicious workspace, an attacker could induce the AI agent to construct image URLs encoding sensitive information from the workspace or conversation context, exfiltrating it to attacker-controlled servers. The workspace trust enforcement introduced in v1.71.0 mitigates the documented attack chain by disabling AI features in untrusted workspaces.
Eclipse Theia versions prior to 1.71.0 automatically load files matching the pattern .prompts/*.prompttemplate from a workspace, which can override or extend AI agent system prompts. This behavior allows an attacker to craft a malicious repository that replaces the AI's system instructions with attacker-controlled content, leading to indirect prompt injection. Exploitation combined with other AI chat features in untrusted workspaces can result in data exfiltration via Markdown image rendering or arbitrary command execution via task definitions. The vulnerability has a high severity with a CVSS score of 8.4.
Eclipse Theia versions prior to 1.71.0 contain a vulnerability where the AI chat agent improperly neutralizes input used for prompting. Specifically, workspace file and directory names are processed as part of the prompt context without differentiation from system instructions. This flaw allows attackers to craft malicious repositories with adversarial file or directory names that can manipulate the AI agent's behavior, potentially leading to data exfiltration or arbitrary command execution.
Dell PowerFlex Manager, version(s) prior to 5.1.0.1, contain(s) an Inclusion of Functionality from Untrusted Control Sphere vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Information disclosure.
Yeoman Environment provides an API to discover, create, and run generators, and to configure where and how a generator is resolved. Versions 2.9.0 through 6.0.0 install missing local generator packages from caller-supplied package names without user confirmation. In downstream consumers that pass attacker-controlled project configuration into this path, this can result in arbitrary package installation and code execution during CLI bootstrap. The vulnerable method is installLocalGenerators(), which calls repository.install() directly without prompting the user. This issue has been fixed in version 6.0.0.
When the application executes the JavaScript script embedded in the PDF within the sandbox, it fails to intercept some dangerous interfaces, which allows remote scripts to be loaded, resulting in arbitrary code execution.
In Duck Site before version 1.0.1, the repository has a deploy workflow that runs after the build workflow completes. The build workflow runs on pull requests, while the deploy workflow runs with package-write permissions and deployment secrets. If an attacker can make a pull request build satisfy the deploy workflow’s main branch condition, the deploy job checks out the triggering workflow commit, builds it into a Docker image, pushes it as latest, and triggers Dokploy deployment. This can allow attacker-controlled pull request code to become the deployed production site image without being merged. This issue has been patched in version 1.0.1.
Quest Bot is an opensource modern Discord Bot built for moderation, utilities and support. Prior to version 1.0.3, the repository has a privileged deploy workflow that runs after the unprivileged build workflow completes. The build workflow runs on pull requests, and the deploy workflow checks out the triggering workflow’s head_sha, builds that code into a Docker image, pushes it as latest, and triggers production deployment. If an attacker can open a pull request from a branch named main, the deploy workflow condition can treat the PR build as deployable and build the attacker-controlled commit in a privileged deployment context. This can result in malicious container deployment and production bot compromise. This issue has been patched in version 1.0.3.