EUVD-2026-38579
GHSA-mqxh-6gq7-558m
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAttacker plants malicious .pi extension in repository
-
DeliveryVictim clones or checks out attacker-controlled repository
-
ExploitVictim starts Pi in the repository working directory
-
ExecutionPi startup auto-loads project extension without trust prompt
-
PersistExtension executes unsandboxed with victim's user privileges
-
ImpactAttacker code accesses files, env vars, credentials, and network
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V15 - Secure Coding and Architecture Trusted source inclusion only
|
| Exploitation Conditions | Exploitation requires that the victim have Pi < 0.79.0 installed and run it interactively from within a working tree that contains an attacker-controlled .pi directory with a project-local extension (TypeScript or JavaScript module). The attacker must control or influence repository content (e.g., via a pull request, a published open-source repo, or a social engineering scenario) and must socially engineer the victim into cloning the repository and starting Pi there - no remote network access to the victim's machine is required. There is no requirement for the victim to have any special Pi configuration; the vulnerable behavior is the default startup behavior of all Pi < 0.79.0 installations. Exploitation is limited to the victim user's local account privileges - it does not cross an OS privilege boundary. Non-interactive Pi runs (headless/automation modes) without a saved trust decision and without |
| Impact | The NVD-assigned CVSS 3.1 base score is 4.4 (Medium) with vector AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N. The Local attack vector accurately reflects that exploitation requires the victim to clone or otherwise possess the malicious repository locally and then start Pi there - this is not a remotely triggerable network service vulnerability. No privileges are required on the attacker side beyond controlling repository content (PR:N), but User Interaction is mandatory (UI:R), which meaningfully constrains automated exploitation. No EPSS score was provided in the input data, and this CVE is not listed in CISA KEV, so real-world exploitation rates are unknown. No public exploit or POC was identified at time of analysis. Despite the modest CVSS score, the real-world risk to the affected population - developers who routinely clone and immediately run tooling in unfamiliar repositories - is material: the impact ceiling is credential theft, secret exfiltration, and arbitrary file access scoped to the developer's user account. The risk profile is analogous to the VSCode workspace trust issue (CVE-2021-43891) and supply-chain extension abuse patterns. Organizations whose developers use Pi with untrusted third-party repositories or open-source contribution workflows should treat this as a higher-priority upgrade than the numeric score alone suggests. |
| Exploit ScenarioDerived | An attacker publishes or contributes to an open-source repository that contains a .pi directory with a malicious JavaScript extension module - for example, one that reads ~/.ssh/id_rsa, .env files, or shell history and exfiltrates them over the network. A developer who clones that repository and runs Pi to assist with a code review or contribution task silently executes the malicious extension at startup with no warning or prompt, because Pi < 0.79.0 treats project-local extensions identically to user-trusted global extensions. No public proof-of-concept has been identified, but the attack requires only knowledge of Pi's extension API, which is documented. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 17, 2026
Implicit execution of untrusted repository-controlled TypeScript/JavaScript extensions in Pi coding agent (npm package @earendil-works/pi-coding-agent) before 0.79.0 allows an attacker who controls a repository to execute arbitrary code with the victim user's full process privileges. Pi's startup path auto-loaded project-local extensions from a repository's .pi directory - including executable TypeScript/JavaScript modules - without any trust gate or user prompt, meaning a developer who cloned and ran Pi in a malicious repository would silently execute attacker-supplied extension code. No public exploit has been identified at time of analysis and this CVE is not listed in CISA KEV, but the attack class (supply-chain / repository-as-malware-delivery) is highly relevant to developer tooling security.
RemediationAI
Upgrade @earendil-works/pi-coding-agent to version 0.79.0 or later (vendor-released patch: 0.79.0), available via npm: npm install @earendil-works/pi-coding-agent@0.79.0. After upgrading, carefully review project trust prompts at Pi startup and only grant trust to repositories whose .pi configuration and extensions you are willing to execute. Use --no-approve or -na for one-off runs in partially trusted repositories where project-local inputs should be ignored for that session; use --approve or -a only in non-interactive automation where the repository is already verified. If upgrading is not immediately possible, manually inspect and remove .pi directories (especially extensions and package configuration) from any repository before running Pi, and avoid running Pi in repositories you have not reviewed. The vendor advisory at https://github.com/earendil-works/pi/security/advisories/GHSA-mqxh-6gq7-558m recommends running Pi inside an OS sandbox, container, or VM with minimal file and credential access when working with untrusted repositories - this remains the recommended posture even after upgrading, as 0.79.0 adds a trust prompt but does not provide a sandbox.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in npm, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Pi is an AI-assisted coding agent distributed as the npm package @earendil-works/pi-coding-agent (CPE: pkg:npm/@earendil-works_pi-coding-agent). The product supports a project-local extension model where TypeScript or JavaScript modules placed in a repository's .pi directory are auto-discovered and loaded into the live Pi process at startup. These extensions are fully unsandboxed and can register commands, tools, and event handlers with unrestricted access to the host process environment. The root cause is CWE-829 (Inclusion of Functionality from Untrusted Control Sphere): before 0.79.0, the startup path unconditionally initialized project-local extensions - alongside user/global extensions - before any project trust boundary was evaluated. The vulnerable components are the project resource loading path (src/main.ts, src/modes/interactive/interactive-mode.ts) and the trust-manager module (src/core/trust-manager.ts), which lacked the hasProjectConfigDir check and trust-gating logic introduced in the fix commits.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Local vector because exploitation requires working in a local checkout; UI:R because user must actively start Pi; C:L/I:L because extension code has process-level file and credential access but does not cross privilege boundary.
Primary rating from Vendor (https://github.com/earendil-works/pi).
CVSS VectorVendor: https://github.com/earendil-works/pi
DescriptionCVE.org
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 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 refinements and security model documentation completed.
- 2026-06-08: Fixed version 0.79.0 released.
- 2026-06-08: Advisory published.
Credits
Reported by @qerogram, @urianpaul94, @EQSTLab, and @kamalmarhubi.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
Exploit-DB