Impact

It was possible to accept an invitation opened by a different Weblate user.

Patches

https://github.com/WeblateOrg/weblate/pull/16913

Workarounds

Users should avoid leaving Weblate sessions with an unattended opened invitation.

References

Thanks to Nahid0x for responsibly disclosing this vulnerability to Weblate.

Impact

It was possible to overwrite Git configuration remotely and override some of its behavior.

Resources

Thanks to Jason Marcello for responsible disclosure.

Impact The SSH management console did not validate the passed input while adding the SSH host key, which could lead to an argument injection to ssh-add.

Patches https://github.com/WeblateOrg/weblate/pull/17722

Workarounds Properly limit access to the management console.

References This issue was reported to us by alexb616 via HackerOne.

Impact

The user patching API endpoint didn't properly limit the scope of edits.

Patches https://github.com/WeblateOrg/weblate/pull/18687

References Thanks to @tikket1 and @DavidCarliez for reporting this via GitHub. We received two individual reports for this.

Impact Weblate didn't correctly sanitize some arguments passed to Git and Mercurial, which allowed changing their behavior in an unintended way.

Patches

The issues were fixed in the 4.11.1 release. The following commits are addressing it:

35d59f1f040541c358cece0a8d4a63183ca919b8 d83672a3e7415da1490334e2c9431e5da1966842

Workarounds

Instances in which untrusted users cannot create new components are not affected.

References SNYK-PYTHON-WEBLATE-2414088

For more information If you have any questions or comments about this advisory: Open a topic in discussions Email us at care@weblate.org

Impact Multi-translation download could write to an arbitrary location when instructed by a crafted server.

Patches https://github.com/WeblateOrg/wlc/pull/1128

Workarounds Do not use wlc download with untrusted servers.

References This issue was reported to us by wh1zee via HackerOne.

Impact The project backup didn't filter Git and Mercurial configuration files and this could lead to remote code execution under certain circumstances.

Patches https://github.com/WeblateOrg/weblate/pull/18549

Workarounds The project backup is only accessible to users who can create projects. Restricting access to this limits scope of the vulnerability.

References This issue was reported by ggamno via HackerOne.

Impact The API did not properly handle project- and workspace-scoped teams and allowed setting invalid configurations, including granting access to projects the user has no access to.

Patches https://github.com/WeblateOrg/weblate/pull/19970

References

Parts of this issue were independently reported by four reporters: @H3xV0rT3x via GitHub imhego via HackerOne v01demort via HackerOne b4nder via HackerOne

Impact It was possible to read arbitrary files from the server file system using crafted symbolic links in the repository.

Resources

Thanks to Jason Marcello for responsible disclosure.

Impact

The ZIP download feature didn't verify downloaded file and it could follow symlinks outside the repository.

Patches

https://github.com/WeblateOrg/weblate/pull/18683

References

Thanks to @DavidCarliez for reporting this vulnerability via GitHub.

Weblate is a web-based continuous localization platform used to manage software translations. In versions prior to 2026.7, a project administrator can read files outside their repository through the App store metadata download feature, which resolves attacker-influenced paths without adequately confining them to the repository. This is an incomplete fix for CVE-2026-34242, whose original patch failed to fully prevent the path traversal, allowing the arbitrary file read to persist. A user with project-administrator privileges can therefore disclose the contents of files on the Weblate host that lie outside the project's repository. This issue is fixed in version 2026.7.

Summary

When creating a new component from an existing component that has a source code repository URL specified in settings, this URL is included in the client's URL parameters during the creation process. If, for example, the source code repository URL contains GitHub credentials, the confidential PAT and username are shown in plaintext and get saved into browser history. Moreover, if the request URL is logged, the credentials are written to the logs in plaintext.

The problematic URL in question is of this form:

https://<HOST>/create/component/vcs/?repo=https%3A%2F%2F<GITHUB USERNAME>%3A<GITHUB PAT>%40github.com%2F<REPOSITORY OWNER>%2F<REPOSITORY NAME>.git&project=1&category=&name=<REDACTED>&slug=<REDACTED>&isglossary=False&vcs=github&sourcelanguage=228&license=&sourcecomponent=1#existing

If using Weblate official Docker image, nginx logs the URL and the token in plaintext:

nginx stdout | 127.0.0.1 - - [04/Apr/2025:10:46:54 +0000] "GET /create/component/vcs/?repo=https%3A%2F%2F<GITHUB USERNAME>%3A<GITHUB PAT>%40github.com%2F<REPOSITORY OWNER>%2F<REPOSITORY NAME>.git&project=1&category=&name=<REDACTED>&slug=<REDACTED>&isglossary=False&vcs=github&sourcelanguage=228&license=&sourcecomponent=1 HTTP/1.1" 200 17625 "<REDACTED>" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:136.0) Gecko/20100101 Firefox/136.0"

