CVE-2026-14495
Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HSummary
CVE-2026-14495 is a high-severity PRNG (CWE-338) vulnerability in Wordpress (inferred from references). Its CVSS base score is 8.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Valid Accounts (T1078); ranked at the 36th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to IA-5 (Authenticator Management) and SC-23 (Session Authenticity) — see the control section below for these in your framework.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-42167
Vulnerability Data
The DoLogin Security plugin for WordPress is vulnerable to Authentication Bypass via Insufficient Randomness in all versions up to, and including, 4.3. The vulnerability exists because `dologin\s::rrand()` seeds the Mersenne Twister with `mt_srand((double) microtime() * 1000000)` — discarding the integer-seconds…
more
component of `microtime()` and constraining the seed to a range of approximately 10^6 values (~20 bits of entropy) — after which every character of the 32-character magic-link token is drawn sequentially with `mt_rand()`, making the entire token a deterministic function of that seed. Because `Pswdless::try_login()` is registered on the unauthenticated `init` hook, resolves the target account by the auto-increment numeric ID embedded in the `?dologin=<id>.<hash>` parameter, performs the hash comparison using a non-constant-time `!=` operator, and then calls `wp_set_auth_cookie()` directly — never passing through `wp_authenticate()` and therefore never triggering the plugin's own `Auth::_has_login_err()` lockout — an unauthenticated attacker can brute-force the ~10^6-candidate seed space to reconstruct an active passwordless login token and authenticate as any targeted user, including administrators, without a password. Exploitation requires that a valid, unexpired passwordless login link (active for up to 7 days) exists for the target account at the time of the attack, and that the numeric link ID is known or guessable from the auto-increment primary key.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
The vulnerability enables authentication bypass by brute-forcing a low-entropy seed to forge valid passwordless login tokens (T1078 Valid Accounts via T1110.004 Credential Stuffing), and the flaw is exposed through an unauthenticated web endpoint in a WordPress plugin (T1190 Exploit Public-Facing Application).
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
- 3 hardening rules · 3 OS baselines
V7.2.3V11.5.1
Mitigating Controls (NIST 800-53 r5) AI
IA-5 requires proper authenticator generation and management; the plugin's mt_srand(microtime()*1e6) + mt_rand() produces only ~20 bits of entropy for the 32-character magic-link token, directly violating this requirement.
AC-7 enforces limits on unsuccessful authentication attempts; the plugin bypasses its own lockout logic by calling wp_set_auth_cookie() directly on the unauthenticated init hook, allowing unlimited brute-force attempts against the weak token.
SC-23 requires session authenticity; the deterministic, low-entropy magic-link token allows an attacker to forge a valid unauthenticated session for any user whose link ID is known.
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.
Secure SDLC practices explicitly require cryptographically strong RNG selection and usage in security contexts.
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.
Mandates use of approved cryptographic controls, directly requiring cryptographically strong RNGs.
Security testing can detect use of weak random number generators.
Secure SDLC processes should catch weak PRNG usage during design and code review.
Application security requirements can specify cryptographically strong random number generation.
Secure engineering principles include selection of appropriate cryptographic primitives.
Secure coding standards prohibit use of weak PRNGs in security contexts.