CVE-2026-41654
Authenticated Remote Code Execution via Malicious Project Backup Import in Weblate
Publication date: 2026-05-07
Last updated on: 2026-05-07
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| weblate | weblate | to 5.17.1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
| CWE-20 | The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not explicitly address how the vulnerability impacts compliance with common standards and regulations such as GDPR or HIPAA.
Can you explain this vulnerability to me?
CVE-2026-41654 is a security vulnerability in Weblate, a web-based localization tool. Before version 5.17.1, an authenticated user with project.add permission could import a crafted project backup ZIP file containing a malicious repository URL. This URL could point to private addresses (e.g., http://127.0.0.1:9999/) or use non-allow-listed schemes (e.g., file://, git://).
The vulnerability arises because Weblate persists components using a method that bypasses Django's full validation, allowing the malicious URL to be written directly into the .git/config file. This improper validation could lead to unauthorized interactions with private or restricted resources.
The issue was fixed in version 5.17.1 by adding explicit validation of repository URLs during backup restoration and enforcing validation on remote operations in Git commands.
How can this vulnerability impact me? :
This vulnerability can allow an authenticated user with certain permissions to import project backups containing malicious repository URLs that point to private or restricted network addresses or use disallowed URL schemes.
Such an attack could lead to Server-Side Request Forgery (SSRF), potentially enabling unauthorized access to internal services or resources that are not normally accessible externally.
It may also compromise data integrity by manipulating the backup restoration process, possibly leading to unauthorized repository configurations.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves an attacker importing a crafted project backup ZIP file containing malicious repository URLs that bypass validation and are written into the .git/config file. Detection involves checking for unauthorized or suspicious repository URLs in project backup components and .git/config files.
You can detect this vulnerability by inspecting the repository URLs configured in your Weblate projects, especially those restored from backups. Look for URLs pointing to private addresses (e.g., http://127.0.0.1:9999/) or using non-allow-listed schemes such as file:// or git://.
Suggested commands to detect suspicious repository URLs include:
- Search for suspicious URLs in the .git/config files of your Weblate repositories: `grep -rE 'file://|git://|http://127\.0\.0\.1|http://localhost' /path/to/weblate/repos/*/.git/config`
- Check the components/<name>.json files inside project backup ZIPs before importing them for suspicious repo URLs: `unzip -p backup.zip components/* | grep -E 'file://|git://|http://127\.0\.0\.1|http://localhost'`
- Audit recent project backup imports and verify if any contain non-validated repository URLs.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, immediately upgrade Weblate to version 5.17.1 or later, where the issue has been patched by enforcing validation of repository URLs during project backup restoration.
If upgrading immediately is not possible, consider the following workarounds:
- Restrict project creation and backup import permissions to trusted users only, limiting who can import project backups.
- Manually inspect and validate any project backup ZIP files before importing them to ensure they do not contain malicious repository URLs.
- Audit existing repositories for suspicious repository URLs and remove or correct any that point to private or non-allow-listed addresses.