Databasus CVE-2026-110770

The attacker must know a valid registered email address (ideally an administrator's) to trigger a reset, then must brute-force the six-digit numeric code - feasible only because Databasus 3.7.0-3.61.0 implements no rate limiting, no account lockout, and does not invalidate codes after failed attempts, per the vendor description. The only practical limiting factor is the reset code's validity/expiry window, within which the ~10^6 keyspace must be exhausted; no authentication or user interaction is required (PR:N/UI:N). Risk is bounded chiefly by the small real-world deployment of the product rather than by any technical precondition.

This is a genuine high-severity flaw whose real-world priority is tempered by deployment footprint and missing exploitation signals. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N, VC:H/VI:H/VA:H, score 9.2) correctly reflects unauthenticated, network-reachable, full account takeover - including administrator accounts. The AT:P (Attack Requirement: Present) metric is the key honest nuance: exploitation is not a single trivial request but requires brute-forcing a six-digit code, which is only feasible because the vendor confirms there is no rate limiting, lockout, or code invalidation. EPSS score is not provided and the CVE is NOT in CISA KEV, so there is no evidence of active exploitation. POC status is not flagged in the input, though a public technical writeup describing the method exists (hackmd reference), meaning the barrier to weaponization is low even if no packaged exploit is confirmed. Net assessment: technically critical and easily automatable against affected instances, but the affected product (Databasus) appears to be an obscure open-source project, so aggregate internet-wide risk is far lower than the 9.2 suggests - this is a 'patch promptly if you run it, but not a mass-exploitation emergency' issue. No signals conflict; the main gap is the absence of EPSS/KEV/POC telemetry to gauge in-the-wild interest.

An unauthenticated attacker submits a password-reset request for a known administrator email via POST /api/v1/users/reset-password, causing the system to generate a six-digit reset code. Because there is no rate limiting, lockout, or code invalidation, the attacker scripts up to ~1,000,000 guesses against the endpoint until the correct code is found, then resets the admin password and takes over the account. A public technical writeup documents the technique, lowering the effort required even though no packaged exploit is confirmed in the input.