Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:HSummary
CVE-2026-24467 is a critical-severity Weak Password Recovery Mechanism for Forgotten Password (CWE-640) vulnerability in Filigran Openaev. Its CVSS base score is 9.0 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Valid Accounts (T1078); ranked in the top 44% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to IA-12 (Identity Proofing) and IA-5 (Authenticator Management) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
OpenAEV is an open source platform for planning and conducting cyber adversary simulation campaigns. CVE-2026-24467 affects password reset handling in versions 1.0.0 through 2.0.12. The implementation issues non-expiring reset tokens that are only eight digits long, enabling an attacker to accumulate many valid tokens for a target account and then brute-force them with a modest number of unauthenticated requests.
An unauthenticated remote attacker who knows or guesses a registered email address can generate large numbers of reset tokens and efficiently locate a valid one, after which the victim's password can be changed without the original credentials or any email interaction. Because the platform exposes user email addresses by design, the attack scales to any account, including administrators, and grants full access to simulation data and the ability to alter agent payloads that run on deployed hosts.
The project security advisory and release notes for version 2.0.13 state that the issue is resolved by upgrading to that version; the corresponding code change is tracked in the referenced GitHub commit. The EPSS score has remained flat at 0.0131 with no material increase since disclosure.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-23882
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V7.4.3
Mitigating Controls (NIST 800-53 r5) AI
Identity proofing at appropriate assurance levels ensures forgotten-password recovery cannot succeed without strong verification of the user.
Authenticator management requires secure distribution, reset, and verification procedures that directly address weak password recovery flows.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Credential lifecycle management directly includes password reset/recovery flows.
Identity proofing is the core control that prevents weak or bypassed recovery mechanisms.
Authentication policy covers strength/MFA but does not address recovery path weaknesses.
Secure SDLC reduces implementation flaws but is not specific to password-recovery design.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Strong authentication-information lifecycle rules directly address weak password-recovery flows.
Secure-SDLC practices can embed strong recovery design, yet the control is broader than this single weakness.
Application-security requirements can mandate secure recovery flows, but the control covers many other requirements.
Secure-coding standards can prevent weak recovery implementations, yet the control is wider in scope.
Secure-authentication requirements include robust forgotten-password procedures.
Proper access-rights provisioning can limit who can trigger recovery, but does not fix the recovery mechanism itself.