User Enumeration via Response Timing in typo3/typo3


Reported on

Aug 25th 2022


There is a significant timing difference in the login functionality for valid and invalid usernames.

Proof of Concept

1. Attempt a Login with a valid user and an invalid user and observe the difference in the response time

Here is a small test script (alternatively we can see the response time in Burp Repeater)

import requests

url = ""
valid_user = {"username": "admin", "userident": "pw", "login_status": "login"}
invalid_user = {"username": "doesnotexist", "userident": "pw", "login_status": "login"}

for _ in range(3):
    r =, data=valid_user)


for _ in range(3):
    r =, data=invalid_user)



We can see that there is a difference in response time of about 750ms. This of course depends on the hash function the password is hashed with. Note that the rate limit was disabled for this PoC.


An attacker is able to identify valid usernames. This could allow for further attacks such as brute force attacks on valid accounts. The impact of this is significantly reduced because of the Rate Limit which is in place by default. The Rate Limit blocks an IP address after 5 failed login attempts. So a username enumeration attack is severely limited and only realistically possible if rate limiting is disabled.


The hash function in authUser is only executed when the username exists in the database. To mitigate this, the hash function should be executed with a dummy input even when the username does not exist.

We are processing your report and will contact the typo3 team within 24 hours. a year ago
We have contacted a member of the typo3 team and are waiting to hear back a year ago
Oliver Hader
a year ago


Thanks for providing this detailed and in-depth report!

We were able to reproduce mentioned CWE-204 with a significant timing discrepancy for existing vs non-existing user accounts.

As mentioned in the report already, the rate limiter (defaults to 5 requests per 15 minutes) successfully mitigates the scenario - this feature has been introduced with TYPO3 v11. IP-based rate-limiting can be by-passed by using frequently changing proxies like torsocks or similar.

The base CVSS we assessed would be 5.3 (medium):

  • TYPO3 v11+ (having rate-limiter per default): AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N -> 3.7
  • TYPO3 v10 and earlier: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N -> 5.3

Since TYPO3's auth system allows to use multiple (combined) services, password hashing is not the only factor that has an impact on response times. Auth requests can be handed over to remote LDAP services or similar - instead of "hashing time", the the discrepancy would be "network latency" and might be different again.

However, addressing this in the core of TYPO3 most probably solves this for 90% of all installations. Custom auth services would have to implement agains a new TYPO3\CMS\Core\Authentication\MimicServiceInterface::mimicAuthUser() which simulates these process times.

Oliver Hader modified the CWE from Observable Response Discrepancy to Observable Timing Discrepancy a year ago
Oliver Hader
a year ago


We are going to request a CVE on our own via GitHub. This report will be updated once a fix has been released.

@vautia TYPO3 has a dedicated bug bounty program, please get in contact with in case you'd like to get rewarded.

The researcher has received a minor penalty to their credibility for misclassifying the vulnerability type: -1
Oliver Hader validated this vulnerability a year ago
vautia has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Oliver Hader gave praise a year ago
Thanks for providing this detailed and in-depth report!
The researcher's credibility has slightly increased as a result of the maintainer's thanks: +1
a year ago


Thanks for letting me know about the dedicated bug bounty program. I'll get in touch!

We have sent a fix follow up to the typo3 team. We will try again in 7 days. a year ago
We have sent a second fix follow up to the typo3 team. We will try again in 10 days. a year ago
Jamie Slome
a year ago


CVE added to the report 👍

Oliver Hader marked this as fixed in 10.4.32, 11.5.16 with commit f8b83c a year ago
Oliver Hader has been awarded the fix bounty
This vulnerability will not receive a CVE
Oliver Hader published this vulnerability a year ago
to join this conversation