CVE-2026-24467 OpenAEV Flaw Enables Account Takeover

A newly disclosed critical-severity vulnerability in OpenAEV (CVE-2026-24467) allows unauthenticated remote attackers to fully compromise any registered user account, including administrator accounts, by exploiting two intertwined flaws in the platform’s password reset mechanism.

Rated CVSS 9.0–9.1 CRITICAL, the flaw affects all versions starting from 1.0.0 and has been patched in version 2.0.13. OpenAEV is an open-source platform that enables organizations to plan, schedule, and conduct cyber adversary simulation campaigns and tests.

Because it hosts agents deployed across enterprise hosts and stores sensitive simulation findings, a compromise of its administrative layer can propagate across an entire organization’s infrastructure. This makes CVE-2026-24467 exceptionally severe, beyond a typical web application vulnerability.

OpenAEV Vulnerability

The vulnerability resides in src/main/java/io/openaev/rest/user/UserApi.java, specifically the passwordReset function, and stems from two compounding security weaknesses rather than a single isolated flaw.

Flaw 1 – Non-Expiring Password Reset Tokens:

Password reset tokens in OpenAEV do not expire after they are generated. Once created, a token remains valid indefinitely, even if the user subsequently requests new tokens or significant time has elapsed. Security best practices explicitly require token expiration to prevent reuse; without it, a leaked or archived token becomes a permanent attack vector.

Web archiving services, HTTP referer headers, and log exposure are all realistic mechanisms through which a non-expiring token can be leaked and weaponized.

Flaw 2 – Short 8-Digit Numeric Token Space:

Reset tokens are only 8 numeric digits long, yielding 100,000,000 possible combinations. While this may sound large, the non-expiration flaw allows an attacker to pre-generate thousands of valid tokens for the target account, drastically reducing the brute-force search space.

If an attacker generates 2,000 valid tokens, the required brute-force attempts drop to approximately 50,000, a trivial load for automated tooling running at 100 requests per second, achievable in roughly 500 seconds.

Attack Chain and Exploitation

The attack requires no authentication, no knowledge of the victim’s current password, and critically does not require a real or functional email address; it only needs the target’s registered login identifier within OpenAEV.

The exploit chain works as follows:

Identify a target account: Email addresses are exposed to other users by design in OpenAEV, making enumeration trivial.
Mass-generate reset tokens – The attacker sends hundreds of password reset API requests (POST /api/reset) for the victim account, silently accumulating thousands of valid, non-expiring tokens server-side.
Brute-force token space – Using tools, ffuf the attacker iterates through the now-reduced token pool. With 2,000 pre-generated tokens reducing the search space to ~50,000 candidates, a match is found in minutes.
Reset victim’s password – Upon hitting a valid token via GET /api/reset/{token}, the attacker sets a new password of their choosing, taking complete ownership of the account.

The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) reflects a Changed scope, meaning a successful attacker can pivot beyond the OpenAEV application itself. Compromised administrator accounts allow modification of agent payloads, meaning every host with an OpenAEV agent installed becomes a potential target for secondary compromise.

What elevates CVE-2026-24467 above standard account takeover flaws is its scalability and reliability. Most password reset vulnerabilities require timing precision or social engineering. This exploit is fully automatable, requires zero user interaction, and works against any account, including those with non-guessable credentials.

Additionally, the attack path does not require OpenAEV’s email service to be configured or operational. Defenders cannot rely on monitoring email delivery anomalies as an early warning. Organizations running OpenAEV in isolated environments with disabled email services are equally exposed, making silent mass exploitation a realistic threat.

Security researchers have long flagged non-expiring tokens as a dangerous design pattern. OWASP guidelines mandate that password reset tokens must be single-use, time-limited, and securely bound to the requesting user’s session, none of which OpenAEV enforced before the patch.

Detail	Information
CVE ID	CVE-2026-24467
Affected Package	OpenAEV (`UserApi.java`)
Affected Versions	> 1.0.0
Patched Version	2.0.13
CVSS Score	9.0–9.1 CRITICAL
CWE	CWE-640 (Weak Password Recovery Mechanism)

Remediation

Organizations running OpenAEV must immediately upgrade to version 2.0.13. Beyond patching, security teams should apply the following hardening measures:

Enforce token expiration – Password reset tokens should expire within 15–60 minutes of issuance.
Implement one-time token usage: once a token is consumed or invalidated, it must never be accepted again.
Apply strict rate limiting: throttle password reset API requests per IP and per account to prevent mass token generation.
Increase token entropy – Replace short numeric tokens with cryptographically secure random strings of sufficient length (minimum 32 bytes).
Enable MFA on administrator accounts – Multi-factor authentication provides an additional barrier even if credentials are reset.
Audit exposed user data – Review whether user email/login exposure is necessary and limit visibility where possible.