CVE-2026-24467

OpenAEV's Improper Password Reset Token Management Leads to Unauthenticated Account Takeover and Platform Compromise

Published Apr 20, 2026 · Updated Apr 20, 2026

OpenAEV is an open source platform allowing organizations to plan, schedule and conduct cyber adversary simulation campaign and tests. Starting in version 1.0.0 and prior to version 2.0.13, OpenAEV's password reset implementation contains multiple security weaknesses that together allow reliable account takeover. The primary issue is that password reset tokens do not expire. Once a token is generated, it remains valid indefinitely, even if significant time has passed or if newer tokens are issued for the same account. This allows an attacker to accumulate valid password reset tokens over time and reuse them at any point in the future to reset a victim’s password. A secondary weakness is that password reset tokens are only 8 digits long. While an 8-digit numeric token provides 100,000,000 possible combinations (which is secure enough), the ability to generate large numbers of valid tokens drastically reduces the required number of attempts to guess a valid password reset token. For example, if an attacker generates 2,000 valid tokens, the brute-force effort is reduced to approximately 50,000 attempts, which is a trivially achievable number of requests for an automated attack. (100 requests per second can mathematically find a valid password reset token in 500 seconds.) By combining these flaws, an attacker can mass-generate valid password reset tokens and then brute-force them efficiently until a match is found, allowing the attacker to reset the victim’s password to a value of their choosing. The original password is not required, and the attack can be performed entirely without authentication. This vulnerability enables full account takeover that leads to platform compromise. An unauthenticated remote attacker can reset the password of any registered user account and gain complete access without authentication. Because user email addresses are exposed to other users by design, a single guessed or observed email address is sufficient to compromise even administrator accounts with non-guessable email addresses. This design flaw results in a reliable and scalable account takeover vulnerability that affects any registered user account in the system. Note: The vulnerability does not require OpenAEV to have the email service configured. The exploit does not depend on the target email address to be a real email address. It just needs to be registered to OpenAEV. Successful exploitation allows an unauthenticated remote attacker to access sensitive data (such as the Findings section of a simulation), modify payloads executed by deployed agents to compromise all hosts where agents are installed (therefore the Scope is changed). Users should upgrade to version 2.0.13 to receive a fix.

CVSS severityUnavailable
Unscored
EPSS probability0.90%
Next 30 days · Sep 16, 2026
Known exploitationUnconfirmed
Based on sourced intelligence
Hinoki checkNot available
Coverage for this vulnerability

See if you're affected

Explore vulnerability checks for your environment with Hinoki.

Book a demo

Summary

What happened

OpenAEV is an open source platform allowing organizations to plan, schedule and conduct cyber adversary simulation campaign and tests. Starting in version 1.0.0 and prior to version 2.0.13, OpenAEV's password reset implementation contains multiple security weaknesses that together allow reliable account takeover. The primary issue is that password reset tokens do not expire. Once a token is generated, it remains valid indefinitely, even if significant time has passed or if newer tokens are issued for the same account. This allows an attacker to accumulate valid password reset tokens over time and reuse them at any point in the future to reset a victim’s password. A secondary weakness is that password reset tokens are only 8 digits long. While an 8-digit numeric token provides 100,000,000 possible combinations (which is secure enough), the ability to generate large numbers of valid tokens drastically reduces the required number of attempts to guess a valid password reset token. For example, if an attacker generates 2,000 valid tokens, the brute-force effort is reduced to approximately 50,000 attempts, which is a trivially achievable number of requests for an automated attack. (100 requests per second can mathematically find a valid password reset token in 500 seconds.) By combining these flaws, an attacker can mass-generate valid password reset tokens and then brute-force them efficiently until a match is found, allowing the attacker to reset the victim’s password to a value of their choosing. The original password is not required, and the attack can be performed entirely without authentication. This vulnerability enables full account takeover that leads to platform compromise. An unauthenticated remote attacker can reset the password of any registered user account and gain complete access without authentication. Because user email addresses are exposed to other users by design, a single guessed or observed email address is sufficient to compromise even administrator accounts with non-guessable email addresses. This design flaw results in a reliable and scalable account takeover vulnerability that affects any registered user account in the system. Note: The vulnerability does not require OpenAEV to have the email service configured. The exploit does not depend on the target email address to be a real email address. It just needs to be registered to OpenAEV. Successful exploitation allows an unauthenticated remote attacker to access sensitive data (such as the Findings section of a simulation), modify payloads executed by deployed agents to compromise all hosts where agents are installed (therefore the Scope is changed). Users should upgrade to version 2.0.13 to receive a fix.

The record

CVE
CVE-2026-24467
Published
Apr 20, 2026
Updated
Apr 20, 2026
Vendor
Unknown vendor
Product
Unknown product
Classifications
Unavailable
Attack vector
Unavailable
Privileges
Unavailable

Timeline

How it unfolded

  1. Apr 20, 2026CVE publishedPublication date reported by the CVE source.
  2. Apr 20, 2026Record updatedLatest update available in the CVE record.

Exploitability

Present is not the same as exploitable

Compare your product and version with the public record. A matching version still requires validation against your environment.

Is a vulnerable build present?

Affected buildAffected product and version details are unavailable.

What conditions does exploitation require?

Attack vectorUnavailable in this record.
Required privilegesUnavailable in this record.

What is affected?

Affected products and versions are unavailable in this record.

Published CVSS scores

No CVSS assessment is available in this record.

CVSS describes severity. EPSS estimates exploitation probability.

Attacks

What attackers are doing with it

Daily unique IPs observed by Shadowserver honeypots for known exploited vulnerabilities (KEVs). Missing observations do not establish an absence of attacks.

Daily unique IPsNo honeypot observations are available for this CVE in the selected window.

No observations available

Sep 10, 2026Sep 16, 2026
Latest reporting daySep 16, 2026
Latest daily unique IPsUnavailable
Prior 30-day averageUnavailable
SourceShadowserver honeypots (KEV)
VectorUnavailable
PrivilegesUnavailable
Known exploitationUnconfirmed
Public exploitUnconfirmed

Weakness, pattern, technique

No sourced classifications are available.

Public exploit references

No public exploit references are available in this record.

Labels summarize the accepted research assessment. They do not indicate a test against your environment.

Technologies

Your stack

See the directory against your own environment.

Your stack

Check the software in your environment

Book a demo to see how Hinoki identifies affected software and validates exploitability in your environment.

Book a demo