Update dependency @earendil-works/pi-coding-agent to ^0.79.0 [SECURITY] #3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "renovate/npm-earendil-works-pi-coding-agent-vulnerability"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
^0.75.5→^0.79.0Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass
CVE-2026-54326 / GHSA-7v5m-pr3q-6453
More information
Details
Potential XSS in HTML session exports via Markdown URL handling
Pi HTML exports render session Markdown into a static HTML file. Affected versions did not consistently reject unsafe Markdown link and image URL schemes. In versions with scheme filtering, C0 control characters in the URL scheme could bypass the check because browsers normalize those characters before navigation.
Impact
The realistic attack path is indirect. An attacker would need to get suitable Markdown into a session, for example through prompt injection that causes the model to include an unsafe link, or through other untrusted session content. The user would then need to export the session as HTML, open or share that file, and click the link.
If triggered, script runs in the exported document, not in pi or the user's shell. The main risk is limited disclosure of data embedded in that exported session file.
Affected versions
@mariozechner/pi-coding-agent >= 0.27.5, <= 0.73.1@earendil-works/pi-coding-agent >= 0.74.0, < 0.78.1@earendil-works/pi-coding-agent 0.78.1The old
@mariozechner/pi-coding-agentpackage scope has no patched release. It was renamed to@earendil-works/pi-coding-agent; users of the old scope should migrate to the new package and upgrade to version 0.78.1 or later.Resolution
Version 0.78.1 sanitizes Markdown link and image URLs with an allow-list after stripping C0 control characters.
Recommendations
Upgrade
@earendil-works/pi-coding-agentto version 0.78.1 or later. Regenerate shared HTML exports after upgrading if the underlying sessions contained untrusted content.Timeline
Credits
Reported by Paul Urian and Cosmin Alexa of CrowdStrike.
Severity
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts
CVE-2026-54328 / GHSA-jfgx-wxx8-mp94
More information
Details
Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts
Pi versions with temporary npm or git extension package installs used predictable paths under the operating system temporary directory. On Linux-based multi-user systems, a local attacker who can write to the shared temporary directory could prepare the expected package location before another user runs pi with a temporary extension package source. Pi could then load attacker-controlled extension code in the victim user's process.
Info
The vulnerable code path affected temporary extension package sources loaded with
--extensionor-e, specifically npm and git package sources. The temporary npm install root and temporary git clone paths were deterministic and rooted underos.tmpdir()/pi-extensions. The path was derived from public source information rather than from a per-user private directory or an unpredictable temporary directory.During resource resolution, pi considered an npm package or git checkout present if the expected package path already existed. Extension resources discovered from that package location were then loaded by the extension loader. Because extensions execute with the same privileges as the invoking pi process, pre-created temporary package contents could execute as the victim user.
The issue primarily affects Linux-based multi-user hosts where the operating system temporary directory is shared across user accounts, such as shared development machines, CI runners, HPC login nodes, and similar environments. On Windows and macOS, the default temporary directory is typically user-scoped, so default configurations are not expected to be affected unless the temporary directory is overridden to a shared writable location.
Impact
A local attacker with access to the same host can exploit this only if a victim runs a vulnerable pi version with a temporary npm or git extension package source that maps to the attacker-prepared location. No network attack path is involved and no race must be won, but victim interaction is required.
Successful exploitation can allow arbitrary extension code execution as the victim user. This can expose or modify files accessible to that user and can also cause denial of service or data loss through malicious package contents or unsafe temporary cache entries.
Affected versions
@earendil-works/pi-coding-agent: affected>= 0.74.0, < 0.78.1; patched>= 0.78.1@mariozechner/pi-coding-agent: affected>= 0.50.0, <= 0.73.1; no patched version was released under the old package name. Migrate to@earendil-works/pi-coding-agent >= 0.78.1.The solution
Version 0.78.1 moves temporary extension package installs to a private per-user directory under
~/.pi/agent/tmp/extensionsand enforces0700permissions on that directory. The same release also hardens git package source path handling so managed clone paths remain inside their intended install roots.Recommendations
Upgrade to
@earendil-works/pi-coding-agentversion 0.78.1 or later. Users of the deprecated@mariozechner/pi-coding-agentpackage should migrate to the@earendil-works/pi-coding-agentpackage and upgrade to a fixed version.On shared Linux hosts, avoid using temporary npm or git extension package sources with vulnerable versions. Review any third-party extensions before loading them, because pi extensions run with full access to the invoking user's account.
Workarounds
If upgrading immediately is not possible, avoid
--extensionor-ewith npm or git package sources on shared Linux systems. As an additional mitigation for vulnerable versions, configure the process temporary directory environment to point at a directory owned by the invoking user with0700permissions before starting pi.Timeline
Credits
Reported by Paul Urian and Cosmin Alexa of CrowdStrike.
Severity
CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:HReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Pi Agent: Race condition in Pi auth.json writes could expose stored credentials
CVE-2026-54327 / GHSA-r95r-rj6r-c39x
More information
Details
Pi auth.json writes could briefly expose stored credentials to local users
Pi stored API keys and OAuth credentials in
auth.json. A race condition in the file write path could briefly create or rewrite this file with permissions derived from the process umask before tightening the file to owner-only permissions.Info
The affected credential storage code wrote
auth.jsonand then corrected the file mode in a separate operation. During the interval between those operations, a local user who could read and traverse the Pi agent configuration directory could potentially read the file before its permissions were restricted.The file can contain API keys, OAuth access tokens, and OAuth refresh tokens for configured providers. The affected behavior was present in the original
auth.jsoncredential storage implementation and thus affects both the original@mariozechner/pi-coding-agentpackage as well as@earendil-works/pi-coding-agent.Impact
Exploitation requires local access to the same machine and read/traverse access to the victim's Pi agent configuration directory. Users whose
~/.pi/agentdirectory is private to their account are less exposed. The main impact is disclosure of stored provider credentials, which may allow use of the configured provider accounts according to the privileges of those credentials.This is not remotely exploitable by itself.
Affected versions
@mariozechner/pi-coding-agent >= 0.28.0, <= 0.73.1@earendil-works/pi-coding-agent >= 0.74.0, < 0.78.1@earendil-works/pi-coding-agent >= 0.78.1The solution
Version 0.78.1 changed the credential storage writes to create
auth.jsonwith mode0600at open time. The fix applies to initial file creation and credential save paths, including OAuth token refresh writes.Recommendations
Upgrade to
@earendil-works/pi-coding-agentversion 0.78.1 or later. Users still on the deprecated@mariozechner/pi-coding-agentpackage should migrate to the@earendil-works/pi-coding-agentpackage and install version 0.78.1 or later.After upgrading, rotate any credentials that may have been exposed on multi-user systems where the Pi agent configuration directory was readable by other local users.
Workarounds
If upgrading immediately is not possible, restrict the Pi agent configuration directory so only the owning user can traverse it, restrict
auth.jsonto owner-only permissions, and run Pi with a restrictive umask such as077until the upgrade is complete.Timeline
Credits
Reported by Paul Urian and Cosmin Alexa of CrowdStrike.
Severity
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Pi Agent: Pi loads project-local extensions without approval
CVE-2026-54325 / GHSA-mqxh-6gq7-558m
More information
Details
Pi loads project-local extensions without approval
Pi before 0.79.0 loaded project-local configuration and resources from a repository's
.pidirectory 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.piresources, 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
< 0.79.00.79.0The 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
--approveor-ais passed. Users can also pass--no-approveor-nato 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_trustevent; project-local extensions are not loaded until after the project is trusted.Recommendations
Upgrade
@earendil-works/pi-coding-agentto 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-approvefor 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
Credits
Reported by @qerogram, @urianpaul94, @EQSTLab, and @kamalmarhubi.
Severity
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Configuration
📅 Schedule: (in timezone UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate CLI.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.