The vulnerability occurs because the authentication flow skips password checks for non-existent users. The authenticate method in AbstractUserDetailsAuthenticationProvider is the central coordinator: it calls retrieveUser (from DaoAuthenticationProvider) to load the user. If retrieveUser throws due to a missing user, authenticate does not execute additionalAuthenticationChecks, creating a measurable time difference. Both methods appear in runtime traces during exploitation: retrieveUser when the user lookup fails, and authenticate when it handles the exception and skips the password check. The lack of password-related function calls (e.g., additionalAuthenticationChecks) in invalid username scenarios would be detectable via profiling.