Weblate EUVD-2026-66712

Exploitation requires a valid authenticated session with at least low-privilege access to the target Weblate instance (confirmed by CVSS PR:L). The attacker must have a registered user account - anonymous or unauthenticated access is insufficient. No special feature enablement, non-default configuration, or specific platform variant is required; the globally-scoped lookup pattern is present in all pre-2026.7 deployments by default. The primary limiting factor is the authentication gate: restricting self-registration or ensuring all authenticated users are trusted colleagues eliminates the external attack surface. The impact ceiling is also a limiting factor - only object existence (a boolean) is inferrable, not object content.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N scores 4.3 (Medium) and accurately captures the threat profile: network-reachable, low complexity, but gated by prior authentication (PR:L). Real-world impact is strictly limited to object existence inference - an attacker can determine that a specific change ID or announcement ID exists within a private project, but cannot read its content, modify data, or cause a service disruption (I:N, A:N). No EPSS score was supplied in the input, so quantitative exploitation probability cannot be stated. CISA KEV status is absent, confirming no known active exploitation at the time of this analysis. The risk is primarily reconnaissance-enabling: mapping private project activity volume or confirming a competitor's Weblate activity - not a direct data breach vector. For organizations hosting sensitive localization data in private Weblate projects with untrusted authenticated users, the practical risk is slightly higher than the raw CVSS score implies, but patching remains a routine maintenance priority rather than an emergency response.

An authenticated Weblate user with a low-privilege account on a shared instance systematically sends GET requests to change, comment, or announcement endpoints using sequential or guessed object primary key values. When the server returns HTTP 403 the attacker records that object ID as existing within a private project; when it returns HTTP 404 the ID is absent. By iterating a range of IDs, the attacker can reconstruct an approximate timeline and volume of activity for private projects they have no authorization to view. No public exploit code has been identified at time of analysis.