EUVD-2026-23883Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Lifecycle Timeline
6DescriptionGitHub Advisory
OpenAEV is an open source platform allowing organizations to plan, schedule and conduct cyber adversary simulation campaign and tests. 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. By automating requests with a list of possible email addresses, an attacker can quickly build a list of valid accounts without any authentication. The endpoint should return a consistent response regardless of whether the username exists in order to prevent account enumeration. Version 2.0.13 fixes this issue.
AnalysisAI
User enumeration via timing/response code discrepancy in OpenAEV /api/reset endpoint allows unauthenticated remote attackers to reliably discover registered email addresses by observing HTTP 400 vs HTTP 200 responses. Affected versions 1.11.0 through 2.0.12 expose account lists without authentication; no active exploitation confirmed but the vulnerability requires trivial effort to exploit at scale. Fixed in version 2.0.13.
Technical ContextAI
OpenAEV is a Java-based cyber adversary simulation platform that implements a password reset endpoint (/api/reset) without response normalization. The underlying issue (CWE-204: Observable Discrepancy) occurs in the UserApi.java REST controller where the endpoint returns different HTTP status codes based on whether the supplied email exists in the user repository: non-existent emails trigger HTTP 400 (Bad Request), while valid emails return HTTP 200 (OK). This differential response creates an information leak that bypasses the intended design principle of never confirming user existence during account recovery flows. The vulnerability affects OpenAEV versions 1.11.0 through 2.0.12 (CPE inference: OpenAEV versions in this range), and the fix involves normalizing responses to always return the same HTTP status code and message regardless of account existence.
RemediationAI
Upgrade OpenAEV to version 2.0.13 or later immediately; this version normalizes /api/reset endpoint responses to return identical HTTP status codes and messages regardless of whether the supplied email exists in the system. Organizations unable to patch immediately should implement compensating controls: (1) Rate-limit the /api/reset endpoint to <5 requests per minute per source IP to increase the cost of enumeration attacks, with the trade-off that legitimate password reset flows may experience throttling; (2) Monitor /api/reset endpoint logs for patterns of 400 responses followed by rapid retries, which indicate enumeration attempts, and block source IPs exceeding thresholds; (3) Restrict access to the /api/reset endpoint to known-good IP ranges (e.g., corporate networks or VPN gateways only) if operational scope permits, accepting the trade-off that external users cannot reset passwords. Patch remediation at https://github.com/OpenAEV-Platform/openaev/releases/tag/2.0.13.
Same weakness CWE-204 – Observable Response Discrepancy
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today