Skip to content

CWE-22 Path Traversal in load_preset() — .yaml file read without authentication

Moderate
oobabooga published GHSA-w3cv-4447-5hf5 Apr 3, 2026

Package

pip text-generation-webui (pip)

Affected versions

< 4.3

Patched versions

4.3

Description

Summary

An unauthenticated path traversal vulnerability in load_preset() allows reading any .yaml file on the server filesystem.
The parsed YAML key-value pairs (including passwords, API keys, connection strings) are returned in the API response.

Details

The vulnerable code is in modules/presets.py at lines 69-75:

def load_preset(name, verbose=False):
    generate_params = default_preset()
    if name not in ['None', None, '']:
        path = shared.user_data_dir / 'presets' / f'{name}.yaml'
        if path.exists():
            with open(path, 'r') as infile:
                preset = yaml.safe_load(infile)

The name parameter comes from a Gradio Dropdown.
Gradio does not server-side validate dropdown values, so an attacker can POST name="../../secret/db_config" via the API.
The path resolves to presets/../../secret/db_config.yaml, escaping the intended directory.
No os.path.basename() or sanitize_filename() is applied.
The .yaml extension is always appended, limiting reads to YAML files.

PoC

  1. Clone the repository and start the server.
  2. Send a crafted API request with a traversal payload as the preset name.
  3. The server opens and parses the target .yaml file, returning all key-value pairs in the Gradio response.

I verified this by cloning the repository, running the verbatim load_preset() function with name="../secret/db_config", and confirming that YAML key-value pairs (host, password, port) from outside the presets directory are returned.

poc.zip

Impact

Any .yaml file readable by the server process can be exfiltrated.
YAML is a common format for sensitive configuration: Kubernetes manifests, Docker Compose files, CI/CD configs, application settings with database credentials.
No authentication required by default.

Remediation: apply os.path.basename(name) before path construction.

We believe this qualifies as a valid security issue.
If you agree, we'd appreciate the following credit on the CVE:
Reported by Woohyun Choi, Sunwoo Lee, and Seunghyun Yoon (Korea Institute of Energy Technology, KENTECH)

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

CVE ID

CVE-2026-35484

Weaknesses

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. Learn more on MITRE.

Credits