Banks prompt library flaw lets attackers run code via fake tools

A security advisory published on 5 November 2026 describes a remote code execution flaw in Banks, the Python prompt-templating package distributed on PyPI as banks. The advisory, tracked as GHSA-64vx-6h2c-rjh7 and CVE-2026-61536, says versions up to and including 2.4.2 resolve attacker-controlled tool definitions into arbitrary Python functions, giving an attacker code execution inside the process that hosts Banks.

According to the advisory, Banks reads {% completion %} blocks in a prompt template and parses each line of the rendered body. Lines that validate as a Tool JSON object are treated as tool definitions. Each Tool carries an import_path field, which Banks later feeds to importlib.import_module followed by getattr to obtain the callable that handles a tool call. The advisory states there is no allowlist and no sanitisation on that field, so any importable Python attribute can be selected, giving examples such as os.system and subprocess.getoutput.

The execution happens when the language model replies with a tool_calls entry whose function name matches the attacker-supplied tool. Banks then decodes the arguments from the model's reply with json.loads and calls the resolved function with those keyword arguments. In the worked example in the advisory, a template instructs the model to call a tool named rce with the command id > /tmp/pwn, while a second line in the same block maps that tool name to os.system. The advisory says modern instruction-tuned models reliably emit the matching tool call.

The researcher also published a local proof of concept that reaches the vulnerable function directly, bypassing the need for a real model during testing. The advisory says the output shown was produced against banks==2.4.2 installed from PyPI, and shows the resolved callable being invoked and returning the output of the id command.

The advisory is explicit that this is a separate issue from GHSA-gphh-9q3h-jgpp, also known as CVE-2026-44209. That earlier problem was fixed in version 2.4.2 by switching src/banks/env.py from Jinja's standard Environment to SandboxedEnvironment. According to the advisory, that change does not touch src/banks/extensions/completion.py, where the unsafe import chain lives, and the malicious tool definition is plain text in the rendered body rather than a Jinja attribute access, so the sandbox does not apply.

The stated root cause is that Banks treats import_path as trusted developer data. When a developer registers a tool from a Python function, the field is built from the function's own module and qualified name. But when Banks parses tool definitions out of a rendered template, the same field carries the same trust level, with no distinction between the two origins. The Tool type in src/banks/types.py has no validator on the field.

The advisory sets two conditions for exploitation. The application must load a prompt from a source an attacker can influence, such as a Redis prompt registry with shared write access, a file or directory registry on shared storage, or a network-fetched prompt string. The application must also run that prompt's completion block against a model that may emit tool calls. Code execution then inherits the privileges of the Banks process, which the advisory describes as typically the inference or agent server.

The suggested fix is to treat import_path as untrusted and resolve tool callables only against an explicit allowlist registered by the application at startup. The advisory includes a short patch that raises an error when a requested tool name is not in that registry. The record lists the issue as reported.