A user can delete their own primary email if they know the UUID, leaving the account in a broken state. The impact is low as this only results in a self-denial of service.
Assume that a user, without special privileges, knows the UUID of their primary email. Normally a user is not supposed to change their primary email. If they know the UUID, e.g., 09db720e-fcb5-4313-9242-f846f1d76359, they can delete the primary email:
DELETE /profile/emails/09db720e-fcb5-4313-9242-f846f1d76359 HTTP/1.1
Host: eyedp.example.com:3000
Content-Length: 200
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://eyedp.example.com:3000
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://eyedp.example.com:3000/profile/emails
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: __profilin=p%3Dt; _eyed_p_session=ba2ca38dcd3caa443a89d50908e1a7cc
Connection: close
authenticity_token=bWUMVlJMz6NVqrPQnwva3u1bSqC9o4bctBZVBKm2BmMsNcfatM41MMblyMqPPnGnut3K5v%2FeDco9pU3Hnrqq%2BQ%3D%3D&email%5Baddress%5D=marcellopogliani1%40radicallyopensecurity.com&commit=Save+Changes
HTTP/1.1 302 Found
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: strict-origin-when-cross-origin
Content-Type: text/html; charset=utf-8
Location: http://eyedp.example.com:3000/profile/emails
Cache-Control: no-cache
X-Request-Id: 794c6166-518d-4183-8a30-9eee4c8c2d7b
X-Runtime: 0.103804
Set-Cookie: __profilin=p%3Dt; path=/; HttpOnly; SameSite=Lax
Connection: close
Content-Length: 110
You are being redirected.
As a result the primary email is deleted and the primary_email field in the user table results broken / empty. Due to this the account is basically not accessible as exceptions are thrown at every page load.
From the point of view of the admin the user has no primary email and only additional emails
Very low as simply a user can perform a DoS against their own account. The only threat is that a user may be able to use this to "convince" the admin to "restore" the primary email to the now-only email on their profile.
A user can delete their own primary email if they know the UUID, leaving the account in a broken state. The impact is low as this only results in a self-denial of service.
Assume that a user, without special privileges, knows the UUID of their primary email. Normally a user is not supposed to change their primary email. If they know the UUID, e.g., 09db720e-fcb5-4313-9242-f846f1d76359, they can delete the primary email:
As a result the primary email is deleted and the primary_email field in the user table results broken / empty. Due to this the account is basically not accessible as exceptions are thrown at every page load.
From the point of view of the admin the user has no primary email and only additional emails
Impact
Very low as simply a user can perform a DoS against their own account. The only threat is that a user may be able to use this to "convince" the admin to "restore" the primary email to the now-only email on their profile.
Patches
This issue is resolved in commit a78c75d. Users should upgrade to the latest commit on main or to a 1.0.0 or later release.
Workarounds
None
For more information
If you have any questions or comments about this advisory: