Trust Issues: Arbitrary File Write in Weblate CLI (CVE-2026-23535)

In the modern DevSecOps landscape, we are obsessed with Zero Trust networking, yet we constantly run CLI tools that treat upstream servers like old drinking buddies. We curl | bash, we npm install packages from strangers, and in this case, we run wlc download to fetch translation files, assuming the server will behave itself. It turns out, that assumption is a critical error.

Weblate is a fantastic tool for managing internationalization. It automates the tedious process of syncing translation strings. The Weblate CLI (wlc) is the glue that developers use to pull those strings into their local environments or CI/CD pipelines. It connects to the Weblate API, asks for the latest data, and saves it to disk.

But here is the catch: when wlc asks the server "What should I name this file?", the vulnerable versions didn't verify the answer. If a compromised or malicious Weblate server decides that the file should be named ../../../../../bin/malware, the CLI dutifully obliges. This isn't just a bug; it's a fundamental architectural failure in trusting external input.

The vulnerability (CVE-2026-23535) is a classic Path Traversal (CWE-22), but the context makes it interesting. Usually, we see path traversal on the server side (a client asking for /etc/passwd). This is the reverse: the client is the victim, and the server is the attacker.

When you run the download command, wlc queries the API for project components. The API returns a JSON object containing metadata, including a slug—a short, URL-friendly identifier for the project and component. The CLI intends to save the file as [output_dir]/[project_slug]-[component_slug].zip.

The logic flaw is simple: the code assumed that a "slug" would always be a benign alphanumeric string. It failed to anticipate that a malicious API response could contain special characters like /, \, or ... Because Python's pathlib (and filesystem APIs in general) resolves paths dynamically, injecting ../ into the filename causes the write operation to traverse up the directory tree, escaping the intended sandbox.

Let's look at the smoking gun in wlc/main.py. The code uses pathlib.Path to construct the file path. While pathlib is generally safer than string concatenation for cross-platform compatibility, it does not inherently block traversal attacks if you feed it garbage.

Here is the vulnerable logic from versions prior to 1.17.2:

# The naive approach
directory = Path(self.args.output)
# trusting component.slug and component.project.slug implicitly
file_path = directory.joinpath(f"{component.project.slug}-{component.slug}.zip")
 
directory.mkdir(exist_ok=True, parents=True)
file_path.write_bytes(content)

If self.args.output is /home/user/translations, and the server sends a project slug of ../../.ssh/ and a component slug of authorized_keys, the file_path resolves to /home/user/translations/../../.ssh/authorized_keys. The operating system normalizes this to /home/user/.ssh/authorized_keys, and write_bytes(content) overwrites your keys with whatever payload the server sent.

The fix, implemented in commit 216e691c6e50abae97fe2e4e4f21501bf49a585f, introduces a strict whitelist. They didn't just try to strip ../ (which is often bypassable); they nuked everything that isn't alphanumeric:

# The fix in wlc/utils.py
NON_SLUG_RE = re.compile(r"[^a-zA-Z0-9_]")
 
def sanitize_slug(slug: str) -> str:
    # Replace anything weird with a hyphen
    return NON_SLUG_RE.sub("-", slug)

Now, ../../ becomes ------, rendering the traversal impotent.

To exploit this, an attacker needs control over the Weblate server instance that the victim is connecting to. This could be a rogue server setup to trick users (social engineering) or a legitimate Weblate instance that has been compromised. The attacker modifies the API response for the project metadata.

Here is the attack chain:

1. Setup: Attacker configures the Weblate API to return specific JSON for the GET /api/components/ endpoint.
2. Payload: The attacker sets the slug to a traversal path.

{
  "results": [
    {
      "name": "Malicious Component",
      "slug": "authorized_keys",
      "project": {
        "name": "Pwned Project",
        "slug": "../../.ssh/"
      },
      "file_url": "http://evil-server/payload.zip" 
    }
  ]
}

3. Execution: The victim runs wlc download --output ./translations.
4. Detonation: The CLI parses the JSON, constructs the path ../../.ssh/authorized_keys, downloads the zip file (which is actually a raw public key, not a zip, or the attacker relies on the zip content extraction depending on the exact flow), and writes it.

[!WARNING] If the attacker targets .bashrc or .zshrc, they gain persistent Remote Code Execution (RCE) the next time the developer opens a terminal. This turns a file write vulnerability into a full system compromise.

The remediation is straightforward: strict input sanitization. The developers of Weblate CLI reacted correctly by implementing an allowlist approach rather than a blocklist. Blocklists (trying to filter ../) are notoriously difficult to get right due to URL encoding, unicode normalization, and OS-specific separators.

Immediate Steps for Users:

1. Upgrade: Update to wlc version 1.17.2 immediately. This version includes the regex sanitization that neuters the attack.

   pip install --upgrade wlc

2. Audit: If you suspect you've connected to a malicious server, check your home directory for unexpected files, particularly in hidden configuration folders (.ssh, .config, shell profiles).

Lessons for Developers: Never trust data coming from an API, even if it's your own API. When performing filesystem operations based on remote input, always treat the input as hostile. Use os.path.basename() or strict regex validation to ensure filenames do not contain directory separators.