### Impact wlc could send an unscoped API token to an unintended server when run inside a directory tree containing attacker-controlled project configuration. If `.weblate`, `.weblate.ini`, or `weblate.ini` defines an API url, and the user supplies a token with `WLC_KEY` or `--key` without also pinning the URL, wlc would send the token to the project-configured URL. Impacted users are those running wlc in untrusted repositories, pull request checkouts, or directories with untrusted ancestor configuration while using `WLC_KEY` or `--key`. ### Patches The issue is patched in wlc 2.0.1 via https://github.com/WeblateOrg/wlc/pull/1500. The fix rejects unscoped keys when the API URL comes from automatically discovered project configuration: - `WLC_KEY` now requires `WLC_URL`. - `--key` now requires `--url`. - URL-scoped keys in the `[keys]` configuration section remain supported. Users should upgrade to wlc 2.0.1 or newer. ### Workarounds Without upgrading, users can avoid the issue by explicitly pinning the API URL whenever using an unscoped key: `WLC_URL=https://hosted.weblate.org/api/ WLC_KEY=... wlc ...` or: `wlc --url https://hosted.weblate.org/api/ --key ... ...` Alternatively, use URL-scoped keys in the [keys] section instead of WLC_KEY or --key, and avoid running wlc with secrets in untrusted checkouts. - The issue was independently reported by [type5afe](https://hackerone.com/type5afe) and [visionx7](https://hackerone.com/visionx7) using HackerOne.
CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:C/C:L/I:N/A:N
Get alerted for CVEs like this
Register your stack and get notified within minutes when a matching CVE drops.
Start monitoring free