Weblate EUVD-2026-66710

The attacker must possess a valid authenticated account on the target Weblate instance (PR:L confirmed by CVSS vector). Beyond authentication, exploitation requires that an administrator send a team or project invitation to the specific email address the attacker has pre-claimed - meaning the attacker must either have advance knowledge of a pending invitation or must socially engineer an administrator into sending one. The vulnerability affects only the REST API path (/api/users/{username}/ via PUT or PATCH); the web UI email-change flow is not confirmed as affected by the advisory. Limiting factors: required prior authentication, dependency on an administrator-triggered invitation workflow, and the need to predict or know the target invitation address. Without a subsequent invitation being issued to the claimed address, the account email change has no exploitable consequence.

The CVSS 3.1 score of 3.5 (Low) accurately reflects the constrained impact: the vulnerability is network-accessible with low complexity, but requires prior authentication (PR:L) and depends on an administrator subsequently dispatching an invitation to the claimed address (UI:R), with only a low integrity impact and no confidentiality or availability consequence. EPSS data was not included in the provided input and cannot be stated. There is no CISA KEV listing, and no public exploit code exists, placing this firmly in the lowest-priority exploitation tier. The realistic attack surface is narrow: the adversary must hold a valid Weblate account and must either predict which address will receive a future invitation or have insider knowledge of a pending one. Despite the low numeric score, organizations with sensitive localization content - legal, medical, or government translation workflows - should treat this as a meaningful integrity issue, since unauthorized project membership could expose source strings or translation memory that is not intended to be public.

An authenticated Weblate user sends a PATCH request to /api/users/{username}/ with a target email address - one they do not own and have not verified - setting it as their primary account email. When an administrator later issues a team invitation to that same address, the attacker's account automatically becomes the recipient and accepts membership in the project or group, granting unauthorized access without the legitimate address owner ever being involved. No exploit tooling beyond standard HTTP client knowledge is required.