ezBookkeeping EUVD-2026-83734

Exploitation requires the attacker to already hold the victim's valid primary credentials AND to capture a live, unexpired TOTP passcode, then replay it against the 2FA authorization endpoint (TwoFactorAuthorizeHandler or the OAuth2 callback handler) within the roughly 90-second acceptance window before the code lapses. It applies only to accounts with TOTP two-factor authentication enabled on ezBookkeeping versions before 2.0.0. Limiting factors: this is not remote-unauthenticated in practice - it needs credential theft plus real-time passcode interception (phishing proxy, MITM, or observation), which is why the vendor assigned AC:H, AT:P, and UI:P; there is no exploit that works against a default install without these captured secrets.

This is a genuine but conditional weakness, not a top-tier priority. The vendor CVSS 4.0 vector (7.6) encodes the practical friction well: AC:H, AT:P (present attack requirement), and UI:P all signal that exploitation is not turnkey. Per CWE-294 (Authentication Bypass by Capture-replay), the attacker must ALREADY possess the victim's valid credentials AND capture a live TOTP passcode, then replay it within the ~90-second acceptance window before it expires naturally. This is fundamentally a defense-in-depth degradation of the second factor rather than a standalone auth break - the 2FA still requires a code that must be observed in real time. No EPSS score is provided, there is no CISA KEV listing, and no public exploit code was identified (only the fix commit and advisory). SSVC-style read: exploitation status is 'none observed', technical impact is total (account takeover of financial/bookkeeping data → VC:H/VI:H), but 'automatable' is effectively No given the credential + live-passcode capture prerequisite. The one signal worth flagging: the input tag 'Information Disclosure' conflicts with the actual weakness (capture-replay/authentication), so tag-driven triage would mis-route this. Net: real, patch it, but lower urgency than a PR:N/AC:L network flaw of the same score.

An attacker who has already phished or otherwise stolen a user's ezBookkeeping username and password intercepts a valid TOTP passcode (e.g., via a phishing proxy or shoulder-surfing) and, because the server never marks used codes as consumed, replays that same passcode across multiple authorization attempts within the ~90-second window to complete login and take over the account. No public exploit code was identified; the attack requires live capture of both the credentials and an unexpired passcode, matching the vendor's AC:H/AT:P/UI:P rating.