Reproduction

1. In a project, create a component which has the Repository push URL setting configured with, for example, a GitHub repository URL including a username and a PAT. 2. In the same project, create another component using the From existing component option and selecting the previous component as the source. Click Continue. 3. Observe that the URL parameter repo includes the secret PAT configured in the original components settings. The URL with the token is potentially saved as plaintext in browser history and server logs. 4. Select a translation file to import and click Continue. 5. Observe again the same repo parameter in the URL.

Impact

- If server logs are compromised, the attacker may be able to gain access to private repositories potentially containing sensitive source code. - Under common browser settings, the URL containing VCS credentials is saved into browser history. Browser extensions, for example, are often able to read the history and thus offer a realistic attack vector to gain access to the credentials.

Impact The screenshot images were served directly by the HTTP server without proper access control. This could allow an unauthenticated user to access screenshots after guessing their filename.

Patches https://github.com/WeblateOrg/weblate/pull/17516

References

Thanks to Lukas May and Michael Leu for reporting this.

Impact The translation memory API exposed unintended endpoints, which in turn didn't do proper access control.

Patches https://github.com/WeblateOrg/weblate/pull/18516

Workarounds The CDN add-on is not enabled by default.

References Thanks to @spbavarva for reporting this responsibly via GitHub.

Impact The verification of the second factor had too long a session expiry. The long session expiry could be used to circumvent rate limiting of the second factor.

Patches This issue has been addressed in Weblate 5.13.1 via https://github.com/WeblateOrg/weblate/pull/16002.

References Thanks to Nahid Hasan Limon for reporting this issue responsibly.

Weblate is a web-based continuous localization platform used to manage software translations. In versions prior to 2026.7, a user with the built-in "Edit source" role can store a malicious regular expression in a source string's flags that is executed without any timeout, allowing them to stall requests and deny service. Regular expressions supplied through the regex: quality check and regex placeholders are compiled during validation but later run against translation content in RegexCheck and PlaceholderCheck with no time limit, so a catastrophic-backtracking pattern like ^(a|aa)+$ can consume CPU indefinitely. Because Weblate re-runs these checks for every linked target unit in the same request when a source unit's flags change, a single edit can trigger sustained CPU-bound denial of service. This issue is fixed in version 2026.7.

Weblate is a web based localization tool. An open redirect exists in versions 5.13.2 and below via the redir parameter on .within.website when Weblate is configured with Anubis and REDIRECTDOMAINS is not set. An attacker can craft a URL on the legitimate domain that redirects a victim to an attacker-controlled site. The redirect can also be used to initiate drive-by downloads (redirecting to a URL that serves a malicious file), increasing the risk to end users. This issue is fixed in version 5.13.3.

Impact

Weblate's VCSRESTRICTPRIVATE did not properly account for some transitional IPv6 ranges, multicast addresses, or some semi-private IPv4 ranges, which allowed some addresses to bypass private range restrictions.

Patches

https://github.com/WeblateOrg/weblate/pull/19768

Resources

The issue was reported by @tonghuaroot via GitHub, and the same user also provided the initial patch.

Impact The SSL verification would be skipped for some crafted URLs.

Patches https://github.com/WeblateOrg/wlc/pull/1097

Workarounds Avoid using untrusted wlc configurations, as that might cause insecure connections.

References This issue was reported to us by wh1zee via HackerOne.

Impact Historically, wlc supported providing unscoped API keys in the setting. This practice was discouraged for years, but the code was never removed. This might cause the API key to be used against different server.

Patches https://github.com/WeblateOrg/wlc/pull/1098

Workarounds Remove unscoped key from wlc configuration. Only use URL-scoped keys in the [keys] sections.

References This issue was reported to us by wh1zee via HackerOne.

Impact Weblate didn't correctly validate filenames when restoring project backup. It may be possible to gain unauthorized access to files on the server using a crafted ZIP file.

Patches This issue has been addressed in Weblate 5.6.2 via https://github.com/WeblateOrg/weblate/commit/b6a7eace155fa0feaf01b4ac36165a9c5e63bfdd.

Workarounds Do not allow project creation to untrusted users.

References Thanks to Bryan Cahill for bringing this issue to our attention.

For more information If you have any questions or comments about this advisory: Open a topic in discussions Email us at care@weblate.org

Impact When a user changes their password, browser sessions are correctly invalidated via cyclesessionkeys(), but DRF API tokens (wlu prefix) stored in authtokentoken are not revoked.

