Summary
Banks template media filters accept user-controlled file paths and pass them directly to open() without validation, allowing path traversal via sequences like ../.
When an attacker can influence template variables, they can read arbitrary files accessible to the Python process, with the contents exfiltrated as base64 inside rendered LLM prompts.
Banks template media filters accept user-controlled file paths and pass them directly to open() without validation, allowing path traversal via sequences like ../.
When an attacker can influence template variables, they can read arbitrary files accessible to the Python process, with the contents exfiltrated as base64 inside rendered LLM prompts.
Affected context
This vulnerability occurs in applications that use Banks to generate prompts where template variables for media filters (image, audio, video, document) can be influenced by end users or upstream systems.
The risk is elevated when the Python process has access to sensitive files (e.g., environment configuration, SSH keys, cloud credentials) and when rendered prompts are logged, stored, or sent to third-party LLM providers.
Systems that treat Banks templates as a bridge between untrusted input and backend filesystems are especially exposed, since no default path restriction or sanitization is applied.
This vulnerability occurs in applications that use Banks to generate prompts where template variables for media filters (image, audio, video, document) can be influenced by end users or upstream systems.
The risk is elevated when the Python process has access to sensitive files (e.g., environment configuration, SSH keys, cloud credentials) and when rendered prompts are logged, stored, or sent to third-party LLM providers.
Systems that treat Banks templates as a bridge between untrusted input and backend filesystems are especially exposed, since no default path restriction or sanitization is applied.
Exploit preconditions
- Attack surface: Template rendering paths that use Banks media filters (
image,audio,video,document). - Required access: Ability to control or influence template variables used as media filter arguments (direct user input, API parameters, or data from compromised upstream services).
- Trigger point: Rendering of a Banks Prompt that evaluates a media filter with the attacker-supplied file path.
- Why exploitation is possible: The implementation wraps untrusted input with
Path(value)and passes it straight intoopen(file_path, "rb")without normalization, directory whitelisting, or checks against traversal sequences, so the process reads any file reachable under its filesystem permissions.
- Attack surface: Template rendering paths that use Banks media filters (
image,audio,video,document). - Required access: Ability to control or influence template variables used as media filter arguments (direct user input, API parameters, or data from compromised upstream services).
- Trigger point: Rendering of a Banks Prompt that evaluates a media filter with the attacker-supplied file path.
- Why exploitation is possible: The implementation wraps untrusted input with
Path(value)and passes it straight intoopen(file_path, "rb")without normalization, directory whitelisting, or checks against traversal sequences, so the process reads any file reachable under its filesystem permissions.
Why this happens
The core issue is unvalidated use of filesystem paths derived from untrusted input, a classic CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').
Banks treats user-controlled values as safe file paths, converting them with Path(value) and using them in open() calls without:
- Normalizing the path and ensuring it stays within an allowed base directory
- Rejecting traversal sequences (
../) and absolute paths - Enforcing a strict mapping between logical resource identifiers and physical files
This design conflates logical template parameters with direct filesystem access, leading to arbitrary file reads whenever an attacker can influence those parameters.
The core issue is unvalidated use of filesystem paths derived from untrusted input, a classic CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').
Banks treats user-controlled values as safe file paths, converting them with Path(value) and using them in open() calls without:
- Normalizing the path and ensuring it stays within an allowed base directory
- Rejecting traversal sequences (
../) and absolute paths - Enforcing a strict mapping between logical resource identifiers and physical files
This design conflates logical template parameters with direct filesystem access, leading to arbitrary file reads whenever an attacker can influence those parameters.
Potential impact
- Reading
.envfiles that may contain database passwords, API keys, and other secrets - Exfiltrating private SSH keys and cloud provider credentials from the application host
- Accessing application source code, configuration files, and proprietary models or prompts
- Enumerating system users via
/etc/passwdand attempting to read password hashes from/etc/shadow(subject to OS permissions) - Pivoting to further compromise by using stolen secrets to access databases, code repositories, or cloud infrastructure
- Indirect leakage of sensitive data to LLM providers or log stores if rendered prompts are transmitted or stored externally
- Reading
.envfiles that may contain database passwords, API keys, and other secrets - Exfiltrating private SSH keys and cloud provider credentials from the application host
- Accessing application source code, configuration files, and proprietary models or prompts
- Enumerating system users via
/etc/passwdand attempting to read password hashes from/etc/shadow(subject to OS permissions) - Pivoting to further compromise by using stolen secrets to access databases, code repositories, or cloud infrastructure
- Indirect leakage of sensitive data to LLM providers or log stores if rendered prompts are transmitted or stored externally
General mitigation guidance
Effective mitigation involves strictly separating user input from raw filesystem paths and constraining all file access performed by template media filters.
Common defensive patterns include:
- Introducing an explicit whitelist of directories or storage backends from which media filters are allowed to read, rejecting any path that resolves outside those roots.
- Performing path normalization and canonicalization (e.g., resolving symlinks) before checks, and denying traversal or absolute paths that escape the configured base directory.
- Replacing direct path-based access with logical identifiers, where templates refer to media IDs, and server-side code resolves those IDs to safe, pre-approved resources.
- Applying least privilege to the runtime environment so that the process account cannot read highly sensitive files (secrets, SSH keys, system configuration) even if a path traversal bug exists.
- Minimizing the secret density on application hosts by using dedicated secret stores or short-lived credentials instead of long-lived keys on disk.
Effective mitigation involves strictly separating user input from raw filesystem paths and constraining all file access performed by template media filters.
Common defensive patterns include:
- Introducing an explicit whitelist of directories or storage backends from which media filters are allowed to read, rejecting any path that resolves outside those roots.
- Performing path normalization and canonicalization (e.g., resolving symlinks) before checks, and denying traversal or absolute paths that escape the configured base directory.
- Replacing direct path-based access with logical identifiers, where templates refer to media IDs, and server-side code resolves those IDs to safe, pre-approved resources.
- Applying least privilege to the runtime environment so that the process account cannot read highly sensitive files (secrets, SSH keys, system configuration) even if a path traversal bug exists.
- Minimizing the secret density on application hosts by using dedicated secret stores or short-lived credentials instead of long-lived keys on disk.
How teams detect issues like this
Several approaches can help detect and monitor this class of vulnerability:
- Static analysis: Search for uses of
open(),Path(), or similar file APIs where arguments are derived from template variables, request data, or other untrusted sources without normalization and directory checks. - Code review: Flag patterns where templating layers are allowed to accept raw file paths, especially if those paths are passed directly to filesystem I/O instead of a constrained resource lookup.
- Security testing: Implement automated tests and dynamic scanning that attempt
../and absolute path payloads in media-related template variables to verify that traversal is blocked. - Runtime monitoring: Enable logging for unexpected file access patterns (e.g., attempts to read
.env, private keys, or system files from template-rendering paths) and treat them as potential exploitation signals. - Policy enforcement: Integrate SAST tools or custom linters into CI pipelines to prevent new instances of unvalidated file path usage from being introduced.
Several approaches can help detect and monitor this class of vulnerability:
- Static analysis: Search for uses of
open(),Path(), or similar file APIs where arguments are derived from template variables, request data, or other untrusted sources without normalization and directory checks. - Code review: Flag patterns where templating layers are allowed to accept raw file paths, especially if those paths are passed directly to filesystem I/O instead of a constrained resource lookup.
- Security testing: Implement automated tests and dynamic scanning that attempt
../and absolute path payloads in media-related template variables to verify that traversal is blocked. - Runtime monitoring: Enable logging for unexpected file access patterns (e.g., attempts to read
.env, private keys, or system files from template-rendering paths) and treat them as potential exploitation signals. - Policy enforcement: Integrate SAST tools or custom linters into CI pipelines to prevent new instances of unvalidated file path usage from being introduced.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
