Headline
GHSA-3ggv-qwcp-j6xg: Mautic Vulnerable to User Enumeration via Response Timing
Impact
The attacker can validate if a user exists by checking the time login returns. This timing difference can be used to enumerate valid usernames, after which an attacker could attempt brute force attacks.
Patches
This vulnerability has been patched, implementing a timing-safe form login authenticator that ensures consistent response times regardless of whether a user exists or not.
Technical Details
The vulnerability was caused by different response times when:
- A valid username was provided (password hashing occurred)
- An invalid username was provided (no password hashing occurred)
The fix introduces a TimingSafeFormLoginAuthenticator that performs a dummy password hash verification even for non-existent users, ensuring consistent timing.
Workarounds
No workarounds are available. Users should upgrade to the patched version.
References
- https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account
- https://github.com/mautic/mautic-security/pull/146
Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.