Weblate is a self-hosted Django-based continuous-localisation platform. Findings catalogued here were disclosed through GitHub Security Advisories and patched upstream.
If you self-host Weblate, the fixes are in 5.17.1 or later — upgrade.
| CVE | Severity | Class | Auth Required | One-line |
|---|---|---|---|---|
| CVE-2026-41519 | Moderate 4.2 | Insufficient Session Expiration (CWE-613) | Pre-existing token holder | API token (wlu_…) survives password change → stolen-token persistence after incident response |
- Affected: Weblate
< 5.17.1 - Fixed:
5.17.1 - Disclosure: GHSA published 2026-04-30; CVE-2026-41519 assigned by GitHub.
Even from a single finding, the pattern is worth noting because it generalises across Django/DRF projects:
- Session lifecycle ≠ token lifecycle. Django's session machinery and DRF's
authtokenare independent subsystems. Code that rotates one rarely rotates the other unless the project explicitly bridges them. Weblate hadcycle_session_keys()wired into password change, but no equivalent forToken.objects.filter(user=...).delete(). - Long-lived bearer tokens demand explicit rotation hooks. DRF
authtokenhas no built-in expiry. Any project using it for a sensitive API must implement rotation on every state transition the user expects to "log everyone out": password change, password reset, MFA enrolment, device-trust revocation, account suspension. - Default-on is the right opt-out shape. The Weblate fix exposes a "Regenerate API key" checkbox during password change, but defaults it to on — preserving the secure path for the 99% of users who don't think about it, while documenting an opt-out for the 1% with long-running automation.
Found and reported by @whatisproblem.
Thanks to the Weblate maintainers (@WeblateOrg, patch by @nijel) for prompt triage and the well-considered opt-out UX in the fix.