The critical detail in CVE-2026-54418 isn't the missing authorization check — it's that four consecutive 2FA methods in Leantime's JSON-RPC dispatcher bypassed security patterns that existed elsewhere in the same codebase. The four methods (getSetupData, saveSecret, verifyAndEnable, disable2FA) form a complete credential lifecycle, and they were all shipped without the ownership checks, session pinning, and permission gates present in every other RPC method. This wasn't four independent oversights — it was a single feature branch that never got cross-referenced against the dispatcher's established patterns.
The practical exploit is straightforward: an attacker with any valid session calls disable2FA on a target userId, then performs a standard password reset. The target loses their second factor without any code guessing or token interception. This turns 2FA from a defense layer into a liability — enabling it actually increases the account's attack surface because the user believes they're protected when the protection can be stripped remotely.
The EPSS score of 0.00297 seems to contradict the CVSS 8.1 rating, but this disconnect is misleading for Leantime specifically. The low EPSS reflects the small self-hosted install base and the requirement for authentication — not the severity of what's possible. For self-hosted deployments, the vulnerability window is actually longer than typical: there's no automatic update pushing patches, and organizations commonly rationalize delay because 'nobody's being exploited yet.' That longer window is the trap, not the comfort it appears to be.
The key question that remains unanswered in the advisory is what level of authentication is required. If these RPC methods accept any valid session, this is an escalation-of-privilege issue from authenticated user to admin-level control. If they accept unauthenticated requests, it's unauthenticated account takeover. Either way, the authorization model permits any caller to act on any userId — the blast radius isn't 'some accounts,' it's every user in the system.
Prioritize this patch based on the blast radius, not the EPSS. The EPSS is backward-looking; the vulnerability itself is architectural and permanent until the code changes.