CVE-2026-24468: OpenAEV Information Disclosure Flaw

CVE-2026-24468 Overview

OpenAEV is an open source platform allowing organizations to plan, schedule, and conduct cyber adversary simulation campaigns and tests. A significant information disclosure vulnerability exists in the password reset functionality that enables account enumeration attacks.

Starting in version 1.11.0 and prior to version 2.0.13, the /api/reset endpoint behaves differently depending on whether the supplied username exists in the system. When a non-existent email is provided in the login parameter, the endpoint returns an HTTP 400 response (Bad Request). When a valid email is supplied, the endpoint responds with HTTP 200. This difference in server responses creates an observable discrepancy that allows an attacker to reliably determine which emails are registered in the application.

Critical Impact

Attackers can enumerate valid user accounts without authentication, potentially enabling targeted phishing campaigns, credential stuffing attacks, or social engineering against confirmed system users.

Affected Products

• OpenAEV versions 1.11.0 through 2.0.12
• OpenAEV /api/reset endpoint
• Organizations using OpenAEV for adversary simulation without patching to 2.0.13

Discovery Timeline

• 2026-04-20 - CVE CVE-2026-24468 published to NVD
• 2026-04-20 - Last updated in NVD database

Technical Details for CVE-2026-24468

Vulnerability Analysis

This vulnerability is classified under CWE-204 (Observable Response Discrepancy), a category of information exposure flaws where application responses reveal sensitive information through behavioral differences. In this case, the password reset endpoint exhibits different HTTP response codes based on whether the submitted email address corresponds to a registered account.

The attack surface is network-accessible and requires no authentication or user interaction, making it trivial to exploit at scale. While the vulnerability does not directly compromise user credentials or system integrity, it provides attackers with a reliable method to confirm which email addresses are registered in the OpenAEV platform—valuable reconnaissance data that can be leveraged in subsequent attack phases.

Root Cause

The root cause lies in the differential error handling within the password reset API logic. The application fails to implement a consistent response pattern regardless of username validity. When processing reset requests, the code path for invalid emails returns HTTP 400, while valid emails return HTTP 200. This design flaw violates security best practices that mandate identical responses for both existing and non-existing accounts to prevent enumeration.

The vulnerable logic resides in the UserApi.java file, as referenced in the GitHub User API Code.

Attack Vector

An attacker can exploit this vulnerability by automating HTTP requests to the /api/reset endpoint with a wordlist of potential email addresses. By observing the HTTP response codes, the attacker can quickly differentiate between valid and invalid accounts. This technique requires no authentication and can be performed remotely over the network.

The attack flow typically involves:

1. Compiling a list of potential target email addresses
2. Sending automated POST requests to /api/reset with each email
3. Recording responses—HTTP 200 indicates a valid account, HTTP 400 indicates invalid
4. Building a confirmed list of valid user accounts for further attacks

The security patch modifies exception handling to provide consistent responses. Below is an excerpt from the fix:

                     !exercise.isUserHasAccess(
                         userRepository
                             .findById(currentUser().getId())
-                            .orElseThrow(ElementNotFoundException::new))
+                            .orElseThrow(
+                                () -> new ElementNotFoundException("Current user not found")))
             .map(Exercise::getId);
     List<String> askExerciseIds =
         Stream.concat(askExerciseIdsStream, input.getExerciseIds().stream()).distinct().toList();

Source: GitHub Commit Changes

Detection Methods for CVE-2026-24468

Indicators of Compromise

• Elevated volume of requests to /api/reset endpoint from single IP addresses or ranges
• Sequential or automated request patterns with minimal time intervals between requests
• Large numbers of HTTP 400 responses followed by HTTP 200 responses to the reset endpoint
• Unusual geographic distribution of password reset requests

Detection Strategies

• Implement rate limiting detection on the /api/reset endpoint to identify enumeration attempts
• Configure WAF rules to flag rapid successive requests to authentication-related endpoints
• Monitor application logs for patterns indicating automated enumeration tools (consistent timing, sequential attempts)
• Deploy behavioral analytics to detect reconnaissance activity against user management APIs

Monitoring Recommendations

• Enable detailed logging for all authentication and password reset endpoints
• Set up alerting thresholds for abnormal request volumes to /api/reset
• Correlate reset endpoint activity with subsequent authentication attempts from the same source
• Review access logs regularly for patterns suggesting credential harvesting reconnaissance

How to Mitigate CVE-2026-24468

Immediate Actions Required

• Upgrade OpenAEV to version 2.0.13 or later immediately
• Review access logs for evidence of prior enumeration attempts against the /api/reset endpoint
• Implement rate limiting on the password reset endpoint as a defense-in-depth measure
• Consider notifying users whose accounts may have been enumerated if suspicious activity is detected

Patch Information

The vulnerability has been addressed in OpenAEV version 2.0.13. The fix ensures that the /api/reset endpoint returns a consistent response regardless of whether the username exists, eliminating the observable discrepancy that enabled account enumeration.

Organizations should upgrade to OpenAEV version 2.0.13 as soon as possible. Additional details about the fix are available in the GitHub Security Advisory.

Workarounds

• Deploy a reverse proxy or WAF rule to implement aggressive rate limiting on /api/reset
• Add CAPTCHA or other human verification to the password reset flow
• Restrict access to the password reset endpoint by IP allowlisting where feasible
• Implement account lockout or progressive delays after multiple reset attempts

# Example rate limiting configuration for nginx
location /api/reset {
    limit_req zone=reset_limit burst=5 nodelay;
    limit_req_status 429;
    proxy_pass http://openaev_backend;
}