Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
37 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 5.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Weblate leaks the IP address of the project member inviting the user to the project in the audit log. Details The audit log included IP addresses from admin-triggered actions, and those could be viewed by invited users. Impact The inviting user's (admin's) IP address could be leaked to invited users.
Recommended action: Upgrade to 5.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 REDIRECT_DOMAINS 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.
Recommended action: Upgrade to 5.13.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The verification of the second factor was not subject to rate limiting. The absence of rate limiting on the second factor endpoint allows an attacker with valid credentials to automate OTP guessing. Patches This issue has been addressed in Weblate 5.12 via https://github.com/WeblateOrg/weblate/pull/14918. References Thanks to obscuredeer for reporting this issue at HackerOne.
Recommended action: Upgrade to 5.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: If using Weblate official Docker image, nginx logs the URL and the token in plaintext: 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…
Recommended action: Upgrade to 5.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 5.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 4.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 4.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.