Banks DirectoryPromptRegistry CVE-2026-107716

Exploitation requires that an attacker can influence the contents of the DirectoryPromptRegistry directory - specifically the ability to place a symbolic link in the registry (as index.json or a *.jinja prompt file) or to control files extracted into that directory (e.g., an untrusted uploaded/extracted archive). This is NOT a default-configuration remote flaw: the attacker must have write/placement influence over the prompt directory, and the application must use the DirectoryPromptRegistry and expose that directory to untrusted input. Exploitation is further limited to pre-2.5.1 versions; file-overwrite paths additionally depend on platforms where the symlink-following behavior occurs (the fix uses O_NOFOLLOW where available and falls back to explicit is_symlink checks on platforms like Windows that lack it). The required local placement of a symlink is reflected in the AV:L and AT:P metrics.

This is a locally-exploitable symlink-based path traversal (CWE-22) in the Banks DirectoryPromptRegistry, carrying a vendor CVSS 4.0 base score of 7.3 (AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L). The signals are internally consistent and point to a moderate, conditional risk rather than a drop-everything priority. The attack vector is Local (AV:L), not network, so there is no remote mass-exploitation surface; the AT:P (attack requirements present) metric and the description's explicit caveat - 'requires attacker influence over the registry directory or its extracted contents' - both confirm that exploitation is gated behind a non-default precondition. Impact is genuine where the precondition holds: high confidentiality and integrity (arbitrary file disclosure via a symlink followed by _scan()/get(), and arbitrary file overwrite via set()/_save()/_load()), with low availability impact. No EPSS score, KEV listing, or public POC was provided in the input, so there is no evidence of active exploitation or weaponization. Note a nuance for consumers of this record: the vendor rated AV:L, yet in a hosted/multi-tenant LLM service where untrusted users can upload prompt archives that are extracted into a shared registry directory, the practical reachability can be closer to remote - verify against your own deployment model. Overall: a real, fixable bug worth patching promptly in affected deployments, but not a widespread internet-facing emergency.

In an application that lets untrusted users supply or influence the contents of a Banks prompt registry directory (for example by extracting a user-supplied archive into it), an attacker plants a symbolic link named like an index.json or *.jinja prompt file that points to a sensitive file outside the registry root. When the application calls DirectoryPromptRegistry._scan()/get(), the link is followed and the external file's contents are disclosed; via set()/_save()/_load() the attacker can instead overwrite the external link target. No public exploit code was identified in the provided data, but the fix commit and advisory describe the mechanism in detail.