Can you explain this vulnerability to me?

CVE-2026-24468 is a vulnerability in the OpenAEV platform's password reset API endpoint (/api/reset) present in versions from 1.11.0 up to before 2.0.13. The issue arises because the endpoint returns different HTTP status codes depending on whether the submitted email exists in the system: HTTP 400 (Bad Request) for non-existent emails and HTTP 200 (OK) for valid emails.

This difference in server responses allows an unauthenticated attacker to reliably determine which email addresses are registered in the application by automating requests with lists of possible emails. This is known as an account enumeration vulnerability.

The vulnerability is classified under CWE-204: Observable Response Discrepancy, where the product leaks internal state information through differing responses to unauthorized requests. The fix involves making the endpoint return a consistent response regardless of whether the username/email exists.

Useful 0 Not Useful 0

How can this vulnerability impact me? :

This vulnerability allows attackers to enumerate valid user accounts without any authentication by observing the different HTTP responses from the password reset endpoint.

With a list of valid emails, attackers can launch further attacks such as password reset abuse, credential stuffing, and brute-force attempts against confirmed accounts.

The vulnerability has a moderate severity with a CVSS v3.1 base score of 5.3, indicating it can be exploited remotely over the network with low complexity and no privileges or user interaction required.

Useful 0 Not Useful 0

How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing the HTTP response codes returned by the /api/reset endpoint when submitting different email addresses. Specifically, sending requests with non-existent emails results in HTTP 400 responses, while valid registered emails return HTTP 200 responses. This discrepancy allows an attacker to enumerate valid accounts.

A proof-of-concept detection method involves automating requests against the /api/reset endpoint using tools like ffuf on a Linux system to test a list of possible email addresses and observe the differing HTTP response codes.

• Use ffuf or a similar HTTP fuzzing tool to send POST requests to /api/reset with different email addresses in the login parameter.
• Observe the HTTP status codes: 200 indicates a valid email, 400 indicates a non-existent email.
• Example ffuf command: ffuf -X POST -d 'login=EMAIL' -u https://target/api/reset -w emails.txt -H 'Content-Type: application/x-www-form-urlencoded'

Useful 0 Not Useful 0

What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation step is to upgrade the OpenAEV platform to version 2.0.13 or later, where this vulnerability has been fixed.

The fix ensures that the /api/reset endpoint returns a consistent HTTP response regardless of whether the username/email exists, preventing account enumeration.

Until the upgrade is applied, consider monitoring and rate-limiting requests to the /api/reset endpoint to reduce the risk of automated enumeration attacks.

Useful 0 Not Useful 0

How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows an attacker to enumerate valid email addresses registered in the OpenAEV platform without authentication by exploiting observable differences in API responses. Such unauthorized disclosure of user existence information can lead to privacy violations and facilitate further attacks like password reset abuse and credential stuffing.

From a compliance perspective, this information leakage could impact adherence to data protection regulations such as GDPR and HIPAA, which require safeguarding personal identifiable information (PII) and preventing unauthorized access or disclosure of user data.

Specifically, the ability to confirm registered emails may be considered a breach of confidentiality under these standards, potentially leading to non-compliance issues if exploited.

The fix implemented in version 2.0.13, which ensures consistent API responses regardless of username existence, helps mitigate this risk and supports compliance efforts by preventing account enumeration.

Useful 0 Not Useful 0