Patches https://github.com/WeblateOrg/weblate/pull/19057

Resources Weblate thanks Sang Yu Jeon for reporting this via GitHub.

Impact Due to improper neutralization, it was possible to perform cross-site scripting via crafted user and language names.

Patches

The issues were fixed in the 4.11 release. The following commits are addressing it:

f6753a1a1c63fade6ad418fbda827c6750ab0bda 9e19a8414337692cc90da2a91c9af5420f2952f1 22d577b1f1e88665a88b4569380148030e0f8389

Workarounds

You can look for crafted user and language names to see if you were affected.

References https://hackerone.com/reports/1486674 https://hackerone.com/reports/1486718 https://hackerone.com/reports/1485226

For more information If you have any questions or comments about this advisory: Open a topic in discussions Email us at care@weblate.org

Impact

The audit log notifications included the full IP address of the acting user. This could be obtained by third-party servers such as SMTP relays, or spam filters.

Patches

This issue has been addressed in Weblate 5.12 via https://github.com/WeblateOrg/weblate/pull/15102.

References

Thanks to micael1 for reporting this issue at HackerOne.

Impact

It was possible to trigger repository updates for many repositories via a crafted webhook payload.

Patches

https://github.com/WeblateOrg/weblate/pull/17221

Workarounds

Disabling webhooks completely using ENABLEHOOKS avoids this vulnerability.

References

Thanks to Hector Ruiz Ruiz & NaxusAI for responsibly disclosing this vulnerability to us.

Impact An authenticated user with project.add permission (default on hosted Weblate SaaS and for any user holding an active billing/trial plan) can import a crafted project backup ZIP whose components/<name>.json contains an attacker-chosen repo URL pointing at a private address (e.g. http://127.0.0.1:9999/) or using a non-allow-listed scheme (e.g. file://, git://). Weblate persists the component via Component.objects.bulkcreate([component])[0], which bypasses Django's fullclean() and therefore never runs the validaterepourl validator. The URL is subsequently written verbatim into .git/config by configurerepo(pull=False).

Patches https://github.com/WeblateOrg/weblate/pull/19061 https://github.com/WeblateOrg/weblate/pull/19062

Workarounds Limiting who can create projects limits the scope.

Resources Weblate thanks @fg0x0 for reporting this vulnerability via GitHub.

Weblate is a web-based continuous localization platform used to manage software translations. In versions prior to 2026.8, Weblate's object-scoped RSS feeds do not apply the permission checks used elsewhere, allowing unauthorized users to read change-history metadata from private projects and restricted components. On installations that permit anonymous access, this metadata can be retrieved without any authentication. The exposed information can include project and component identities, contributor usernames and full names, action types, timestamps, and translation or unit links, though translated-string content is not included in the feed. Installations using private projects or restricted components are affected. This issue is fixed in version 2026.8.

The password reset form in Weblate before 2.10.1 provides different error messages depending on whether the email address is associated with an account, which allows remote attackers to enumerate user accounts via a series of requests.

wlc is a Weblate command-line client using Weblate's REST API. Prior to version 2.0.0, the HTML output format in wlc embeds API response data into HTML without escaping, allowing cross-site scripting when the output is rendered in a browser. This issue has been patched in version 2.0.0.

Impact The Create Component functionality in Weblate allows authorized users to add new translation components by specifying both a version control system and a source code repository URL to pull from. However, the repository URL field is not validated or sanitized, allowing an attacker to supply arbitrary protocols, hostnames, and IP addresses, including localhost, internal network addresses, and local filenames.

When the Mercurial version control system is selected, Weblate exposes the full server-side HTTP response for the provided URL. This effectively creates a server-side request forgery (SSRF) primitive that can probe internal services and return their contents. In addition to accessing internal HTTP endpoints, the behavior also enables local file enumeration by attempting file:// requests. While file contents may not always be returned, the application’s error messages clearly differentiate between files that exist and files that do not, revealing information about the server’s filesystem layout.

In cloud environments, this behavior is particularly dangerous, as internal-only endpoints such as cloud metadata services may be accessible, potentially leading to credential disclosure and full environment compromise.

Patches

This has been addressed in the Weblate 5.15 release.

https://github.com/WeblateOrg/weblate/pull/17103 https://github.com/WeblateOrg/weblate/pull/17102

Workarounds

Removing Mercurial from VCSBACKENDS avoids this vulnerability, as the Git backend is not affected. The Git backend was already configured to block the file protocol and does not expose the HTTP response content in the error message.

References Thanks to Jason Marcello for responsible disclosure.