Account takeover when having only access to a user's short lived token

Vulnerability

CVE-2021-41093 affects the Wire secure messenger (open-source). In versions prior to 2021-08-16 (server-side) and client app version 3.86, the endpoint for changing the user's email address accepted only a short-lived access token from the Authorization header. The short-lived token is an HTTP header token that is less protected than the long-lived cookie. An attacker who obtains a valid short-lived token (which is used more frequently and transmitted in HTTP headers) can call the POST /self/email endpoint to change the victim's email address. The affected server versions are those before the deployment on 2021-08-16; the iOS client fix was applied in version 3.86, which updates wire-ios-sync-engine to 385.0.1 and wire-ios-transport to 77.1.0 [1][2].

Exploitation

The attacker only needs access to a valid short‑lived access token for the target user. Short‑lived tokens are requested by the client using long‑lived tokens and are sent as an HTTP Authorization header with every request that is not the initial authentication. If the attacker intercepts this token (e.g., via a network leak, log access, or cross‑site scripting) they can reuse it to call the /self/email endpoint. The attack does not require the user’s password or long‑lived cookie. The attacker simply sets a new email address of their choice, then uses the password‑reset flow to take full control of the account [1].

Impact

Successful exploitation allows the attacker to change the email address associated with the Wire account. Because the email change is a privileged operation that should require stronger authentication, this constitutes a privilege escalation. After the change, the attacker can trigger a password reset email sent to the new address, gaining full control of the account (account takeover). The impact is a complete compromise of confidentiality, integrity, and availability of the victim’s Wire account and communications [1].

Mitigation

Wire fixed the issue on its SaaS platform on 2021‑08‑16 by deploying a new endpoint that requires both the long‑lived client cookie and the Authorization header; the old endpoint was removed [1]. Client version 3.86 (released around the same time) updates the sync‑engine and transport libraries to enforce the new server behavior [2]. For on‑premises instances that use SCIM or SAML SSO, email changes are already blocked or stored separately, so those users are not affected. As a workaround when a patch cannot be applied immediately, on‑premises administrators can block the /self/email path at the reverse proxy (nginz) or firewall [1].