GHSA-3mqq-hv9c-85hc: Infoleak
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 WLCKEY 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 WLCKEY 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:
- WLCKEY now requires WLCURL. - --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:
WLCURL=https://hosted.weblate.org/api/ WLCKEY=... wlc ...
or:
wlc --url https://hosted.weblate.org/api/ --key ... ...
Alternatively, use URL-scoped keys in the [keys] section instead of WLCKEY or --key, and avoid running wlc with secrets in untrusted checkouts.
- The issue was independently reported by type5afe and visionx7 using HackerOne.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/wlcto a version that resolves this vulnerability.Fixed in 2.0.1 - Upgrade
Upgrade
wlcto a version that resolves this vulnerability.Fixed in 2.0.1 - Compensating control
When using an unscoped key, explicitly pin the API URL: set WLC_URL together with WLC_KEY, or use wlc --url together with --key. Alternatively, use URL-scoped keys in the [keys] section and avoid running wlc with secrets in untrusted checkouts.
Event History
Frequently Asked Questions
Which usage patterns are exposed to token disclosure?
Users are exposed when they run wlc from an untrusted repository, pull request checkout, or a directory with untrusted ancestor configuration while supplying an unscoped token through WLC_KEY or --key. The risk applies when discovered .weblate, .weblate.ini, or weblate.ini configuration provides the API URL.
What conditions are required for an attacker to receive the token?
An attacker needs control over project configuration in the current directory tree that sets an API URL. The user must then invoke wlc with WLC_KEY or --key without also explicitly setting WLC_URL or --url, allowing the token to be sent to the configured URL.
How can the issue be mitigated before upgrading?
Explicitly pin the API URL whenever using an unscoped key, for example by setting WLC_URL together with WLC_KEY or by passing --url together with --key. URL-scoped keys in the [keys] configuration section are also supported.
What version contains the fix, and how does it change key handling?
Upgrade to wlc 2.0.1 or newer. In the fixed version, WLC_KEY requires WLC_URL and --key requires --url when the API URL would otherwise come from automatically discovered project configuration.