CVE-2025-47951: Weblate Authentication Bypass Vulnerability

CVE-2025-47951 Overview

CVE-2025-47951 affects Weblate, a web-based localization tool used to translate software projects. Versions prior to 5.12 fail to apply rate limiting to the second factor verification endpoint. An attacker holding valid primary credentials can automate one-time password (OTP) guessing against the second-factor challenge. The maintainers patched the issue in version 5.12 by introducing rate limiting on the SECOND_FACTOR endpoint. The weakness is categorized as [CWE-307] Improper Restriction of Excessive Authentication Attempts.

Critical Impact
An attacker with compromised username and password credentials can brute-force OTP codes to bypass two-factor authentication (2FA) and gain full account access.

Affected Products

Weblate versions prior to 5.12
Weblate self-hosted deployments using the built-in second factor authentication
Weblate instances relying on TOTP or WebAuthn OTP verification without external rate limiting

Discovery Timeline

2025-06-16 - CVE-2025-47951 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-47951

Vulnerability Analysis

Weblate implements a two-step authentication flow. After a user submits a valid username and password, the application prompts for a second factor such as a Time-based One-Time Password (TOTP) code. Prior to version 5.12, the endpoint that validates the second factor did not enforce a request rate limit. An attacker who already possesses valid credentials, obtained through phishing, credential stuffing, or database leaks, can iterate through the 10^6 possible six-digit TOTP values programmatically until the correct code is accepted.

The attack requires an authenticated session at the primary credential stage, which raises the complexity. However, once inside the second-factor step, the finite OTP keyspace and the short validity window can be exhausted or narrowed with automated tooling. Successful exploitation defeats the security guarantees of 2FA and yields full account takeover within Weblate.

Root Cause

The application configuration table for rate limits did not include an entry that enforced strict thresholds on the second factor verification path. Other authentication surfaces in Weblate were rate limited, but the second factor endpoint accepted repeated submissions from the same session without triggering throttling or lockout.

Attack Vector

Exploitation is network-based and requires prior possession of valid primary credentials. The attacker scripts repeated POST requests to the second factor verification endpoint, cycling OTP values. Without rate limiting, no server-side counter blocks or slows the attempts, enabling brute-force success within a practical time window.

text

// Patch excerpt: docs/admin/optionals.rst
+-----------------------------------+--------------------+------------------+------------------+----------------+
| Second-factor authentication      | ``SECOND_FACTOR``  | 5                | 300              | 600            |
+-----------------------------------+--------------------+------------------+------------------+----------------+
| Sitewide search                   | ``SEARCH``         | 6                | 60               | 60             |
+-----------------------------------+--------------------+------------------+------------------+----------------+
| Translating                       | ``TRANSLATE``      | 30               | 60               | 600            |
+-----------------------------------+--------------------+------------------+------------------+----------------+

Source: Weblate commit f806293. The patch introduces a SECOND_FACTOR rate limit key that allows 5 attempts, then imposes a 300-second lockout window with a 600-second window scope.

Detection Methods for CVE-2025-47951

Indicators of Compromise

High volume of POST requests to the Weblate second factor verification URL from a single client IP or session identifier within a short interval
Repeated 401 or 403 responses from the second factor endpoint followed by a 200 success response for the same account
Successful logins immediately preceded by dozens or hundreds of failed OTP submissions for the same user

Detection Strategies

Aggregate web server and application logs by user account and source IP, then alert when second factor verification attempts exceed a defined threshold within a rolling window
Correlate primary authentication success with anomalous counts of subsequent second factor requests before session establishment
Baseline normal OTP submission behavior per user; flag deviations such as automated request cadence or non-browser user agents

Monitoring Recommendations

Forward Weblate application logs and reverse proxy access logs to a centralized analytics platform for correlation
Track authentication metrics per user, including failed second factor counts, and generate alerts on statistical outliers
Review Django rate limit counters and lockout events exposed by Weblate after upgrading to 5.12 or later

How to Mitigate CVE-2025-47951

Immediate Actions Required

Upgrade Weblate to version 5.12 or later, which introduces the SECOND_FACTOR rate limit configuration
Force password rotation for accounts that show anomalous second factor request patterns in historical logs
Re-enroll or rotate TOTP secrets for any user whose account may have been targeted while running an unpatched version

Patch Information

The fix is contained in commit f806293451248c5d95e45b3b507e9d158bc4f384 and shipped in Weblate 5.12, with follow-up in 5.12.1. Details are documented in the GitHub Security Advisory GHSA-57jg-m997-cx3q and the Weblate v5.12.1 Release. Administrators should review the updated rate limit table in the Weblate documentation to confirm the SECOND_FACTOR key is active.

Workarounds

Place Weblate behind a reverse proxy or Web Application Firewall (WAF) and enforce rate limiting on the second factor URL path
Enforce account lockout policies at the identity provider layer when Weblate is federated through Single Sign-On (SSO)
Restrict administrative and privileged account access to trusted networks or VPN segments until the upgrade is deployed

bash

# Example nginx rate limit for the Weblate second factor endpoint
limit_req_zone $binary_remote_addr zone=weblate_2fa:10m rate=5r/m;

server {
    location /accounts/two-factor/ {
        limit_req zone=weblate_2fa burst=5 nodelay;
        proxy_pass http://weblate_upstream;
    }
}