- Status Closed
-
Assigned To
cbay - Private
Opened by monty099 - 30.04.2025
Last edited by cbay - 02.05.2025
FS#167 - Security Report: Persistent Webmail Session After Renaming Email Address in Alwaysdata
Vulnerability Description:
A vulnerability has been discovered in Alwaysdata's email management system that allows an attacker to retain an active Webmail session even after the associated email address has been renamed in the control panel. This issue enables unauthorized access to the previous email identity and settings, potentially allowing an attacker to maintain control without the new user's awareness.
—
Steps to Reproduce:
1. The attacker adds a custom domain (e.g., test.com) to their Alwaysdata account.
2. They create an email address like admin@test.com and log in to Webmail (webmail.alwaysdata.com), keeping the session active.
3. The attacker then goes to the control panel (admin.alwaysdata.com) and renames the email address to something else (e.g., info@test.com) and saves the changes.
4. Although admin@test.com no longer exists in the interface, its Webmail session remains active.
5. The attacker deletes the domain test.com from their account.
6. The Webmail session for admin@test.com is still valid, and the attacker can access and modify email settings.
—Proof of Concept (PoC) Provided: https://admin.alwaysdata.com/support/86544/
Impact of the Vulnerability:
Modification of email settings.
Wide-scale exploitation: The attacker can repeat the process with multiple domains, allowing them to gain control over different email accounts.
Recommendations to Fix the Vulnerability:
1. Terminate all active sessions immediately when an account is deleted or a domain is removed.
2. Link sessions to the user account instead of just the domain to ensure sessions do not transfer between different users.
This vulnerability poses a serious threat to user privacy and account security, and we strongly recommend fixing it as soon as possible.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Hello,
There is no victim in your scenario.
Kind regards,
Cyril
Hello Cyril,
This vulnerability is a bypass of the fix implemented in Report #146.
The victim here is the user who adds the same domain and creates the same email address, while the attacker still holds an active session from the old address.
This allows unauthorized access to the victim’s email.
Thank you,
That's already the case, so I do not believe your "scenario" is valid.
Hello Cyril,
Thank you for following up. However, with all due respect, the scenario is not just theoretical — it’s clearly exploitable.
The video clearly demonstrates that after renaming the email address and deleting the domain, the session tied to the old email remains active and functional. This allows unauthorized access, which directly undermines the fix implemented in Report #146.
This is not a hypothetical edge case — it's a real bypass with tangible impact. I believe the evidence speaks for itself.
I look forward to your reevaluation based on this.
Best regards,
So you have an active session to a deleted domain/mailbox. Again, there is no victim here.
Hello Cyril,
I understand your point of view, but I respectfully disagree. The video clearly shows that the old session remains active and fully functional even after renaming the email address and deleting the domain.
It is true that I performed the deletion during the scenario, but that was only to demonstrate the concept — exactly as I did in Report #146, which was accepted. Nevertheless, the vulnerability is real. The core issue is that the session is not properly terminated when the email address is renamed and the domain is deleted.
The impact is clear: when another user later creates the same email address (e.g., admin@test.com), the attacker still has access through the old session — even though ownership of the mailbox has shifted to another user. This constitutes unauthorized access and makes the new user the victim.
This vulnerability is a clear bypass of the previous fix. I invite you to review the video from this perspective — all the evidence is clearly presented.
Thank you,
Hello,
Thanks for the clarification. The issue is actually not that the session is still valid when the mailbox is deleted, it's that the session is still valid when a new mailbox is created.
Anyway, that's now fixed, you can claim your bounty. Thanks!
Kind regards,
Cyril