CVE-2022-32741

What it actually does

The flaw is a timing side-channel in the password reset workflow that leaks whether a supplied username is valid or not by returning measurably different response latencies.

Why it matters to the business

Attackers can silently enumerate valid user accounts across the internet, enabling targeted follow-on attacks such as credential stuffing or phishing; the issue has been public for more than four years with negligible exploit activity observed.

How an attack unfolds

An unauthenticated attacker repeatedly submits the password-reset form with candidate usernames and records the elapsed time for each HTTP response; usernames that produce noticeably longer or shorter responses are inferred to be valid accounts.

How to fix it

Upgrade to a maintained release that enforces constant-time responses for the password-reset feature; until a patch is available, implement a reverse-proxy or WAF rule that adds artificial jitter or normalizes response times for all unauthenticated reset requests.

How to confirm the fix worked

After applying the fix, replay a set of known-valid and known-invalid usernames against the reset endpoint and confirm that response-time distributions are statistically indistinguishable; also verify that the application version string no longer matches the vulnerable range.

Typical attack path

1. Identify the public password-reset endpoint
2. Generate a list of candidate usernames (harvested from other sources or brute-force patterns)
3. Issue parallel or sequential reset requests while measuring server response times
4. Statistically classify which usernames produced outlier latencies
5. Feed the confirmed valid usernames into subsequent attacks such as password spraying or social-engineering campaigns

How to detect it

Search web-server access logs for repeated POSTs to the password-reset endpoint originating from the same client IP or subnet within short time windows; correlate with unusually consistent or patterned response-time values if timing data is logged.

What your security team should do

• Treat the finding as a low-severity enumeration risk and schedule patching during the next routine maintenance window
• Add a WAF or load-balancer rule that pads password-reset responses to a fixed minimum latency
• Monitor authentication logs for anomalous volumes of password-reset attempts from single source IPs
• Review and reduce the set of user attributes that are exposed through timing differences in any unauthenticated workflow